Make motor fault handling safer

[mkhlb]

Description of the task

Currently when there is a motor fault, we clear and try starting the motor again a few times. Some of these faults are quite serious and should not be trivially cleared. Furthermore thunderloop crashes and requires an SSH and a reboot. Perhaps we should not always crash thunderloop on a motor fault, so we can monitor and properly clear these faults.

This issue may be a triage until the new year’s motor firmware is in place.

Acceptance criteria

• [ ]

Blocked By

[itsarune]

First step:

• motor.cpp: Thunderloop shouldn't crash if the motors have faulted too many times. It should raise a flag to send to Thunderscope and try to run in 3-wheel mode (in this mode, the robot will execute commands but skip over the motor that has faulted).

[potatoisagender]

To add, I probably need to raise some sort of flag to indicate which motor failed to thunderscope. I may want to implement this as a list, so that we can handle the event of multiple failures. (And distinguish between dribbler and wheel motor failures).

This will likely need a protobuffer.

To start with, I may just want to force the robot with a failing motor into halt_tactic. (need to talk about editing core ai and fsm decision tree).

Then, I'll want to implement a new fsm tactic (maybe limp_tactic?) to limp the robot over to the pit.

I'll probably want to turn off the drivers for the affected motor and keep them off, so the wheel can freespin, and no further damage is caused. (Need clarification on if this is even possible, or if the current motor board doesn't allow this).

There is also the possible need for the pi to turn off the drivers when the robot is in a standby mode (maybe?) so that it isn't burning power keeping the motors at '0' velocity. However, this probably should be in a separate ticket, and might cause some problems given the way I understand how the motors work.

[mkhlb]

Yeah its imperative that the motors arent locked as it can be catastrophic if we try driving while a motor is locked. Thunderscope's decision of what to do sounds a bit out of scope of this issue; it may not be optimal to limp as soon as we go 3-wheels, as 3 wheels still offer us full control in all three coordinates (even 2 motors offer us enough movement to return to the pit!).

Turning off the drivers is a good thing to look into, as I'm doubtful that we can trust writing to the drivers to free the motor once it's already faulting.

[potatoisagender]

The limp mode is an idea, but probably would end up being a separate issue. If we wanted to, we could design separate movement algorithms to achieve some features with 3 motors only, or no dribbler motor, for example.

I'll need to do some research into how to turn off the drivers/free the motors. For now, I'm still working on implementing per motor driver control