For ASC, we would like to create a reliable telemetry system. In order to accomplish this, we are currently want to use LTE to dump CAN messages from the solar car onto a server, where it can be distribute it to other clients.
...
As a lower priority task, we'll also triage the XBee communication. If we can figure out what went wrong at ASC 2018, this communication method may still be a good choice for a chase car. If not, the changes being made for
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
A simple approach could be to add two more GUIs, in addition to iterating over the existing driver display page. One page would be a more detailed real-time GUI as described above, and the other would be a page to view historical data and analytics. The new real-time GUI would have be mocked out and broken up into tasks implementing components in a prioritized order. Exactly how this second page would be implemented - from scratch or using existing tools such as SuperSet/Redash/Metabase (to quote the ASC 2018 Telemetry Retrospective) will depend on how progress on the core telemetry functionality goes. I think that using an existing tool would be the best solution, although we may have to make changes to the existing SQL db dumping to better fit the application.
In summary: we still need an LTE solution, we still need to figure out a new way to feed the Pi CAN messages, we've almost finished writing code to send CAN data to "the cloud", and we need another GUI.