Strategy during the race

Owned by Michael Shiozaki
Last updated: Dec 12, 2021
2 min read

Project Summary

Note: changes to challenger will result in the below information potentially no longer applying.

Strategy should exist in 3 places during the race: chase vehicle, Raspberry Pi 3B (In-Car), and Raspberry Pi 0 (BMS Carrier). The following page in progress will outline how we rely on each and why each is important.

Goals

We should be clear what models are running where, and how often we expect inputs/outputs of each. Eventually, we’ll want to test this system.

Questions

  • How do we manually control the system? (Start/stop)

  • What’s the most effective way we can fire queries so as to not block anything else?

  • Is Python sufficiently fast for our calculations?

  • Are we over-burdening the 3B Pi; if so, what’s the backup plan? For eg. what’s the power usage cost of using the infotainment Pi exclusively for strategy?

  • Specific to the SOC ideas (via discussion with Avery, 3/13/21)

Chase Vehicle

The chase vehicle should be the primary location for strategy data monitoring during the race. It has one copy of the optimization calculations running (including relevant API calls) and a dashboard.

Inputs: Telemetry

Frequency: 15 mins intervals, corresponding to telemetry

In-Car Pi

Note: due to the team changing to a challenger, a drivers display pi will no longer be needed. However, there will likely be a pi for telemetry still that may be capable of operating the strategy suite. The below information will likely change when electrical determines what computing resources will be necessary for the car.

There are three strategy-specific responsibilities of this Pi (as operated by telemetry’s parent script):

  • Receive information from BMS carrier and telemetry

  • Perform optimization (API calls, calculations) and save all inputs/outputs in a database

  • Send optimization information through telemetry to chase vehicle, and optimization result to driver display

Inputs: BMS Carrier data, telemetry data on speed, API calls?

Frequency: 15 mins intervals, corresponding to telemetry

BMS Carrier Pi

The only model running on this Pi is the SOC model. This should estimate the battery’s SOC at any given time, given frequent data on current/voltage in and out of the battery pack. (calculate energy usage given this data; needs to be implemented)

Inputs: BMS Carrier data → current, voltage in/out of the battery back

Outputs: SOC for every raw battery cell reading; if raw battery data is being sent over, align SOC and raw battery data.

Frequency: Run model as frequently as possible (according to Micah Black). According to Jess Muir, battery data is produced 10ish times/second; sends out data to 3B once/second.