Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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?

...

View file
namecan_messages.csv
View file
namesystem_can.dbc

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

...