Page Comparison

...

Goals

• Wirelessly relay vehicle telemetry data sent on the CAN bus to the laptop device in the chase vehicle
• Provide GPS positional data via a GPS receiver (that the microcontroller communicates with over either UART or SPI)Design a user interface that is useful, aesthetically pleasing, maintainable, and intuitive to use
• useful: provides an overview of the important data at a glance; presents all the necessary information in a detailed format if necessary
• aesthetically pleasing: looks good, fits the context
maintainable: something that can be iterated upon without the new maintainer wanting to kill themselves 
• intuitive to use: user experience flows well, careful thought put into various use cases
• It should "just work"

Background and strategic fit

The proposed approach was originally inspired after a realization that having a working real-time telemetry system would be really useful for the race. Our previous "telemetry system" involved the driver periodically radioing back sensor data displayed on the vehicle dash to the chase car. The main purpose of this system is to provide the individuals in a chase car with real-time data that will help monitor performance of the solar car. This will allow team members to adjust our race strategy accordingly.

...

The goal is to offload as much work to the more powerful desktop client as possible, so that essentially the telemetry board on the car simply wirelessly streams CAN message data out.

Assumptions

• The client will be on a laptop in the chase car
• Most of the data-processing will occur on the more powerful device (in the chase car)
• The telemetry board will sit inside the car, and listen on the CAN bus
• The telemetry data is not going to be used by the individual driving the vehicle, and is only used by people operating the laptop in the chase vehicle

Requirements

...

Server

The server will expose a websocket, supporting bi-directional communication between the server and a laptop computer. This allows us to implement server to the telemetry board communication in the future (if we want to say, inject CAN commands or something). Ideally, this will also run on the Raspberry Pi Zero, and be lightweight enough with no major dependencies. The reason for the websocket is to allow us to push data to the telemetry client as it arrives. This points to something like golang, which can be compiled, and runs fairly efficiently on the Pi.

Since the server must run on both the Raspberry Pi Zero and the laptop computer, at the moment we will not consider some log stream abstraction (like Kafka/RabbitMQ), due to the resource overhead they will impose. Should the requirements change in the future (or the throughput of the system calls for it, which seems unlikely), we will deal with that, and perhaps look at using a "real" database instead of SQLite.

In addition, the server should be decoupled from the data ingestion logic, so that if we decide to, say, put the telemetry server directly on the CAN bus, it's only a matter of rewriting the "connector" that feeds into the server.

Routes

The websocket will be pushed data directly as it is received. Any requests to the routes will hit the database, allowing the telemetry client operator to "explore" historical data. The server should also provide routes for the client to look at historical data. Here's an outline of the routes, they will be covered in detail later (this list is probably incomplete0.

• GET /api/v1/batteries
• GET /api/v1/batteries/{id}
• GET /api/v1/motorcontrollers
• GET /api/v1/motorcontrollers/{id}
• GET /api/v1/mppts
• GET /api/v1/mppts/{id}
• GET /api/v1/messages
• GET /api/v1/location?time={timestamp}
• /ws/

Command Line Interface/Configuration

The command line interface should provide:

• -port: specify the port the webserver runs on (and provide a sensible default)
• -fake: randomly generate data (for testing)

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing