Is your feature request related to a problem? Please describe.
The commands v3 scheduler sends all data about running and queued commands in a protobuf message, including child/parent relationships and requirements.
Describe the solution you'd like
Have the line graph renderer support the commands v3 scheduler, rendering running commands similarly to discrete fields. Commands could be grouped into rows, with one row per mechanism (multiple commands per mechanism would be stacked vertically), or like a flame graph (could be difficult to visualize, since there are three dimensions [time, mechanism name, and parent])
Rendering on the line graph is very useful for cross-referencing running commands with robot state (eg triggers, sensor data, match time, ...), so line graph support is the most important, in my opinion. Separate views could be useful for displaying command trees in more detail.
Describe alternatives you've considered
Abuse the alerts API in combination with listening to command schedule/exit events to bodge a set of discrete fields to display. However, this wouldn't be able to include mechanism data.
Is your feature request related to a problem? Please describe.
The commands v3 scheduler sends all data about running and queued commands in a protobuf message, including child/parent relationships and requirements.
Describe the solution you'd like
Have the line graph renderer support the commands v3 scheduler, rendering running commands similarly to discrete fields. Commands could be grouped into rows, with one row per mechanism (multiple commands per mechanism would be stacked vertically), or like a flame graph (could be difficult to visualize, since there are three dimensions [time, mechanism name, and parent])
Rendering on the line graph is very useful for cross-referencing running commands with robot state (eg triggers, sensor data, match time, ...), so line graph support is the most important, in my opinion. Separate views could be useful for displaying command trees in more detail.
Describe alternatives you've considered
Abuse the alerts API in combination with listening to command schedule/exit events to bodge a set of discrete fields to display. However, this wouldn't be able to include mechanism data.