Why do we need to log?
Our robot is a completely separate machine, as because of that, it is incredibly hard to debug code without any information of what it happening. Especially in cases of mechanisms not working, it is a nightmare to try to figure out why the elevator didn't reach its setpoint without being able to see the position of the elevator motor, the PID setpoint, and other information like that. Logging is the process of storing information about the different systems on the robot, whether it is saving to a file or sending it over the network in real time to be viewed on someone's laptop.
Technologies
NetworkTables
NetworkTables is FRC's software to send and receive data over the network. It operates as a publisher-subscriber model, and the server is run as part of the robot code. NetworkTables is used everywhere, from AdvantageScope using it to show metrics in real time, or the Limelights using it to send and receive data and configuration for the camera.
AdvantageScope
AdvantageScope is the programmer's best friend when it comes to debugging the robot. It is essentially a pretty log viewer over the raw NetworkTables fields sent by the robot. It has the ability to display the fields in a line graph, tables, 2D fields, swerve speeds and module states, and even a 3D field with vision targets and game pieces.
Elastic
Elastic is one of many ways that the drive team can interact with the robot during matches. As opposed to AdvantageScope, which is mainly used for debugging, Elastic is used for quickly interacting with widgets such as dropdowns, booleans, and simply statuses (for the most part sending "configuration" over to the robot). In the past, we used SmartDashboard or Shuffleboard, but Elastic is the nicest looking and the best maintained.
NetworkTables in Code
WPILib provides a NetworkTables API that we are able to use in code. However, for the most part, we use a function called InitSendable . This is an abstract function provided by wpi::Sendable that automatically logs subsystems and their children. It is essentially a wrapper over raw NetworkTables API usage. In InitSendable , you will see a lot of AddDoubleProperty or AddBooleanProperty or something similar. These are essentially registering getters and setters that are run every period to log variables to NetworkTables and handle information that NetworkTables gave us.
However, you may notice that we do use raw NetworkTables sometimes, primarily with sending structs. This is because InitSendable does not contain an AddStructProperty (I don't know why), and it means that we can't publish structs the same way we do for the other fields. It is a hassle to publish field using raw NetworkTables, and we are looking into replacing it with something better.
Finding the Balance
I told you that it is important to log fields, but it is also important not to log too much. This is mainly because logging field takes up CPU time. The RoboRIO is not a powerful system at all, and logging fields could literally take over 10 milliseconds, which is a big problem given that the default loop period is 20 milliseconds. Many times, before we cleaned up the fields that we logged, we would see a Command Scheduler Loop Overrun because the logging would take over 20 milliseconds. Additionally, and while this isn't as big as an issue, logging that many fields takes up network bandwidth and hard drive space.
TLDR: Make sure you think about whether the field you are logging can actually be used for debugging, or if it is redundant or completely useless. For example, logging the CAN bus of the motors is completely unnecessary - we already tell it through a constant in code.
Vlogger and Dashboarding
Vlogger was a custom tool that we made that provides an API to read multiple sources of logging through one streamlined API. It is mainly a backend tool that is used for our dashboarding software.
As part of reducing the time spent debugging in the Pit, we wanted to find a way to check repetitive information during the match. For example, in the 2025 season, it would be nice to automate the task of checking for any anomalies in the auto align instead of having the pit programmer load up the log and scroll through the whole match. In general, we wanted an overview of what went wrong and what went well during the match so that the pit programmer could focus his debugging on actually concerning parts of the match. For this reason, we created ValorDashboard . This is a Streamlit app that uses Vlogger as its backend to load the logs and run it through a processor that can graph it and identify concerning points.