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 9 Next »

Centre console is the board which contains the main state logic for the entire car’s electrical system. It governs starting the system and controlling the power states, as well as the drive state of the car. When the car is off, this board, along with pedal and power distribution are the only ones which are powered, so that they can be used to start the broader system.

The car is powered on when the power button is pressed. Initially this is “aux power”, which means that car is powered by a supply separate to the main batteries. This means minimal functionality is available, and is good for testing initial startup. If the brake is pressed and the power button is pressed at the same time, the car will enter the main power state, powered by the main electrical system, and full functionality will be available.

TODO:

  • Find out if we want a parked state (Ebrake/parking brake, if manual will it have a sensor?) Not needed
  • How are we handling ack messages?
  • We should write a module to handle monitoring (ie. wait for a repeated event with a timeout)
  • Do CAN messages remain the same or are they cleared after each cycle? They will remain the same unless manually cleared

Inputs

Buttons

  • Power Button

    • Used to control power state, along with pedal

  • P, R, N, D → drive state control buttons

  • Hazard button → Latching, sends message to power distribution to strobe turn lights

  • DRL Lights

Buttons will be handled as gpio interrupts, received as notifications to the relevant fsm tasks. Maybe can block on notifications taking place? (TBD)

CAN messages

  • Pedal - Constantly monitor brake state to determine whether to enter main power state

    • Must receive value within 100MS (Could be certain number of cycles with new architecture)

  • MCI

    • Constantly monitor speed message - Must receive new message within 3 seconds

    • Send pre-charge and wait for complete message with a timeout

  • BMS - Heartbeat Message

    • If not received in 3 seconds, or has errors in message, a BPS fault has occurred

  • ACK messages from Power Distribution, MCI,

Outputs

LED Indicators - All on a I2C Expander for 8 possible outputs

  • CENTRE_CONSOLE_LED_BPS

  • CENTRE_CONSOLE_LED_POWER

  • CENTRE_CONSOLE_LED_DRIVE

  • CENTRE_CONSOLE_LED_REVERSE

  • CENTRE_CONSOLE_LED_NEUTRAL

  • CENTRE_CONSOLE_LED_PARKING

  • CENTRE_CONSOLE_LED_HAZARDS

  • CENTRE_CONSOLE_LED_SPARE,

7-Segment displays (x3)

  • Used for Cruise Control, speed, and battery percentage

Power FSM

The power FSM governs the power state of the car. There are 4 main States:

  • POWER_OFF

  • POWER_MAIN

  • POWER_AUX

  • POWER_FAULT

For the main power states however, when we are transitioning there is a sequence of checks we run to make sure that the system is in a correct state to allow a transition. These steps typically involve sending a CAN message to another system, waiting for it to do its checks and balances and then receiving an acknowledgement (ACK) message. If these checks fail, we will transition back to the normal power state.

The sequence model for these states is along the following lines:

  • All steps must be executed successfully before a transition can take place

  • If a step fails, we should handle the error and remain in the current state

The diagram is shown below, hexagons representing the sequence steps. The states themselves have no real functionality in their output functions.

The following represent a

Power Aux Sequence

  1. Transmit CONFIRM_AUX_STATUS and receive ack OK

    1. checking any aux faults before enabling power

    2. Sent to power select, which checks for aux faults. Will reply with OK if everything is good

  2. Transmit TURN_ON_EVERYTHING and receive ack OK

    1. Sent to power distribution, which turns on outputs needed for aux state

Power Main Sequence:

Power main sequence needs to send the following messages and receive an ack for each.

  1. confirm_aux_status

    1. Tell power select to check any aux faults before enabling power (Maybe not needed in main seq?)

  2. Turn on bms, wait for ack

    1. Tell Power distribution to power on BMS board (do this separately to run independent bms checks)

  3. confirm_battery_status

    1. Battery checks, waits for ack

  4. close_battery_relays

    1. Transmits to BMS to close relays

  5. confirm_dcdc

    1. Power Select confirms DCDC

  6. turn_on_everything

    1. Power Distribution enables all boards

  7. power_main_complete

    1. Sends “ready to drive” to MCI

    2. Start BPS watchdog

Power Off Sequence:

  1. Discharge Precharge

    1. Send message to MCI to discharge precharge

  2. Turn Off everything

    1. Tell Power distribution to turn off the relevant boards

  3. Open Relays (Transition to fault on BPS Fault)

    1. Tell BMS to open the relays (receive ack)

Fault

  • This state covers a BPS fault during operation. It occurs if we receive a message from BMS saying that we have a fault condition, or a timeout occurs on the BPS heartbeat message

    • If a message is received saying that a fault has occurred, then we can attempt to handle the specific fault

    • If a BPS timeout has occurred, we must discharge MCI and loop until BPS communication resumes, or the car is power cycled.

    • BPS indicator is on during this time (and hazard lights flash as well I believe)

Drive FSM

The Drive FSM handles the control of drive state of the car. It receives the drive buttons (Neutral (N), Drive (D), Reverse(R), Parking (P)) and runs the preparations and checks needed to change the drive state of the car, and communicate this value with the motor controllers. One of these preparations is MCI Precharge.

The following conditions need to be met when changing the drive state

  • Successfully precharge (receive ack) MCI before going into a drive state (D or R)

  • Discharge MCI when exiting a drive state (to park or fault)

    • Neutral should stay charged

If a fault condition occurs, we should exit back to neutral and indicate failure.

State Input Functions:

All the following must be met for a transition to happen from the following states

Neutral → Drive

  • Drive button has been pressed (neutral state)

  • Power state is POWER_MAIN (neutral state)

  • Speed state is stationary (speed >= 0) (neutral state)

  • Get precharge state (state 1)

    • if state is down (not charged) go to state 2

    • else go to state 3 (is charged)

  • Turn on Pre-charge and get ack (state 2)

  • Transmit REVERSE state to MCI, receive ACK (state 3)

  • If either step fails, return to neutral

Neutral → Reverse

  • Drive button has been pressed (neutral state)

  • Power state is POWER_MAIN (neutral state)

  • Speed state is stationary (speed <= 0) (neutral state)

  • Get precharge state (state 1)

    • if state is down (not charged) go to state 2

    • else go to state 3 (is charged)

  • Turn on Pre-charge and get ack (state 2)

  • Transmit REVERSE state to MCI, receive ACK (state 3)

Drive → Neutral

  • Neutral button or force (sent by power fsm) or drive_state != main (drive state)

  • Transmit NEUTRAL state to MCI, receive ACK (state 1)

Reverse → Neutral

  • Neutral button or force (sent by power fsm) or drive_state != main (drive state)

  • Transmit NEUTRAL state to MCI, receive ACK (state 1)

Centre Console Communications:

To MCI:

Current drive state, (forward, reverse, cuise, off?)

cruise target velocity, ignored if not in cruise.

  • No labels