-
-
Race Control Dashboard
-
Accident info
-
Hardware
-
Flow-chart
FlagSense
Inspiration
In motorsport, an incident can become dangerous very quickly.
Imagine a driver has crashed and is stopped near the racing line. They may be winded, trying to exit the car, or unable to move immediately. Meanwhile, the race leaders are approaching at racing speed.
The stopped car is no longer the only hazard, every approaching car can become another one.
Race control has to interpret telemetry, track position, traffic, and incident context quickly before deciding whether to deploy a yellow flag, Safety Car, or red flag.
We built FlagSense to explore whether software could bring those signals together, identify developing risk, explain what it sees, and recommend a response while keeping the final decision with a human operator.
What it does
FlagSense is an incident-analysis and race-control decision-support system.
It replays vehicle telemetry on an interactive track map and continuously looks for signs that an incident may have occurred, including:
- severe or abnormal deceleration
- a vehicle remaining stationary
- proximity to the racing line
- approaching high-speed traffic
- closing speed and distance to nearby cars
- the duration and developing context of the incident
When an incident is detected, FlagSense evaluates its severity and produces an evidence-based recommendation such as:
- Green
- Yellow Flag
- Safety Car
- Red Flag
Instead of only displaying a recommendation, FlagSense explains why it reached it.
For example:
Recommended: RED FLAG
Car #XX is stationary near the racing line with high-speed traffic approaching.
The dashboard also separates historical race-control actions from FlagSense recommendations, allowing the two timelines to be compared without presenting the prototype as a replacement for official decision-making.
FlagSense includes a repeatable synthetic race simulation along with four historical incident scenarios for demonstrating and testing different conditions.
An optional ESP32-S3 hardware display connects to the system and communicates the current recommendation using an LCD and LED ring, creating a physical race-control indicator.
How we built it
FlagSense is built as several independent layers so that incident detection, machine learning, decision logic, and visualization remain inspectable.
1. Telemetry processing
A Python pipeline validates incoming telemetry, maps vehicle positions onto circuit geometry, and calculates incident-related features.
These include values such as:
- deceleration
- stationary time
- vehicle speed
- distance from the racing line
- distance to approaching vehicles
- closing speed
- surrounding traffic conditions
This creates a consistent representation of each developing incident.
2. Severity estimation
A scikit-learn Random Forest estimates incident severity using seven telemetry-derived features.
The machine-learning model does not directly decide which flag should be shown.
Instead, it produces an additional severity signal that can be considered alongside measurable track conditions.
This separation was intentional: we wanted machine learning to help identify patterns without allowing a model score alone to determine a safety recommendation.
3. Deterministic recommendation engine
A transparent rules engine combines the severity estimate with explicit evidence such as vehicle position, stationary duration, track obstruction, and approaching traffic.
The engine then recommends an appropriate track state and generates an explanation describing the evidence behind that recommendation.
This makes the output easier to inspect than a purely black-box classifier.
4. Historical scenario context
Historical scenarios can include environmental information and manually reviewed observations from incident stills.
These observations can influence explicit rules but are not used as inputs to the Random Forest.
Some historical vehicle motion is simulated when reliable telemetry is unavailable, and the dashboard clearly labels simulated data rather than presenting it as measured telemetry.
5. Dashboard and hardware
The offline dashboard is built with Streamlit and Plotly.
It provides:
- interactive race replay
- vehicle positions on the circuit
- incident evidence
- FlagSense recommendations
- historical race-control actions
- recommendation timelines
- scenario controls
We also built an ESP32-S3 display that receives the current recommendation and incident context.
The LED ring provides an immediate visual indication of track status, while the LCD displays the recommended response and a short explanation.
Challenges
Limited incident data
Serious motorsport incidents are intentionally rare, which makes high-quality labeled datasets difficult to obtain.
We therefore generated synthetic examples to build and exercise the telemetry pipeline before adding sourced historical scenarios for demonstration.
Synthetic data is useful for development, but it cannot establish real-world model accuracy. We designed the project around that limitation instead of hiding it.
Separating simulated and real information
Historical incidents do not always have publicly available high-frequency telemetry.
For some scenarios, we recreate portions of vehicle movement to demonstrate how FlagSense would respond.
A major challenge was making sure simulated information remained clearly distinguishable from historical observations and sourced race-control events.
Deciding where machine learning belongs
One of our biggest design questions was how much authority a machine-learning model should have in a safety-related system.
We decided that ML should estimate severity, not directly control the final recommendation.
The final track-status recommendation comes from deterministic logic whose evidence can be displayed and inspected by a human operator.
What we learned
One of our biggest takeaways was that a useful safety system needs to communicate uncertainty and reasoning, not just output a prediction.
A recommendation such as Red Flag is much more meaningful when the operator can also see:
- what vehicle triggered the incident
- where it stopped
- how long it has been stationary
- what traffic is approaching
- which conditions caused the recommendation to change
We also learned how useful deterministic replay is when developing systems like this.
Because every scenario can be reproduced exactly, we can change thresholds, features, or model behavior and immediately see how those changes affect the same incident.
Finally, we learned that synthetic data is extremely useful for building infrastructure and testing edge cases, but it should never be confused with real-world validation.
What's next
The next step for FlagSense would be testing the system using appropriate high-frequency motorsport telemetry and properly labeled incident data.
We would also like to work with motorsport safety experts to evaluate:
- incident-detection thresholds
- recommendation rules
- false positives and false negatives
- model calibration
- how recommendations should communicate uncertainty
- which information is actually useful to race-control operators
With a sufficiently large validated dataset, we could compare different severity-estimation approaches and determine whether machine learning provides meaningful value beyond deterministic telemetry rules.
We would also like to expand the hardware prototype into a broader race-control interface with multiple distributed displays.
FlagSense is not intended to replace race control.
It is an exploration of how telemetry, machine learning, transparent rules, and human decision-making could work together to make rapidly developing incidents easier to understand.
Slide Deck
View our presentation deck here:
Log in or sign up for Devpost to join the conversation.