Skip to content
Programming, Controls & Sensors·Lesson 48 of 51

Log Replay Architecture with AdvantageKit

Record every input to your robot code and re-run it bit-for-bit offline, so you can debug a real match from your couch and verify fixes deterministically.

Sign in to track progress, earn XP, and save lessons.

The hardest FRC bugs are the ones you can't reproduce: a vision glitch in match 47, an auto that failed once. AdvantageKit (by Team 6328, Mechanical Advantage) solves this with deterministic log replay -- a software-engineering technique borrowed from distributed systems.

The core idea: IO at the boundary

AdvantageKit records every input your code reads -- joystick values, every sensor and motor signal, gyro, vision, timestamps -- to a log on the robot. The trick is architectural: all hardware access is isolated behind IO interfaces. Your subsystem logic reads from an Inputs object, never directly from a motor.

public interface DriveIO {
  class DriveIOInputs { double leftPositionRad; double leftVelocityRadPerSec; /* ... */ }
  void updateInputs(DriveIOInputs inputs);
  void setVoltage(double left, double right);
}

At runtime a DriveIOTalonFX (or DriveIOSparkMax) reads real hardware. The subsystem only sees the recorded inputs.

Replay: re-run the exact match offline

Because the code is deterministic in its inputs, AdvantageKit can later feed the recorded log back through the same code on your laptop -- no robot needed. Every calculated value (odometry pose, command state, vision result) is recomputed identically. You can add new logged outputs to old code, replay last week's match, and see internal values you never thought to log at the time. That is the superpower: debug the past with new instrumentation.

Why it changes debugging

  • A flaky auto becomes reproducible: replay it as many times as you want.
  • You can fix a bug, replay the failing match, and prove the fix works against the real data -- before ever touching the robot.
  • Combined with AdvantageScope, you scrub through the match timeline and watch every internal value.

Cost and fit

The IO-interface discipline is real work and adds boilerplate; it suits teams ready for serious software engineering, not first-year programmers. Vendor swerve templates exist that already follow the pattern (e.g. the AdvantageKit TalonFX swerve template, which supports high-frequency odometry and deterministic replay), so you can adopt the architecture without writing it from scratch.

Case study mindset

Top-tier teams treat their robot code like production software: every match is a recorded test case. When something goes wrong at an event, they pull the log, replay it in the pit, and diagnose deterministically instead of guessing and re-queuing. That feedback loop -- record, replay, fix, prove -- is a big part of why elite programming teams iterate so fast.

Key takeaways

  • AdvantageKit records all robot inputs and replays them deterministically offline -- debug a real match with no robot.
  • The enabling pattern is IO interfaces: subsystem logic reads an Inputs object, hardware lives behind a swappable IO class.
  • Replay re-runs identical logic, so you can add new logged outputs to old code and inspect values you never originally logged.
  • It adds boilerplate and suits software-mature teams; vendor swerve templates provide the architecture pre-built.

Lesson quiz

Required

Answer all 3 questions correctly to complete this lesson.

1.In an AdvantageKit-based robot, how is hardware interaction structured to enable log replay?

2.During AdvantageKit log replay, how does the framework reproduce the robot's exact behavior?

3.Why must any non-deterministic data source cross the logged IO interface boundary in AdvantageKit?

Answer every question to submit.