Project Summary

We intend to run the models on personal computers in one of the race vehicles while on the road at ASC. For us to read the data, there needs to be some kind of dashboard that will display the results of the model and allow the strategy team to make informed decisions based on the data. This dashboard will contain the results of different projects and note the status of the models (if any models go offline/lose their data input).

Goals

• Build a visually structured dashboard with both stats and easy-to-read graphs to convey information provided by models and car data to the team. We want to be able to understand the car’s performance, past, current, and predicted (future).

• Showcase maps of the upcoming route complete with weather and sun incidence data so we can more holistically understand the state of the route/race (ie. we want to present this data as well as using it in models).

• Have clearly defined error states to:

  • Quickly notify team when a model throws an error, loses connection, or goes offline

  • Quickly notify team when we lose connection to the database

Inputs

Data about the car can be received either directly from the car (if strategy models are running on the car’s Raspberry Pi), or DynamoDB (if running on a local computer). The problem with the latter is that we would be bulk pulling data in case we lose connection; when we lose connection, our backup is … USB I guess?

• Route/Race Model

  • Weather data and map

  • Sun incidence data and map

• Optimization model

  • Eventually, should be integrated with SOC, solar, etc. to produce a velocity profile

Outputs of System

We need a way to store all this data (not including visual components like graphs) for future storage within Google Drive. Of our two possibilities: strategy models running on the Raspberry Pi means that it could be sent directly to DynamoDB (which is periodically cleared out and moved to Drive); strategy models running locally means we should be saving it as CSV files for later upload to Drive.

Graphs

• Current state of charge

  • Percentage vs. distance travelled

  • Remaining km at current average speed (this may be more effective as a straight number, rather than as a graph)

• Route map

  • Sun incidence - estimated sun incidence for the route or expected solar energy incoming

  • Weather

  • Upcoming elevation/changes for next x km

Other

• Distance travelled so far

• Average speed over last 30 minutes, over day, over race

Technical

Our current proposed telemetry-strategy setup is as follows:

...

We’re still trying to figure out where the ideal location to run “strategy models” from will be, given that it would hopefully be taking input about weather and route that is not provided by the car.

Framework Selection

• DASH - likely our final solution but further comparison is being done

• Plot.ly

• MatplotLib

Basically, consider that everything we write has been in Python so we need to integrate with that. As well, we want a framework that allows us to pull data from DynamoDB and as a backup, transfer manually (via USB)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.