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.
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
- 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
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | On-board message/data storage | The telemetry board should log any messages it sends onto a SD card. The on-board telemetry system should be capable of storing at least a day's worth of data. | ||
| 2 | Withstand operating temperatures | If we're planning on attending WSC (where vehicle interiors have been known to exceed 50C), we should ensure that at minimum, our electronics can operate at 60C. | Must Have | |
| 3 | GPS location | The telemetry board should also be able to identify the location of the vehicle via GPS. | ||
| 4 | Real-time data | Critical information should be presented in real-time. Battery pack data (voltage, current, temperature, state of charge) should be real-time. It would be nice to have motor controller and MPPT data presented in real-time. | Must Have |
|
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| How much space do we need to store the CAN data? | |
| Are we planning on implementing a new protocol on top of the CAN bus? | Yes. The motor controllers will have their own network, and "our" CAN network will communicate with the motor controllers via an intermediate board that "translates" messages to the motor controller manufactor's specifications. See CAN Message Protocol for more information. |