Inspiration

In a race, the pit wall keeps asking one question: should we pit now to jump the car ahead, or wait? Strategists make that call in seconds, from tyre wear, gaps, traffic and weather. We wanted a companion that answers in plain language, and that shows its working instead of giving a confident guess. In motorsport a wrong call costs places, so an answer you can check matters more than one that merely sounds good.

What it does

Pit Wall Copilot watches a race and tells the strategist when an undercut is on, and why.

  • Undercut and what-if calculator: it works out the time gained from a stop, with a Monte Carlo confidence band, and compares "pit now" with "wait 3 laps".
  • Strategy watches: you set a standing condition ("tell me when it opens") and it checks every lap. It uses hysteresis, so alerts don't flicker.
  • Grounded explanations: each alert is explained in plain words, and the numbers in the text are re-checked against the calculation. If they don't match, the text is rejected. It cites rule excerpts and refuses to invent anything it doesn't have, such as a rule number that isn't on file.
  • Web dashboard: a broadcast-style dashboard with a timing tower, circuit maps for eight real circuits, weather, and ten cars from five teams. It has engineer tools: sector times, ghost lap, tyre cliff prediction, fuel and energy, a pit-window drop map, an undercut threat matrix, a safety-car outlook, a Monte Carlo strategy simulator and a briefing.
  • Voice: a simulated Alexa+ client asks questions through an MCP tool server. Every answer shows the tool calls behind it.

All race data is simulated. Team and driver names and circuit shapes are real so the demo is recognisable; the lap times, tyre models and results are not.

How we built it

  • Backend: one modular FastAPI app holds all the logic. It contains a deterministic race simulator, the strategy engine (undercut and what-if with Monte Carlo trials), a watch evaluator, a knowledge base of rule excerpts and an explanation engine. State is stored in memory by default.
  • Voice path: an MCP server (FastMCP, Streamable HTTP) exposes five domain tools. A simulated Alexa+ client holds a real MCP session against it. Only the Alexa+ client is simulated; the protocol and HTTP calls are real.
  • Clients: a single-file HTML/JavaScript/SVG web dashboard with no build step, and a React Native app for Amazon Fire TV.
  • Design rule: the strategy engine decides the numbers and the language layer only describes them. The explanation uses a deterministic template by default, with a Bedrock option built but never run.
  • Testing: 595 backend tests, 53 MCP server tests, 8 simulated Alexa+ tests, 19 legacy skill tests and 186 Fire TV tests pass locally. They make no AWS or outbound network calls.
  • AWS: we wrote infrastructure code (a SAM template for DynamoDB, ECS Fargate, Lambda and more) but did not deploy it.

Challenges we ran into

  • No AWS access. We built everything to run locally and kept the AWS pieces as code and templates only. That is why we describe the project as source-validated with AWS pending, and say so everywhere.
  • Keeping the language layer honest. It is easy for a language model to state a number that sounds right. We made the numbers deterministic, re-check every figure in the explanation against the calculation, and make the assistant refuse when it lacks evidence.
  • Making a simulation feel like a race. We made each circuit look and behave differently, with DRS zones, corners, kerbs, weather and tyre crossover. Doing that without real telemetry meant clearly labelling what is invented.
  • Fitting many tools without clutter. The dashboard now has six pages (Race, Telemetry, Strategy, Analysis, Copilot, Championship), so nothing is crammed together.

Accomplishments that we're proud of

  • Answers that carry their own evidence: tool calls shown, numbers re-checked, and refusals when it doesn't know.
  • A full voice path over a real MCP protocol, even without a real Alexa+ device.
  • A dashboard that looks and feels like a race broadcast, with strategy tools you can actually use.
  • Hundreds of passing tests and clear, honest documentation of what is built, simulated and not built.

What we learned

  • Grounding the language layer in deterministic calculations makes the assistant far more trustworthy.
  • Clear boundaries between "built", "simulated" and "not built" make the project easier to judge and to continue.
  • Small, separate tools (five MCP tools, one backend) are easier to test and reason about than one large agent.

What's next for Pit Wall Copilot

  • Deploy the existing infrastructure to AWS and validate it (ECS, DynamoDB, CloudWatch), and test the Bedrock explanation path.
  • Test on a physical Fire TV and a real Alexa+ device, and build a signed Android release.
  • Connect real-time telemetry (UDP or WebSocket feeds, a stream bus such as Redis or Kafka, and historical data from FastF1) to replace the simulated models.
  • Add speech-to-text for team radio.
  • Calibrate the tyre and fuel models against recorded race data and compare our recommendations with real team decisions.

Built With

Share this project:

Updates

Submission history