mitmotorsports/my18

All of the code on MY18, MIT's FSAE electric racecar.

my18's Issues

[DASH] Support for upcoming VCU/CSB charging mode

There should be a page dedicated to displaying vital charging information including:

• Bus voltage
• Bus current
• Cell Temperatures (min/max)
• Cell Voltages (min/max)
• BMS SOC if we can get that to work reliably

[BMS] Add and overhaul error handler functions and functionality

Work off of bms-errors for this issue!

Errors we need to monitor for Roman Chariot

• Undervoltage
• Overvoltage
• Undertemp
• Overtemp

Errors we need to monitor for Reliable Car

• All LTC errors
• Whatever EVT had

[BMS] Better pack voltage estimation

Is it possible to sum the voltage over all cells? Can we get a narrower range? There was a case where the estimate was 233V when the actual pack voltage was 260V.

Launch control torque commanded does not match dash output message

Launch control is able to jump back to the BEFORE state from later stages

As noticed on the testing trip on 9/9, Jeremy was able to drive the car via launch control and noticed that the states would fluctuate with different combinations of pressing the brake. Seemed like a race condition to Sebastian because it did not occur with different parameters of launch control.

[VCU] TRANSITION_FATAL comes before TRANSITION_RECOVERABLE

In state_error.c we have

void update_no_error_state(void) {
TRANSITION_FATAL();
TRANSITION_RECOVERABLE();
}

this is bad because if we reach both a fatal and a recoverable error, the state transition will happen to recoverable before the update loop body of the fatal transition will occur. This will result in not disabling the motors and closing contactors.

Launch control is not properly reset with master reset / driver reset

When running on 9/9, we found that the car must be completely restarted to restart launch control. Otherwise, the car would simply stutter to a halt on attempting launch control.

[TODO] Saturday pre-testing trip

Things to do before testing tomorrow in descending importance (do topmost first):

• [VCU] Transmit over CAN the controls configuration used by the VCU.

  This is both for logging purposes and for the next item.

  Title it VCUControlsParams.

• [Dash] Set each value in DashRequest to the corresponding value in VCUControlsParams upon entry in a page with unknown values.

  This means that at steady state (CAN messages came in), a question mark should never show up in place of a value.

  This would also work in the case of the critical page -- the limp factor and default regen value should be coming from the VCU.

• [Dash] Add ESTOP hit indication in critical page.

  There should be a prinout in the critical page that reads "ESTOP" if carstats.vcu_state.estop_hit and "" otherwise.

• [Dash] Add TSMS open indication in critical page.

  FATAL:CONTACTOR faults are monostable. If the TSMS is open, when the car moves from VCU_LV to VCU_PRECHARGE it will fault and go down to VCU_LV or VCU_ROOT (no guarantee as to which since I will change it soon, so do not rely on this).

  The fault will only appear very momentarily. On the dash you need to catch this fault and latch on some state variable that indicates TSMS was left open and thus precharge failed. This variable must remain latched on until the car enters VCU_RTD when it latches off.

  There should be a printout in the critical page that reads "TSMS" if the variable is latched on and "" otherwise. Ideally this would be next/on top of the ESTOP printout.

• [Dash] Debug button_listener actions.

  Today the dash rapidly cycled through many pages whenever tapped. I changed it back to A.rising_edge but we should fix that. I think that actions should only happen momentarily -- TAP pulses if button is released before the threshold and HOLD pulses at the threshold.

Spec and Pack BMS CAN Messages

We need to fix the parts of the CAN spec that pertain to the BMS and implement the CAN message packing in canmgr.c.

Things to be fixed:

• BMSPackStatus needs to be removed. We can't fit the entire status in a single message, therefore we must split it up into BMSCellTemps, BMSCellVoltages.

  1. Remove pack current and pack voltage. The BMS does not have that information on its own. It can estimate pack voltage, but so can any other board on the car given min and max cell voltages.
  2. balancing_needed sounds like an error to me.
  3. Pack voltage segments need to be thoroughly checked for correct message lengths and packing/unpacking them must be manually verified. If there's any potential overflow it should be recorded in BMSErrors.

• Cell IDs need to be documented somewhere -- where on the pack/module is cell 21?

• Convert BMSErrors/Heartbeat from a single enum segment to as many segments as there are things to encode. or multiplex them cleverly somehow cos this conflicts with BMSHeartbeat containing things other than errors. or maybe rethink ParseCAN concept to accommodate segment groups.

• Contactor weld should only be part of BMSErrors -- not its own message

• Merge BMS_SOC into some other message. Maybe rename BMSErrors to BMSHeartbeat to make it more inclusive?

• Agree upon message transmission frequencies and adhere to them. Enforce the frequencies through canmgr.c (make transmit functions return early if we try to send early).

[BMS] Performance hit during SOC save

During writing SOC to EEPROM, CAN communications halt. We need to either make the write faster or do it less often.

[CSB] Initialize itoa buffer to NUL char

MY18/src/charger-shutdown-board/src/lcd.c

Line 173 in 6d22ca0

char buff[11]; // Max length of 32 bit num including minus sign.

Launch control race condition when checking accelerator let-off during speed controlling

May be related to #25 , seems like there is a race condition where even though we went to the ZERO_TORQUE stage, we sometimes progress to the DONE state. For example, on the jacks on 9/15, we noticed that if you do a 2nd driver reset, and you go through LC all the way to speed controlling and let go of the pedal, you sometimes hit ZERO_TORQUE but not DONE until you press the pedal once more.