You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working with the Command framework in WPILib, our team has found it useful to log the current state of command compositions to a log file for debugging purposes. Being able to track the currently running command alongside other key data (like motor measurements, odometry, and behaviors) can be crucial for identifying issues and analyzing the robot’s behavior. However, there is currently no simple way to do this in the framework.
There are alternative ways to do this, such as creating a command that logs a string and placing it between composed commands. We have done this, however, it becomes very inconvenient to manage this logging, and an integrated callback, similar to the logging callbacks through SysId, would be amazing to have. This would simplify, and create more idiomatic code for teams.
The text was updated successfully, but these errors were encountered:
Most of the discussion I see there is stating that it would be a struggle to implement some sort of simple ".logged()" factory method. Which I agree with, however allowing the user to have a callback with a command object, it allows the user to specify how they use that data, and how to log it. So they could log the name of the class, or categorize it in any way they like. Is there something I'm missing?
While working with the Command framework in WPILib, our team has found it useful to log the current state of command compositions to a log file for debugging purposes. Being able to track the currently running command alongside other key data (like motor measurements, odometry, and behaviors) can be crucial for identifying issues and analyzing the robot’s behavior. However, there is currently no simple way to do this in the framework.
There are alternative ways to do this, such as creating a command that logs a string and placing it between composed commands. We have done this, however, it becomes very inconvenient to manage this logging, and an integrated callback, similar to the logging callbacks through SysId, would be amazing to have. This would simplify, and create more idiomatic code for teams.
The text was updated successfully, but these errors were encountered: