2020-05-04 Firmware Meeting notes

Owned by Jess Douglas Muir (Deactivated)
May 05, 2020
4 min read

Overview

Date

  • May 4th, 2020

Meeting Goals

  • Go through every project going on in firmware and break them down into modules/tasks

  • Come up with a list of tasks assignable to new members (post software 101)

  • Be able to clean up the JIRA

Participants

  • @Jess Douglas Muir (Deactivated) , @Andrew Guo (Unlicensed) , @Micah Bai (Unlicensed) , @Brian Nguyen (Deactivated) , @Hewitt McGaughey , @Jarvis Weng , @Mitchell Langdon Ostler , @Ryan Dancy , @Gerald Aryeetey (Deactivated) , @Avery Chiu

Notes

Intro

  • Being on Midnight Sun is first and foremost about learning

  • Coming up with new member tasks and going through the projects will help everyone understand the car better

Workflow overview for MS14 firmware

  1. High level design: What does it do? What components help it do that?

  2. Detail design: What specifically does each component need to do?

  3. Implementation: What code implements the required behaviour?

  4. Unit testing: How can you prove the code does what you say it will?

  5. IO testing: How can you demonstrate the firmware behaves correctly on hardware?

  6. Integration testing: How can you demonstrate the firmware interacts with other components correctly?



Hardware mini status update (From @Micah Bai (Unlicensed) )

No integration testing because the school is closed for the spring term.

IO testing can be done in limited capacity by hardware members bringing up the boards at home.

For new members, we need to determine how to do remote tutorials. We could ask people to buy dev boards? Need to look into simulating.

Ongoing projects

Table: list of projects and their breakdowns. Modules in bold have not been implemented yet.

Project

Owner

Details

Status / Dates

Front Power

Ryan

Purpose

  • To manage turning on and off power to the other boards and lights, and broadcast current they’re drawing

Modules

  • Can_rx_event_mapper

    • Receives CAN messages and raises events specified in the config

  • Current_measurement

    • Measures current from the bts7200 and bts7040 chips specified in config

  • Gpio

    • Takes events and turns on/off gpio pins as specified in config

  • Publish_data

    • Takes current measurements from current_measurement and publishes them over CAN

  • Rear_power_distribution_strobe_blinker

    • Uses blink_event_generator to generate events blinking the strobe light on rear

  • Lights_signal_fsm

    • Controls blinking the left/right signal lights on both front and rear

Implementation is nearly complete, unit tested almost complete



To finish integration testing this term

Rear Power

Ryan

Same as front power

To finish integration testing this term

Power Selection

Jarvis

Purpose

  • Check the aux voltage/temperature, check DCDC (voltage converter) status

Modules

  • Aux_dcdc_monitor_init

    • Checks the aux voltage/temp and checks the DCDC

    • Periodically broadcasts ok, not ok

    • Change ack status



  • Implement the communication to aux/DCDC through ADC

Implementation in progress, design is done



To finish integration testing this term

Center Console

Arshan

Purpose

  • Let the driver control the car’s power and drive states

Modules

  • Button_press: registers button presses

  • Main_event_generator: turns valid button presses into events

  • Power_fsm: FSM to transition between power states

  • Power_main_sequence: FSM to power car from main battery

  • Power_aux_sequence: FSM to power car from aux battery

  • Power_off_sequence: FSM to power off car

  • Drive_fsm: FSM to transition between drive states

  • Pedal_monitor: checks and saves pedal state

  • Mci_output_tx: sends drive commands and state to MCI

  • Ebrake_tx: manages ebrake state

  • Precharge_monitor: waits for precharge to complete (part of MCI)

  • Charging_manager: maintains charger state and handles permissions

  • Speed_monitor: gets and stores velocity from MCI

  • Fault_monitor: gets BPS heartbeat

To finish integration testing this term

Steering

Avery

Purpose

  • Registers driver controls on the control stalk (lights, signals)

  • Checks status of signal controls

Modules

  • Steering_can

    • Transmits can messages

  • Steering_control_stalk

    • Uses an ADC to read what the control stalk is doing

  • Steering_digital_input

    • Reads digital inputs on the control stalk and raises events

Implementation done, unit testing in progress



To finish integration testing this term

Pedal

Jarvis

Purpose

  • To detect brake pedal and acceleration pedal status

Modules

  • Brake_data:

    • Grabs via ads1015. How far the brake is being pushed down

    • Maps values into 0-100%

  • Throttle_data:

    • Grabs via ads1015. How far the throttle is being pushed down

    • Maps values into 0-100%

  • Pedal_data_tx:

    • Gets the brake and throttle data and sends it to the rest of the car

  • Pedal_shared_resources_provider:

    • Initializes the project

    • Stores the ads1015 storage

    • Stores the calib blob

  • Pedal_calib:

    • Stores the calib blob and that calibrates the pedals

      • Through test file

Integration testing complete

MCI

Gerald

Purpose

  • Communicate with the motor controller to perform action based on drive state and pedal values

Modules

  • drive_fsm: Applies the drive state from centre console

  • mci_broadcast: Broadcasts the current status of the motor controller

  • mci_output: Uses motor_can to communicate to the motor controller (taking note of drive state and pedal values)

  • Motor_can: API for on the motor controller CAN network

  • precharge_control: Ensure the capacitor is charged before sending commands to motor controller



  • Reading error values from the motor controller

Integration testing complete

AFEs

Avery/Gerald

Purpose

  • ‘Analog Front End’, measures battery voltage, reads temperature



  • Implemented from MS12

  • Testing required to determine code compatibility

To finish implementation this term

Current Sense

Jess

Purpose

  • Reads current coming in and out of battery pack

To finish implementation this term

BMS carrier

Avery/Gerald

Purpose

  • Implements battery management, detects faults (over/under voltage, over temp, over current)

  • Broadcast info so everything knows if battery will kill us (signals faults)

  • Manages BPS heartbeat (faults if a battery board goes down)

  • Manages killswitch (kills power from main battery)

Some implementation can be taken from MS12



To finish implementation this term

Charging

Jess/Jarvis

Purpose

  • Manage charging the battery from a wall charger

Modules

  • Charger_controller: toggles charging via mcp2515 and registers faults

  • Charger_control_pilot_monitor: reads PWM pin to determine max current

  • Charger_connection_sense: checks if charger is connected via GPIO pin

  • Permission_resolver: asks center console permission to charge

  • Begin_charge_fsm: FSM to go through steps to start charging

  • Stop_charging: steps to stop charging

  • Battery_voltage_monitor: monitors battery voltage to know when battery is full

Implementation complete

Lights

Ryan

Implemented in power distro

To finish implementation next term

Solar



TODO

To finish implementation next term



New member tasks

  • Implement the communication to aux/DCDC through ADC (power selection)

  • Reading error values from the motor controller (maybe for an extra enthusiastic member)

  • Charging_manager: maintains charger state and handles permissions



  • Firmware tutorial idea (creds to @Jarvis Weng ): Create specific git branch and implement

    • Blinking led project

    • Read adc project

    • Etc

  • Then tell a hardware member with tutorial board access to flash the tutorial projects on that branch and let the new firmware member know if they worked / what the behaviour was

Questions that came up

  • What is a firmware project manager?

  • Where do telemetry, driver interface, strategy fit into the overall timeline?