Project Summary

Strategy should exist in 3 places during the race: chase vehicle, Raspberry Pi 3B (Driver Display), 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?

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

Driver Display Pi

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; if raw battery data is being sent over, then SOC and raw battery data can be aligned

Frequency: Run model as frequently as possible (according to Micah Black)