Telemetry Board

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)
• 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.

We wish to have a real-time telemetry system that allows us to gather data from the solar car and transmit it via wireless link to an external client (in a chase car). This information will be provided by sensors and a dedicated telemetry board, which will be transmitted to a remote laptop in the chase car. Optimum path and usage plans can also be created using the transmitted data, to optimize performance from the car and solar panels.

The telemetry system allows us to monitor performance through stored and real-time data (including battery voltage and current, the vehicle power consumption, the power generation from the solar panels, the temperature of the cells and battery pack, the vehicle speed and location, the faults and status signal from the controller, and GPS). In addition, having telemetry data allows us to tailor our strategy, and ideally recognize potential issues and trigger alerts before they become serious issues. Since data will be retained (ideally forever), we can also use this data to identify where improvements can be made in future designs.

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

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