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 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 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 system will use a series of Finite State Machines 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.

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.

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.

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

Horn State Machine

Push-to-Talk State Machine