Overview
The objective of for the driver input system is to wait on the events generated by the attached input devices and use those events to broadcast the relevant message to the correct subsystem. Since the events will, for the most part, be user-initiated, using interrupts is the ideal way to handle incoming events. A series of finite state machines will be used to monitor the current state of the vehicle based on the actions generated by each event.
Driver Inputs
IO Initialization
To simplify device setup, two separate modules have been created to take care of IO initialization for both digital and analog inputs. A configuration file has also been set up to define the addresses used for each device.
In addition, since the type of ISR needed to handle an input event will depend on whether the input is digital or analog, the responsibility for handling the events for particular device will fall onto either the digital or analog module, depending on the device.
Input Handling
Since input commands are to be made by the user, the events will be handled through the ISRs. The idea is to use the triggering address to correctly identify the raised event, and then raise it in a global event queue.
Once an event is popped from the queue in the main loop, it must be processed with the correct FSM. Additionally, we must also ensure that a given event is not processed if any of the FSMs are in a state that disallow the event. However, this approach can create dependencies between FSMs, which can result in coupled implementations. To avoid this, an event arbiter is used to see if an event can controls firmware is to create a robust system capable of both properly keeping track of the state of the vehicle when responding to user inputs, as well as being able to send out the correct messages to other subsystems of the car.
The driver controls system works by waiting for the user to take an action such as a button press, which will then be used to construct an event to push to a global queue. When the event is ready to be raised from this queue, the system observes the current state of the car to determine whether the event is safe to be processed at the current time. The event arbiter works by looking at the current state of each active state machine and determining whether the event can be processed. This can be thought of as similar to a Caesar Cipher, where the correct alignment of states is needed for the event to be passed.
Through this approach, we can filter out events while also eliminating dependencies between different state machines.
CAN Data Scheme
Until a sufficient protocol can be defined for sending driver input data over CAN, we will be using the following dummy scheme for the event data field:
...
Finite State Machine
The program will be controlled through the use of multiple Finite State Machines to ensure that inputs are only serviced at the appropriate periods.
Within the state machines used in this system, there exist transitions that depend on the current states of other state machines. As 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.
...
- Receiver POWER signal while in brake and neutral.
...
- Receiver POWER signal while in the off state.
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.
...
Brake
...
- Receive POWER signal while in the off state
- Receive GAS_BRAKE signal while in coast, drive, or cruise control
...
Coast
...
- Receive GAS_COAST signal while in the brake or drive state
...
- Receive GAS_DRIVE while in the coast state or brake state (Direction state must be in either forward or reverse)
...
- Receive CRUISE_CONTROL_ON while in coast or drive
Directional State Machine
This state machine governs the possible gear shifts made by the user. Transitions in the pedal state machine depend on the current state of this FSM.
...
- Receive DIRECTION_SELECTOR_NEUTRAL signal while the Pedal FSM is in the brake state
...
- Receive DIRECTION_SELECTOR_FORWARD signal while the Pedal FSM is in the brake state
...
- Receive DIRECTION_SELECTOR_REVERSE signal while the Pedal FSM is in the brake state
...
Turn Signal State Machine
This state machine governs the states of the turn signals made by the driver. Independent from the other FSMs.
...
- Receive TURN_SIGNAL_NONE signal while either signal is active
...
- Receive TURN_SIGNAL_LEFT signal while the left signal is inactive
...
- Receive TURN_SIGNAL_RIGHT signal while the right signal is inactive
Hazard Light State Machine
...
Hazard lights are currently active
...
- Receive HAZARD_LIGHT_ON signal while hazard lights are off
...
- Receive HAZARD_LIGHT_OFF signal while hazard lights are on
Possible State Transition Solutions
...
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
...
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.If an event is raised at an unsafe time (i.e. flooring it while in neutral), then the event will be discarded.
To monitor the current state of the car, a series of Finite State Machines is used to monitor each input device. The different states of each FSM have a corresponding check function, which can be used to approve or decline an event according to it's current state. An event arbiter module is then used to run the check functions of all active FSMs, and the event is only processed if they all determine the event to be safe to run.
Once a given event is processed, the FSMs change state to reflect the event. A CAN message is then sent to the relevant subsystem based on the data held in the event.
Sequence Diagram
