Driver Control Software

Overview

The objective of 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 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:

Pin Assignments

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.

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.

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.

Turn Signal State Machine

This state machine governs the states of the turn signals made by the driver. Independent from the other FSMs.

Hazard Light State Machine

Possible State Transition Solutions

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.