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 an input 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 disallows the event (To prevent situations such as powering off while the car is moving). 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 system will use 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 both monitor the current state of the vehicle and ensure that the proper input events are serviced at the correct times.
For a given FSM, each of its states be assigned a filter function to determine if an event can be passed. When an event is raised, all active FSMs will have the filter functions of their respective current states called, with the event passing if all functions return true. This allows us to control eeping separate the implementations of each state machine.
Power State Machine:
Keeps track of the car's functional state.
...
- Receiver INPUT_EVENT_POWER signal while in brake and neutral.
...
- Receiver INPUT_EVENT_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.
...
Pedal Brake
...
- Receive INPUT_EVENT_POWER while in the off state
- Receive INPUT_EVENT_PEDAL_BRAKE signal while in coast, drive, or cruise control
...
Pedal Coast
...
- Receive INPUT_EVENT_PEDAL_COAST signal while in the brake or drive state
...
- Receive INPUT_EVENT_PEDAL_PRESSED while in the coast state or brake state (Direction state must be in either forward or reverse)
...
- Receive INPUT_EVENT_CRUISE_CONTROL while in coast or drive
Direction 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 INPUT_EVENT_DIRECTION_SELECTOR_NEUTRAL signal while the Pedal FSM is in the brake state
...
- Receive INPUT_EVENT_DIRECTION_SELECTOR_DRIVE signal while the Pedal FSM is in the brake state
...
- Receive INPUT_EVENT_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 INPUT_EVENT_TURN_SIGNAL_NONE signal while either signal is active
...
- Receive INPUT_EVENT_TURN_SIGNAL_LEFT signal while the left signal is inactive
...
- Receive INPUT_EVENT_TURN_SIGNAL_RIGHT signal while the right signal is inactive
Hazard Light State Machine
...
Hazard lights are currently active
...
- Receive INPUT_EVENT_HAZARD_LIGHT signal while hazard lights are off
...
- Receive INPUT_EVENT_HAZARD_LIGHT signal while hazard lights are on
Horn State Machine
...
- Receive INPUT_EVENT_HORN signal while the horn is active
...
- Receive INPUT_EVENT_HORN signal while horn is off
Push-to-Talk State Machine
...
- Receive INPUT_EVENT_PUSH_TO_TALK signal while Push-to-Talk is off
...
- Receive INPUT_EVENT_PUSH_TO_TALK signal while Push-to-Talk is active
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. Essentially, if an event is raised and the states of every FSM are aligned in such a way that all their check functions return true, then the event can be considered safe to run at the current time.
Sequence Diagram
