Note: this was originally written for ASC 2021 and there will likely be multiple changes to the planned implementation, so this information will probably become outdated quickly.
Running Models
Raspberry Pi
The optimization model will be running on a Raspberry Pi located within MSXIV. Exact location unsure, but it will likely be connected to either the infotainment screen or driver display to provide the driver with the optimal speedIt will be Raspberry Pi 3B, which powers the drivers display and also shares components for telemetry and other firmware tasks.
Chase Vehicle
Strategy team members will be running models on laptop computers located in the chase vehicle. They will have full access to the suite of models, the dashboard and be able to input live weather/sun data collected via internet calls.
Concerns
Concern | Implementation | Fallback |
|---|---|---|
Raspberry Pi | ||
Raspberry Pi Optimization model may fail | Installed on Raspberry Pi | Models being run in chase vehicle on laptop |
Internet connection lost to Pi for weather/solar data | Unknown, may use LTE to call for weather/solar data periodically | Download the day’s data in the morning and store it locally on the pi |
Telemetry (Theoretical from Jess, has not been fully built out/tested)
CAN + GPS messages will be on the Pi at some point
There is a router within the car connected to the Pi via ethernet, router is a wifi access point
PI transmits data via wifi and LTE at same time, if wifi or LTE goes down the other continues sending data
Data is also stored locally on the Pi in case, all LTE transmitted points go to cloud database
laptops in chase vehicle can connect via wifi to store/display data
From Micah Black on the SoC Models
But I think I should be clear that there will essentially be 3 models running in my mind. Of we don't agree on this, then we should talk.
1 - model running on the raspberry pi zero in the car, reading voltages and currents and updating the SoC in real time. This SoC is reported over the CAN bus to the rest of the car and telemetry. The voltage and current measurements of the pack are only reported over CAN once for every X measurements to keep the CAN bus less busy.
2 - A model running in the chase car that reads the voltages and currents from telemetry and also calculates SoC in real time. We can compare this against what the car is reporting over telemetry as a sanity check. This one would not be required in an MVP.
3 - A model that the strategy algorithm can use while calculating the correct velocity profile. This will be run in an 'optimization' script that calculates the ideal velocity profile on-route. We need to recalculate this ideal speed frequently since we don't know how accurate our models are at predicting the losses, and we don't know how bad our drivers will be at driving the actual recommended speed. This one is the one that I previously built and has different inputs/outputs than the other two. Output is still the current SoC but input is based on the power requirements of the motor calculates for each section.