Logging Options
Data Logging: Understanding What Happened
Data logging captures robot telemetry, sensor values, and system state during operation. You'll use that data to debug issues, analyze performance, tune mechanisms, and figure out what happened during a match.
Logging turns debugging from guesswork into data-driven problem solving.
Why Logging Matters in FRC
The Logging Challenge
During a match, your robot runs for only 2-3 minutes. When something goes wrong, you need to quickly understand what happened and fix it before the next match. Without logging, you're debugging blind.
Without Logging
- Guess what went wrong based on driver observation
- Attempt to reproduce issues in the pits
- Waste time debugging problems that already occurred
- Miss subtle performance issues and edge cases
- Struggle to tune PID and feedforward values
With Logging
- Review exact robot state from any match
- Analyze sensor data, motor outputs, and commands
- Identify root causes of failures quickly
- Optimize performance with data-driven decisions
- Tune PID values using real match data
Debug Faster
Tune Better
Improve Continuously
Logging is a Competitive Advantage
Top FRC teams invest heavily in logging because diagnosing and fixing an issue between matches can decide an elimination round.
What Should You Log?
Effective logging captures all relevant robot state while managing data volume and performance impact:
Inputs
- Joystick values and button presses
- Sensor readings (encoders, gyros, limit switches)
- Vision detection results
- NetworkTables values
- Game-specific data (alliance, match number)
Robot State
- Motor outputs (voltage, current, duty cycle)
- Mechanism positions and velocities
- Robot pose (X, Y, heading)
- Subsystem states and modes
- Active commands
Control Signals
- Target setpoints and actual values
- PID error and output
- Feedforward calculations
- Path following targets
- Control loop timing
Balance Detail with Performance
Logging has costs, and too much of it starts to hurt the robot:
- Network bandwidth:Don't spam NetworkTables with high-frequency data
- CPU overhead:Logging shouldn't slow down control loops
- Storage space: Log files can grow large with high-frequency data
- Best practice: Use efficient binary logging formats and appropriate sample rates
The Logging Framework We Use
This workshop uses exactly one: WPILib's built-in DataLogManager, mirroring the 2027 template. Here's what it does, followed by a short vocabulary list of the other framework names you'll hear around FRC, and why we don't use them.
DataLogManager (WPILib Built-in)
Official WPILib data logging system that captures all NetworkTables data to binary .wpilog files. (NetworkTables is WPILib's shared live-data table: the robot publishes values to it, and dashboards and loggers read them.)
Advantages
- Built into WPILib, no additional dependencies
- Automatically logs all NetworkTables data
- Efficient binary format (.wpilog) for compact storage
- Integrated with AdvantageScope for visualization
- Simple setup with one line of code
- Low performance overhead
Limitations
- Only logs data published to NetworkTables
- No built-in replay/simulation capabilities
- Requires manual data publication from code
- Less structured than framework-based approaches
Best For
Teams who want simple, effective logging without additional framework complexity. Ideal for most FRC teams.
Names you'll hear (evaluated, not used here)
Plenty of good teams use these tools, so you should recognize the names, but the workshop and the 2027 template don't use them. Treat this list as vocabulary, not required learning.
- AdvantageKit (Team 6328): a logging framework whose headline feature is deterministic replay, re-running a match log through your robot code in simulation. Getting that requires extending
LoggedRobotand restructuring every subsystem around an IO layer. We record and review logs; we don't re-run them through the code, so the extra machinery would buy us nothing here. - Epilogue (@Logged): WPILib's annotation-based logging (2025+). A reasonable alternative, but DataLogManager plus plain NetworkTables publishing keeps the mental model smallest for a teaching codebase.
- Hoot logging: CTRE's device-side signal log. You already have this one without doing anything: Phoenix 6 devices write a
.hootfile automatically alongside DataLogManager's.wpilog, viewable in Tuner X or AdvantageScope.
One name that is not a logging framework: AdvantageScope is the log viewer we do use. It opens .wpilog and .hoot files regardless of which framework wrote them.
Recommended Approach for This Workshop
Using WPILib DataLogManager
For this workshop we mirror the 2027 template and use WPILib's built-in DataLogManager. It records every NetworkTables value change to a binary .wpilogfile, including everything the drivetrain's telemetry publishes. It also captures console output, and DriverStation.startDataLog adds the Driver-Station and joystick data. There's no extra library to install and no replay layer to learn.
Why DataLogManager?
- Built into WPILib: nothing extra to install, and two lines in
Robot's constructor turn it on - Captures all NetworkTables data automatically (your telemetry plus DS/joystick state) to an efficient
.wpilog - Opens directly in AdvantageScope for graphing and review
- Phoenix 6 devices also log to a
.hootfile readable in Tuner X or AdvantageScope, so you get extra signal data for free - Fewest moving parts, which suits a teaching codebase
What we're NOT using (and why)
- AdvantageKit: its IO-layer / replay model is more than this workshop needs; DataLogManager covers record-and-review
- Epilogue (@Logged): a fine alternative, but DataLogManager + plain NetworkTables publishing keeps the mental model smallest
- Deterministic log replay:out of scope; we record and review logs, we don't re-run them through the code
How it looks
Two lines in Robot's constructor start it (DataLogManager.start() + DriverStation.startDataLog(DataLogManager.getLog())); after that you just publish the values you care about to NetworkTables. The swerve telemetry helper already does this for the drivetrain. The next lesson wires it all up.
A new WPILib Telemetry API is in development
Telemetry.log("name", value) API with pluggable backends for NetworkTables and log files (allwpilib PR #7773). As of mid-2026 it is still an open draft: not merged, not in any 2027 alpha. If it ships, this workshop will likely adopt it in place of hand-rolled NetworkTables publishing. Until then, DataLogManager is the shipped, supported path.Additional Resources
What's Next?
Up Next: Implementing Logging
Robot's constructor, publish your robot state to NetworkTables so it lands in the .wpilog, and open the result in AdvantageScope.