Internal State Machine (Planning)

[nwdepatie]

This is the beginning of a more complex architecture change, where we should have an internal state machine to make sure that we have a robust sense of what state the car is in. last year, we had some different mode (reverse, speed limiting, performance, efficiency) and I'm not sure if we want to add any more modes in. Since we have a lot of modes and might add more in, we need to make sure that the way we make the state machine is extensible and forces developers to account for edge cases during development.

This ticket pertains to the general architecture of how we are going to do this. Should we change the function pointers that tasks are pointing to? Should it just be a bigass switch statement in each task that this is relevant to?

[nwdepatie]

Preliminary State diagram of car to go off of

[HamzaIqbal69]

I think function pointers would probably be a cleaner way to do it

[nwdepatie]

Reference Shepherd SM for more info https://github.com/Northeastern-Electric-Racing/shepherd_bms/blob/main/shepherd_bms/include/stateMachine.h

[nwdepatie]

[nwdepatie]

This will be a hierarchical state machine, meaning that there will be a Cerberus State, one of which can be Drive. Drive will have multiple sub states. I think that we can probably make Charging a sub state in a similar manner.

[nwdepatie]

[nwdepatie]

Note that we are charging the accumulator out of the car so we need to make sure that we don't attempt to turn the car on if the acucmulator is out, and if the accumulator is detected as being pulled out we need to turn off car as a fault

[nwdepatie]

More reference, here is the MPU's state diagram from last year