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.
Key Concept: Comprehensive logging transforms debugging from guesswork into data-driven problem solving.
Why Logging is Critical 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 Comprehensive Logging
- Replay 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 data logging infrastructure. Being able to quickly diagnose and fix issues between matches can mean the difference between winning and losing in elimination rounds.
Modern logging frameworks make it easier than ever to capture comprehensive data without impacting robot performance.
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
While comprehensive logging is valuable, excessive logging can impact robot performance:
- 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
Comprehensive logging and replay framework developed by Team 6328 (Mechanical Advantage). Industry-leading solution for advanced teams.
✅ Advantages
- Deterministic replay: Re-run robot code with logged data
- Hardware abstraction: IO layer separation for testability
- Comprehensive capture: All inputs/outputs logged automatically
- Time-travel debugging: Step through logged matches
- Simulation support: Test code without hardware
- Integrates with AdvantageScope for visualization
⚠️ Limitations
- Significant code restructuring required
- Steeper learning curve for implementation
- Requires understanding of IO layer pattern
- More complex setup and maintenance
- Best adopted at start of season, not mid-season
🎯 Best For
Advanced teams who want deterministic replay, time-travel debugging, and comprehensive testing capabilities. Requires significant investment in code architecture.
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
- Integrates seamlessly with AdvantageScope
- 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 using WPILib 2025+ who want comprehensive logging with minimal code. Perfect for teams 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 | Complex - Major restructure | Easy - Simple integration |
| Learning Curve | Minimal | Minimal | Steep | 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 | Most teams, simple logging | Java teams, minimal boilerplate | Advanced teams, comprehensive testing | CTRE-focused teams |
Recommended Approach for This Workshop
📊 Using DataLogManager + Epilogue
For this workshop, we'll use a combination of WPILib's DataLogManager and Epilogue for structured annotation-based logging. This provides:
Why DataLogManager?
- Simple setup with minimal code changes
- Automatic capture of NetworkTables data
- Official WPILib support and maintenance
- Works with AdvantageScope for visualization
Why Add Epilogue?
- Zero boilerplate with @Logged annotations
- Automatic structured logging of subsystems
- Compile-time code generation (no runtime overhead)
- Built into WPILib 2025 - no extra dependencies
Future Considerations
As your team's sophistication grows, consider migrating to AdvantageKit for deterministic replay and comprehensive testing. However, start simple with DataLogManager + Epilogue to build good logging habits before adopting more complex frameworks.
Additional Resources
What's Next?
Up Next: Implementing Logging
Now that you understand the logging framework options, you'll implement DataLogManager and Epilogue in your robot code to capture telemetry.