The purpose of lights control boards is to receive instructions from the driver controls board through a CAN message and take action accordingly. There are two lights boards on the car. One board is located at the front and one at the back. The boards will use the same software. Thus, software needs to determine which board it's being operated on. The responsibilities of each board is as follows:
Front Board:
- Headlights: control the TESLA headlights.
- Left and Right Signals: Blink the left and right signals.
- Hazard: blinking signals for hazard.
- Horn: for activating (honking) the horn.
Rear Board:
- Brake Lights: Control the brake lights
- Strobe Light: Blink the strobe light in case of emergency.
- Left and Right Signals
- Hazard
Challenges:
| Description | Solution |
|---|---|
| How to detect whether it's the front board or the rear board? | There will possibly be a gpio address that we'll be able to read from. |
| How to sync both the front and the back board when blinking? The timer on both boards will not be identical so some communication needs to happen between the boards to make sure they're both blinking at the same time. | Implementation of this solution should be a module that's independent from the rest of the program. e.g: The state machine logic for signals and hazard should simply make function calls and not worry about keeping the boards in sync. One board probably will need to send a can message to the other board, and both boards will reset their timers. This doesn't have to happen too frequently, probably every couple seconds. |
Functional Block Diagram:
Modules:
- lights_can:
- Its main responsibility is to solely receive can messages and raise events.
- Is the only module that knows about whether software is at the front board or the back board.
- The only occasion where it sends a can message is a sync signal to the other board.
- main: This module only contains a main loop where it gets the raised events from lights_can and passes them to the next three modules: strobe, simple_peripherals, and signals_fsm. Every module checks if it owns the event that is passed to it and processes it. If the event is not related to the module, the module ignores it.
- simple_peripherals: Used for all the peripherals which have a simple on, or off state. These peripherals are: horn, headlights, and brake lights.
- strobe: Uses a blinker object to blink the strobe light.
- signals_fsm: Contains the FSM of the signals. Every often calls send_sync from lights_can to sync the two boards. Uses blinker for blinking the signals.
- blinker: Basically handles all the overhead related to using soft timers.
- lights_gpio:
- Is the only module that knows about all the addresses.
- Can be thought of the only part where the boards actually take action?!
- strobe, signals_fsm, and simple_peripherals all call its lights_gpio_set() function to change the state of the lights.