...
Within the state machines used in this system, there exist transitions that depend on the current states of other state machines. However, since the current FSM API does not provide a way to view the current state outside of string comparisons, a wrapper struct will be used to hold both the FSMs as well as their current states. In addition, the code defining each FSM has been split up, which will make it easier to add new FSMs in the future if needed. As of now, the driver input system is controlled by four FSMs.
Power State Machine:
| State | Description | Transition |
|---|---|---|
| Off | The vehicle is off |
|
| On | The vehicle is on |
|
Pedal State Machine:
This state machine governs the running state of the car and defines the conditions under which the driver can turn on and move the vehicle. Transitions for this FSM depend on the state of the directional state machine.
...
The driver control inputs will be connected to onboard GPIOs. As we are only concerned with handling each input as they are triggered, most of the inputs will be set to be handled through the use of a common ISR (for the prototype, we will collect information on the gas pedal through polling).
Once the ISR initiates, the pin that triggered the request is debounced and the ISR determines the proper event to process based on the debounced state of the pin. For the prototype, this has been implemented through the use of switch statements. However, as more work is done on the system and the amount of input devices increases, there may be a need to add additional functions to delegate the different input requests to, since it would keep the code cleaner and modular as well as easier to debug.
After determining the proper event to process, the ISR will go through another switch statement to ensure the event is handled by the proper state machine, after which the status of the system will be displayed as a text output. We later intend to output this information to CAN. The ISR will then look at the debounced state of the triggering input device and raise the proper event in the event queue. The event queue will then be used to send the necessary messages over CAN and I2C.