Command-Based CAN Bus Overutilization

[kestrel]

We’re having some trouble with controlling motors in a command-based robot. When doing something like this, where m_drive is a CANSparkMax controller:

setDefaultCommand(Commands.run(() -> m_drive.set(1.0)));

We are having issues where this line floods the CAN bus, leading to timeout errors.

We were thinking about something like this:

setDefaultCommand(Commands.runOnce(() -> m_drive.set(1.0)));

Does the InstantCommand get run every time the default command is scheduled, or is it only run a single time ever?

Is there a suggested paradigm for how to do this that other teams are using?

[Oblarg]

Does the REV library really send a new CAN message every call even if the value isn’t changing?

runOnce runs once when scheduled. It will run again if you schedule it again. It’s not appropriate for a default command, though, because default commands should never end - instead, do a runOnce and then a nonterminating empty run.