ApexTrace: Find the Failure Before the Wall Does

At 330 km/h, a brake warning 0.3 s late is 28 m too late. ApexTrace breaks an F1 car's warning system in every way it can fail, then finds the cheapest upgrade that fixes it.

Comment

Inspiration

At Monza's first corner an F1 car brakes from 334 km/h to 76 km/h in 2.8 seconds, covering 93 metres every second. Every car streams about 1.1 million data points a second from 300 sensors to the pit wall, and warnings like brake now depend on that same chain of sensors, radio links and software. Delay it by a third of a second and the warning lands 28 metres late. Lose the link and there's no warning at all.

Teams test the car relentlessly. We wanted to stress-test the warning chain itself: what happens to "brake now" when the rain comes, the brakes fade, a sensor lies, or the radio drops at 330 km/h?

What it does

ApexTrace is a crash lab for a race car's corner-entry BRAKE warning. It has four screens:

  • Drive: the real Monza and Baku layouts with a 2026-regulation car model. Drive it on the keyboard, a gamepad, or our custom ESP32 steering wheel. The warning under test flashes BRAKE at the last safe moment.
  • Engineer: the saboteur on the pit wall. From a second device, pick a saved scenario or build single faults: 22 fault types across 7 layers, from the road to the driver. Examples:
    • Monza, high-speed blackout: the radio dies 390 m before turn 1, and the driver sees WARNING DATA STALE instead of BRAKE.
    • Monza, wet braking zone: rain at turn 1, and the grip sensor notices 4 s late. The track visibly turns wet.
    • Baku, speed sensor freeze: the speedometer sticks but the data still looks fresh.
  • Garage: safety meets money. Three upgrades (brake servicing, a faster radio link, an onboard fallback warning) give 8 combinations, each driven through 42 held-out tests (14 scenarios × 3 seeds). That's 336 simulated laps. It then recommends the cheapest mix that fits the team's real budget: cash, minus what's already owed, minus an emergency reserve.
  • Compare: replays the same test twice, with and without the upgrade, as a see-through "ghost" car beside yours, with outcome cards and a speed trace.

The headline result: with no upgrades the car passes 14 of 42 tests. The most expensive single upgrade (the faster radio, CAD 2,500) fixes the least, because a faster radio that's switched off still sends nothing. The cheapest, a CAD 1,000 onboard fallback, fixes the most. Brake servicing plus fallback (CAD 2,500) passes 31 of 42: every test any upgrade can fix. The 11 that still fail (frozen or biased sensors, wet braking) are shown openly as "no upgrade fixes this".

How we built it

  • Simulation (Python, FastAPI): a server-authoritative car at 20 Hz.
    • load-sensitive tyres with a friction circle and lateral load transfer
    • downforce and drag with active aero
    • a 400 kW engine plus a 350 kW hybrid system and an 8-speed gearbox
    • traction control, ESC and steerable ABS
    • kerbs, grass, run-off and solid walls
  • Warning under test: a physics rule that shows BRAKE when the distance to the corner drops below

$$d_{warn} = \frac{v^2 - v_{corner}^2}{2\,a_{brake}} + v\,t_{react} + d_{margin}$$

using only what the car reports. It shows STALE when data is older than 300 ms.

  • Stress framework:
    • a seeded fault scheduler that plugs each fault into one layer of the chain: road, car, sensors, uplink, warning service, downlink or driver
    • a scripted test driver that brakes only when warned
    • separate dev and held-out suites with acceptance criteria fixed in advance
  • AI model 1: crash predictor. An ensemble of three temporal convolutional networks (PyTorch) reads 2.5 s of reported telemetry and predicts track-exit risk 1 s ahead. It scores PR-AUC 0.94 on 153,304 unseen moments, versus 0.08 for a stopping-distance rule and 0.20 even for knowing the true edge distance. It only observes and never triggers warnings.
  • AI model 2: fault-finding adversary. A Soft Actor-Critic agent (Stable-Baselines3, Gymnasium) controls grip loss, radio delay and brake fade under a hard budget and rate limits, and learns timings that crash the car. It found its first crash in 410 attempts versus 2,174 for random search (14 crashes vs 8). We re-ran its finds on full laps and report that only 1 of 4 still crashes.
  • Frontend (React, TypeScript, Vite, React Three Fiber / three.js):
    • real track geometry
    • an optimised GLB car with steering wheels
    • image-based lighting, ACES tone mapping, bloom and SMAA
    • baked tree impostors, kerbs and tyre walls
    • sparks, smoke and skid marks
    • rain with a wet reflective road and tyre spray
    • a live Web Audio engine synthesised from rpm and throttle
  • Hardware:
    • an ESP32 wheel with two MPU6050 IMUs (accelerometer and gyro) for steering
    • an HW-504 joystick for throttle, brake and reset
    • a 1.69" ST7789 colour screen showing the live BRAKE warning
    • two SG90 servos for rumble
    • a Python serial-to-WebSocket bridge
    • our 3D printer never arrived, so the chassis is artisanal cardboard

Challenges we ran into

  • Making "passed" mean something. The first calibration failed every configuration on the test suite. We separated tests that no upgrade can fix from those that can, and judge upgrades only on the fixable ones.
  • Physics. Early builds spun under full traction control and couldn't turn while braking. That's fixed with ESC and ABS that leaves grip for steering.
  • Smooth 3D from a 20 Hz server. We added entity interpolation, adaptive resolution and a throttled test pool so the evaluation doesn't stutter the driving.
  • Hardware.
    • noisy IMU steering, fixed with a One-Euro filter and a response curve
    • a joystick that needed centre calibration at boot
    • a screen driver that fought us until the very last push
  • Honesty. An AI that "finds crashes" is easy to overclaim, so we re-validate its finds on full laps and show when they don't hold.

Accomplishments that we're proud of

  • The whole warning chain is breakable and measurable, from tyre grip to the driver's reaction, with results reproducible to the seed.
  • A counter-intuitive, defensible answer: the cheapest upgrade beats the most expensive one, proven on held-out tests.
  • Two AI models that each beat strong baselines, and are reported with their limits.
  • A working custom wheel, made of cardboard, with live force feedback.

What we learned

  • Safety systems fail at the seams: late data, stale data, and sensors that lie while looking healthy.
  • "Buy the best" is not "buy the right thing". You only know which is which by testing.
  • Evaluation design matters as much as the model: held-out suites, fixed acceptance criteria, and baselines that are hard to beat.

What's next

  • Plug in real team telemetry in place of our simulated car.
  • More fault types: tyre blowout, crosswind, left/right brake imbalance.
  • More tracks.
  • Let the RL adversary feed new scenarios straight into the Garage's test suite.

Built With

Share this project:

Updates

Submission history