Skip to content

Logging and dashboards

AdvantageKit is the source of truth. Dashboards are views of that truth.

That distinction matters. If a value is published only through a direct NetworkTables publisher, it may look fine on a dashboard while being missing or inconsistent in replay. For this template, normal telemetry should flow through AdvantageKit.

What to use

Use these APIs:

Logger.processInputs("Drive/Gyro", gyroInputs);
Logger.recordOutput("Robot/Auto/Selected", selectedName);
Logger.recordOutput("Robot/Navigation/Active", active);

Use LoggedDashboardChooser for autonomous selection.

Use WPILib Alert for driver-relevant faults such as disconnected cameras or hardware health problems.

What not to use for normal telemetry

Do not create direct publishers like this for ordinary robot telemetry:

NetworkTableInstance.getDefault().getStringTopic("Robot/Auto/Selected").publish();

That bypasses the logging/replay path. The AdvantageKit NT4 publisher already exposes logged outputs to NT4 dashboards.

Direct NetworkTables access is acceptable when NetworkTables is the protocol for a device or external service, such as Limelight-style IO. That is different from dashboard telemetry.

Naming topics

Keep topic names stable and boring. Good logs are easy to search.

Recommended top-level groups:

  • Robot/... for dashboard-facing summary aliases
  • Drive/... for drivetrain IO and state
  • Vision/... for detailed camera observations
  • Auto/... for autonomous internals
  • mechanism names such as Intake/..., Arm/..., Elevator/...

Avoid renaming topics during an event unless the old name is actively wrong. Dashboards, log review habits, and tests often depend on stable names.

Dashboard topic contract

No Elastic layout is committed. Build your dashboard externally around these logged NT4 values:

  • Robot/Auto/Selected
  • Robot/Auto/Valid
  • Robot/Localization/Pose
  • Robot/Navigation/Active
  • Robot/Navigation/Goal
  • Robot/Vision/Camera0/Connected
  • Robot/Vision/Camera1/Connected
  • Odometry/Robot
  • Vision/Summary/RobotPosesAccepted
  • Vision/Summary/RobotPosesRejected
  • Drive/Gyro
  • Drive/Module0
  • Drive/Module1
  • Drive/Module2
  • Drive/Module3
  • SwerveStates/Measured
  • SwerveChassisSpeeds/Measured

Add mechanism topics as mechanisms are implemented. Document them near the subsystem so the dashboard does not become tribal knowledge.

Logs on the robot

Real robots should write WPILOGs to USB. Check that logs exist before you need them. A missing log after a failed match is a process bug.

Before an event:

  • test USB logging
  • confirm timestamped logs are created
  • open a log in AdvantageScope
  • verify drivetrain, vision, auto, command, and battery data are present

Replay

Replay should not touch real hardware. That is why replay uses no-op IO implementations.

Replay is useful for:

  • checking derived outputs
  • reviewing estimator behavior
  • debugging command decisions
  • validating dashboard aliases
  • comparing code changes against a recorded match

Do not add hardware calls to constructors or commands that make replay require a robot.

Driver-facing alerts

Use alerts for things the drive team or pit crew should know:

  • camera disconnected
  • gyro missing
  • module hardware not connected
  • invalid autonomous selection
  • brownout or power health concerns

Do not alert for every internal tuning detail. Too many alerts train people to ignore all alerts.

Reviewing a log

When something goes wrong, I usually check in this order:

  1. Battery voltage and brownout state.
  2. Enabled/disabled timeline.
  3. Command scheduler timeline.
  4. Robot pose and measured chassis speeds.
  5. Module measured states vs setpoints.
  6. Gyro yaw and angular velocity.
  7. Vision accepted/rejected observations.
  8. Auto or navigation selected state.
  9. Mechanism inputs and setpoints.

This order prevents chasing vision or controller gains when the real issue is power, geometry, or command scheduling.