Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 36 Next »

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

IO initialization has been split into two separate modules for both digital and analog devices.

Input Handling

Once an event has been generated, it will be stored inside a global event queue until it is time to process the event. The system will use FSM arbitration to events will be stored inside a global event queue until 

Pin Assignments

Input DevicePin
PowerPC0
Gas PedalPA1
Direction Selector ForwardPC2
Direction Selector ReversePC3
Cruise ControlPC4
Cruise Control IncreasePC5
Cruise Control DecreasePC6
Turn Signal RightPC7
Turn Signal LeftPC8
Hazard Light SwitchPC9
Mechanical BrakePA10

Handling Inputs

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  

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.

StateDescriptionTransition
OffThe vehicle is off
  • Receiver POWER signal while in brake and neutral.
OnThe vehicle is on
  • 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.

StateDescriptionTransition

Brake

The car is on, but braking is active
  • Receive POWER signal while in the off state
  • Receive GAS_BRAKE signal while in coast, drive, or cruise control

Coast

The gas pedal is pressed just enough to allow the car to coast.
  • Receive GAS_COAST signal while in the brake or drive state
DriveThe brakes are engaged and the car is not moving
  • Receive GAS_DRIVE while in the coast state or brake state (Direction state must be in either forward or reverse)
Cruise ControlThe car is currently in cruise control mode
  • 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.

StateDescriptionTransition
NeutralThe vehicle is in neutral gear
  • Receive DIRECTION_SELECTOR_NEUTRAL signal while the Pedal FSM is in the brake state
ForwardThe vehicle is in forward gear
  • Receive DIRECTION_SELECTOR_FORWARD signal while the Pedal FSM is in the brake state
ReverseThe vehicle is in reverse
  • 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.

StateDescriptionTransition
No signalThe car is currently not signalling
  • Receive TURN_SIGNAL_NONE signal while either signal is active
Left signalThe car has the left signal active
  • Receive TURN_SIGNAL_LEFT signal while the left signal is inactive
Right signalThe car has the left signal active
  • Receive TURN_SIGNAL_RIGHT signal while the right signal is inactive

Hazard Light State Machine

StateDescriptionTransition
Hazard Light On

Hazard lights are currently active

  • Receive HAZARD_LIGHT_ON signal while hazard lights are off
Hazard Light OffHazard lights are currently inactive
  • 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

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.

  • No labels