Chain-Break

A hardware-connected stress-testing environment that finds when a motorsport safety warning stops protecting the driver — not just whether it works once.

Comment

Inspiration

Most safety-tech projects at a hackathon answer one question: can we detect danger? FTHacks gave me a chance to ask a different one — even if a system detects danger perfectly, does the warning actually survive the real world getting messy: a slow network, a dropped sensor, a driver who reacts half a second late? ChainBreak answers that with real hardware and real numbers, not a hunch.

What it does

ChainBreak takes a connected safety-warning system (in this demo: an automatic double-yellow flag) and tests it under stress instead of just demonstrating that it works once.

  • A physical incident node — an ESP32, an MPU9250 accelerometer, and a push button — detects a real impact or manual trigger and sends it over WiFi to the backend.
  • That activates a modeled approach: a following car's distance, speed, and time to the hazard.
  • ChainBreak then runs 1,200 seeded scenarios across five degraded conditions at once — network latency, packet loss, reduced grip, driver response delay, and sensor dropout — and classifies each as safe, marginal, or unsafe based on simulated stopping distance.
  • A logistic model (fitted with Newton–Raphson/IRLS, 95.0% held-out accuracy) finds the exact failure boundary: at reference conditions, the warning chain holds up to 0.68 seconds of one-way network latency before it's more likely to fail than not.
  • Four interventions — no warning, yellow, double yellow, virtual safety car — are compared on the identical scenario set, so the comparison is fair.
  • If the hardware node goes quiet for more than 2.5 seconds, ChainBreak doesn't guess. It declares degraded mode and falls back to cached data, clearly labeled, with nothing fabricated.

How we built it

  • Backend: Node.js, zero runtime dependencies, custom simulation and stress-testing engine
  • Frontend: vanilla JS dashboard with a live scenario inspector, scatter plot, and intervention comparison
  • Hardware: ESP32 + MPU9250 + push button, posting JSON packets to a real ingest endpoint over WiFi. The IMU on hand turned out to be an MPU9250, not the chip the first library assumed, so I read its accelerometer registers directly instead of relying on a mismatched library.
  • Stats: seeded Latin-hypercube sampling for the stress sweep, logistic regression via IRLS for the fitted boundary, an 80/20 held-out split to check the fit generalizes rather than just memorizing the sweep
  • Tests: 41 automated tests covering the simulation engine, adapters, and hardware edge cases

Challenges we ran into

  • The IMU's chip ID didn't match the library I started with — same footprint, different chip, silent failure. Fixed by talking to the accelerometer's registers directly.
  • Getting the ESP32 to actually reach the backend took real debugging: a missing firewall rule and a server that wasn't bound to the right host both looked like hardware failures until I isolated them with a phone-browser test.
  • The subtlest bug: a real physical incident was reaching the server and updating the hardware status panel — but wasn't flowing into the actual incident state the rest of the dashboard uses. I traced it, wrote up exactly what was and wasn't working, and personally verified the fix: reset, trigger, watch the approach window populate, run the stress test, disconnect, watch it degrade honestly, reconnect, watch it recover.
  • The push button failed mechanically late in the build. Rather than hide it, ChainBreak runs IMU-only for the live demo — a small, honest example of the exact kind of hardware fragility this project is built to test for.

Accomplishments that we're proud of

  • A complete, physically real trigger path — an actual sensor, not a simulated one, driving a real incident through to a real result
  • A fail-safe I watched work end to end: signal lost → honest degraded mode with nothing invented → signal restored → clean recovery, no stale state left behind
  • A model that isn't just asserted — it's fitted from data, checked against a held-out set, and cross-checked against a second, independent method
  • Getting here without prior hardware experience — every wire, pin, and library mismatch worked through from scratch

What we learned

That "it detects the danger" and "the detection can be trusted" are two different claims, and almost nobody tests the second one. Also: chip identification matters more than expected, a firewall setting is a more common demo-killer than bad code, and a held-out accuracy number only means something once you've watched it fire from a real trigger, not just read it in a report.

What's next for Chain-Break

  • Solder the button connections for a reliable second trigger path
  • Wire in a real historical OpenF1 incident replay alongside the synthetic sample
  • Add a second hardware node to model an actual secondary-collision chain, not just a single incident
  • Sensitivity analysis on the model's stated assumptions (braking capability, driver reaction baseline)

Built With

Share this project:

Updates

Submission history