Logging Options
Data Logging - Understanding What Happened
Data logging captures robot telemetry, sensor values, and system state during operation. This data is essential for debugging issues, analyzing performance, tuning mechanisms, and understanding 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 operates 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
FRC Logging Framework Options
Several logging frameworks are available for FRC teams. Each has different features, complexity, and use cases:
DataLogManager (WPILib Built-in)
Official WPILib data logging system that captures all NetworkTables data to binary .wpilog files.
✅ 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.
AdvantageKit
Logging, telemetry, and replay framework developed by Team 6328 (Mechanical Advantage). The Logger can be used on its own as a drop-in telemetry sink, or with the optional IO layer to unlock deterministic replay.
✅ Advantages
- One API, two outputs:
Logger.recordOutput(...)writes to both NetworkTables and a.wpilogfile - Free built-in capture: DriverStation, joysticks, alerts, console, PDP/PDH, CAN, battery, and loop timing — no code required
- Rich type support: Pose2d/3d, ChassisVelocities, SwerveModuleState, units, custom record structs
- @AutoLogOutput annotation for zero-boilerplate logging of fields and getters
- Optional replay path: add the IO layer later to unlock deterministic match replay in simulation
- First-class integration with AdvantageScope
⚠️ Considerations
- Requires extending
LoggedRobotinstead ofTimedRobot - Vendordep + one annotation processor entry in
build.gradle - USB logging on a real robot needs a FAT32-formatted USB stick plugged into the roboRIO
- Full deterministic replay does require restructuring subsystems around the IO layer — that piece is optional and not covered in this workshop
🎯 Best For
Teams who want the cleanest logging API in FRC today, strong type-aware output recording, and the option to grow into deterministic replay later without rewriting their telemetry.
Hoot Logging
Lightweight logging framework specifically designed for CTRE Phoenix 6 and modern FRC hardware.
✅ Advantages
- Optimized for Phoenix 6 signals and CTRE hardware
- Automatic capture of motor controller telemetry
- Low overhead with efficient signal logging
- Simple API for custom logging
- Outputs to .wpilog format
- Works well with CANivore high-frequency data
⚠️ Limitations
- Focused primarily on CTRE ecosystem
- Less comprehensive than AdvantageKit
- Smaller community and documentation
🎯 Best For
Teams using CTRE Phoenix 6 hardware who want optimized logging for motor controllers and CANivore devices.
WPILib Epilogue (Java Only)
Annotation-based logging framework built into WPILib 2025+. Automatically generates logging code at compile time using the @Logged annotation.
✅ Advantages
- Zero boilerplate: Add @Logged annotation, get automatic logging
- Built into WPILib - no additional dependencies
- Generates efficient logging code at compile time (no runtime overhead)
- Logs to NetworkTables and DataLog automatically
- Works with AdvantageScope out of the box
- Configurable timing (defaults to 50Hz offset from robot loop)
- Performance metrics logged to NetworkTables
⚠️ Limitations
- Java only (not available for C++ or Python)
- Requires WPILib 2025 or later
- Only available for teams using annotation processing (Gradle default)
- Less control than manual logging approaches
- New in 2025 - still maturing
🎯 Best For
Java teams on WPILib 2025+ who want the simplicity of DataLogManager with better structure and less manual code.
Logging Framework Comparison
| Feature | DataLogManager | Epilogue | AdvantageKit | Hoot Logging |
|---|---|---|---|---|
| Setup Complexity | Very Easy - One line | Very Easy - Annotations | Easy (logging-only) / Complex (with replay) | Easy - Simple integration |
| Learning Curve | Minimal | Minimal | Low (logging-only) / Steep (with replay) | Moderate |
| Performance Impact | Very Low | Very Low (compile-time) | Low (when properly configured) | Very Low |
| Data Capture | NetworkTables only | Annotated classes | Comprehensive (all I/O) | Focused on CTRE devices |
| Replay Capability | No (visualization only) | No (visualization only) | Yes (deterministic) | Yes (limited) |
| Visualization | AdvantageScope | AdvantageScope | AdvantageScope | AdvantageScope or Tuner X |
| Community Support | WPILib official | WPILib official | Strong (Team 6328) | Growing |
| Best Use Case | Workshop choice — simple, captures all NT | Java teams, minimal boilerplate | Rich types, optional deterministic replay | CTRE-focused teams |
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 — including everything the drivetrain's telemetry publishes — to a binary .wpilog file, plus console output and (via DriverStation.startDataLog) the Driver-Station and joystick data. There's no extra vendordep, no LoggedRobot, and no replay layer to learn.
Why DataLogManager?
- Built into WPILib: no vendordep, 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.