...
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 FSMsAs a result, an event must be ok'd by all active FSMs before a transition can be made. This way, dependencies between different FSMs can be supported while keeping separate the implementations of each state machine.
Power State Machine:
Keeps track of the car's functional state.
...
State | Description | Transition |
---|---|---|
Off | The vehicle is not receiving power |
|
Brake | The car is on, but braking is active |
|
Coast | The gas pedal is pressed just enough to allow the car to coast. |
|
Drive | The brakes are engaged and the car is not moving |
|
Cruise Control | The car is currently in cruise control mode |
|
Directional State Machine
...
State | Description | Transition |
---|---|---|
Neutral | The vehicle is in neutral gear |
|
Forward | The vehicle is in forward gear |
|
Reverse | The vehicle is in reverse |
|
Turn Signal State Machine
...
Combine pedal state and direction state into one FSM | This option will eliminate the FSM interdependence as well as allow for the elimination of the state IDs. However, the resulting FSMs would become much more complex, and there may exist better solutions. |
Use boolean array to record active states | Would eliminate FSM dependencies and state IDs and allow us to refer to the array to observe the needed states. However, it would make changes could become difficult to make. Also, the boolean would need to be globally exposed for modification by the FSMs |
Give each state a list of forbidden events | Each state's output function will take an event ID as an input and return true if the event ID does not appear in a given list of forbidden IDs. Once an event has been popped from the event queue, all FSMs will run this function. All results must be true for the event to be processed. This solution would eliminate the dependencies between FSMs, as well as the need for state IDs. Additionally, this list of forbidden id would be private to each state, meaning that changing this list would be very easy to do without alterations to any other part of the program. |
Additionally, it may be useful to have the FSMs stored in an array rather than in the fsm_group struct. This will allow us to iterate through the active fsms and make it easier to do operations on multiple ones at once.
Driver Inputs
SMT32F0 Interrupts
...
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. 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.
The prototype of the system used a switch statement to determine the correct event to raise. However, given the amount of inputs that the system will need to serve in the future, using individual callbacks may