Load cell vectoring

[Dopp-IO]

Load cell torque controller

• Distributes torque to wheels proportionally based on sensed normal force
• Load cell values are FIR filtered
• • This requires hardware aliasing filters to work properly
• • Load cell AnalogChannels should be configured with clamping to enforce rationality checking
• • i.e., .clamp = true, .clampLow = // something negative. we don't care about lower bound, .clampHigh = 1000 // choose a rational upper bound on the amount of force we expect to sense on a single load cel

Added ready to TorqueController outputs.

• TCMux ingests ready to determine whether a controller can be selected and whether to fall back to safe mode

[walkermburns]

I can take a look at this more deeply later, but does this 'ready' from torque controller default to safe mode if there is an unset torque controller? i.e. would it fall back to safe mode if the dial was in a position for which we had not written a torque controller lol

[Dopp-IO]

I can take a look at this more deeply later, but does this 'ready' from torque controller default to safe mode if there is an unset torque controller? i.e. would it fall back to safe mode if the dial was in a position for which we had not written a torque controller lol

It should fall back to TC_NO_CONTROLLER, i.e., zero torque request, if the dial is in a position with no torque controller. Since TC_NO_CONTROLLER is always "ready", TCMux should never fall back to TC_SAFE_MODE.

https://github.com/hytech-racing/MCU/blob/3f9309bc64c91bd369d2db93c3e0aeefd09b8e1b/lib/systems/include/TorqueControllerMux.h#L26-L34

https://github.com/hytech-racing/MCU/blob/3f9309bc64c91bd369d2db93c3e0aeefd09b8e1b/lib/systems/include/TorqueControllers.h#L74-L78

[walkermburns]

I see, this is something that we spent a long time debugging when the dial code was finally implemented because we thought the car should work, but the dashboard was no longer reporting dial mode as 0, and no power was being sent to the wheels. We will probably not face this issue again now that we know that it is a possibility, but would there be any harm in changing the default to be 'safe_mode' rather than 'no_controller'?

[Dopp-IO]

Nothing wrong with using safe mode instead of no controller as the default for an unmapped dial state.

On another note, it would be good for the driver to know when safe mode is active since the behavior of the car will change. Are there LEDs on the dashboard we can use for that? It would essentially be a torque controller error LED.

[CL16gtgh]

I see, this is something that we spent a long time debugging when the dial code was finally implemented because we thought the car should work, but the dashboard was no longer reporting dial mode as 0, and no power was being sent to the wheels. We will probably not face this issue again now that we know that it is a possibility, but would there be any harm in changing the default to be 'safe_mode' rather than 'no_controller'?

For now during debugging it should default to no controller, as indicating empty slots for controllers we have not implemented yet, also potentially expose more problems. During comp we should put whatever extra dial modes that we have to a mode that eliminates loss most just in case driver/car trips

[walkermburns]

Looks like the torqueMode issues that you were having were just the result of reading the wrong button from the CAN message. This should now be fixed

[walkermburns]

Cecilia said I could merge. Merging