| Table of Contents |
|---|
Summary
In this RFC, we propose a general plan of attack for the implementation of our telemetry system. The goal is to trigger an initial discussion regarding the software implementation and hardware design, and not a complete detailed design.
The scope of this telemetry system currently does not include strategy.
Vocabulary
- telemetry: the automatic measurement and wireless transmission of data from remote sources
- telemetry system: for the purposes of the document, the "telemetry system" refers to the components of the car which we have sensors monitoring data
- client:
- server:
- Maximum Power Point Tracking (MPPT) devices:
- state of charge (SoC):
Motivation
We wish to have a realtime 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.
- Vehicle speed
- State of charge
- Analytics on data
As an extended feature, we could perform analytics on the data, aggregating various data sources to optimize performance and determine what aspects of the car can be improved. This is a stretch goal that is something to be considered, but not something within scope right now.
What do other teams do?
Here we attempt to reverse engineer how other teams do their telemetry. This is a combination of browsing through GitHub, watching YouTube videos, and smart Google-search queries.
Eclipse
As seen by their UI, the focus is on the telemetry operator taking an interactive approach, and "exploring" through various graphing visualizations that they find useful. One thing that I think is useful here is their Last Seen timestamp for each signal.
There is this car-level view which is pretty neat.
You are able to graph every signal with respect to time.
Minnesota
It's kind of hard to see what's going on here, but here's one of their tabs.
Kentucky
Here we see that they care a lot about visualizing their pack. I do like the way they've chosen to distill their data.
...
I do find it funny that they decided to name their pack Batman + Robin, given that Tesla names their BMS + redundant BMS chip the same thing.
Stanford
This was their old telemetry pre-2005
...
And this is supposedly a newer version of it. To be honest, I'm not really a fan of their newer dashboard. It seems to choose looking pretty and cool over being useful, and while their old page didn't look as nice aesthetically, it provided the relevant information.
Missouri S&T
This was their old LABVIEW design
...
This was what was used for Solar Miner
Near East University
It looks good, but I'm not convinced that they've effectively utilized all the space they have available.
...
With that being said, everything that they have chosen to display is large, and clearly visible. I do like how everything stands out.
University of New South Wales: Sunswift
Here's an old Sunswift telemetry screen from 2010-2013 that I found sitting around on their Bitbucket. Their last commit was in 2014, and the project is listed under their deprecated projects, so I'm pretty sure this is no longer what they use. It's a native application called Scanalysis written using the Python GTK bindings.
...
A summary of all the systems in the car. As someone who was monitoring vehicle telemetry during ASC 2018, I think all this information here is super useful when just monitoring what is going on. They've done a good job at summarizing everything that you would need.
Here's some more graphs.
Delft University of Technology
They won WSC 2015 with this, which includes a separate panel for their strategy. They won the race by 8 minutes, with the University of Twente placing second (which was the closest WSC finish in history). A lot of it probably has to do with their car designs (ie. aero), but strategy definitely plays a huge role.
...
They also had a pretty sick chase vehicle setup in 2011. It must be nice having that much money for dashboards 
Tesla
Okay, not really a school, but I pulled this from the Model S "Reading Battery Voltages and Temperatures via CAN on Model S" thread at Tesla Motors Club.
...
Something like this is what I had in mind for the pack visualization.
Detailed Design
The proposed approach was originally inspired after a realization that having a working realtime telemetry system would be really useful for the race. Our previous car's (MSXI) "telemetry system" involved the driver periodically radioing back sensor data displayed on the vehicle dash to the chase car. MSXII was slightly better, although it wasn't very user friendly—it involved me holding an XBee receiver out of the rear passenger window while running a Python script to parse the data, and then periodically update the odometer reading manually from the Chase vehicle (with some liberal use of Excel spreadsheets for graphing things like power consumption and battery module state).
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
Overview
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 seriously apparent.
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.
Onboard Telemetry
Software Requirements
| Title | User Story | Importance | Notes |
|---|---|---|---|
| Data Transmission | The data should be transmitted to the chase car via the XBee | Must Have | This can probably just be a simple pass-through over UART. During FSGP/ASC 2018, we implemented Consistent Overhead Byte Stuffing (COBS) in our CAN-UART link, which was shared with our telemetry. I don't think we really had any issues with this. |
| Data Logging | The data should be logged to a local SD card/flash drive as well, in a CSV format (or raw CAN message data, as long as we can parse it out). | Should Have | |
| SD Card driver | An SD card driver needs to be written. | Must Have | We will probably just implement one initialization flow, depending on what kind of cards we're going to be using (most likely SDHC). |
| FatFS bring-up | We should integrate FatFS by providing stubs to the SD card driver | Should Have | |
| GPS driver | A GPS driver needs to be written. | Must Have | We need GPS data in order to determine where we are on the route. This is also useful in correlating where we are on the route. |
Hardware Requirements
| Title | User Story | Importance | Notes |
|---|---|---|---|
| Reliable transmission to chase vehicle | The method of transmission must be able to be received from a chase vehicle | Must Have | This should have at least 12 m of range, in case the chase car gets cut off by another car (which actually did happen 3-4 times during ASC 2018). |
| Small Footprint | The size of the board should be small enough to mount on the roof of the car | Must Have | |
| SD card reader | The hardware should have a SPI interface that allows for a SD card | Must Have | Controller Board has SPI ports, so we just need to connect the SD card reader to the appropriate port. |
| Be able to listen on the system CAN bus | The hardware should have a CAN transceiver that allows the board to listen on the system CAN bus | Must Have | This is probably going to be covered by the Controller Board. |
| Operating Temperatures | Electronics must be able to operate at a minimum of 60 C | Must Have | Ambient temperature at WSC has been known to hit 50 C |
Desktop Telemetry Client Requirements
Software Requirements
| Title | User Story | Importance | Notes |
|---|---|---|---|
| Shared backend with Driver Display | The backend should be reusable for Driver Display | Must Have | This is critical, as our driver display currently is proposed to be a different frontend running on the Raspberry Pi. As such, this necessitates the use of a backend language that is going to be able to run on the lower powered Pi as well as our Desktop computers. |
| Readable Summary | The overview GUI should be legible in full screen, with all the data above the fold. | Must Have | This is critical, since all the important information should be distilled into a form where they are available at a quick glance. |
| Data Logging | All data should be logged to a database | Must Have | This is probably going to take some careful thought into table design in order to partition the tables correctly. Most of this will be for strategy purposes during the race, which will probably operate on a week's worth of data at most (realistically probably just the previous day). I can see the data being used for ad-hoc queries after the race, in order to explore various characteristics of our design. I think this has lower priority than getting the GUI complete, as we can always log to a file and then perform ETL afterwards. |
| Local data storage | All data should, at the very least, be stored locally | Must Have | One thing we learned from ASC 2018 was that internet connectivity is going to be spotty. Verizon had coverage, but there were times when even that was bad. We can ETL into another datastore and perform ingestion whenever we have connectivity (or need to perform analytics), but IMO that's out of scope here. |
| Backfill dashboard data with historical data | The backend should provide historical data to backfill graphs/visualizations when appropriate | Nice to Have | Occasionally, the XBee may disconnect, and so you'll have to backfill your dashboard's data with your stored data. Or if the app is closed, then you have historical data instead of a blank state. |
| RAW data mode | There should be a way for someone to view the raw messages if the visualization is not working (or doesn't provide that information). | Should Have | There must be a way to view the raw data (aka "Console Mode") |
| Speedometer reading | The GUI should display the speed | Must Have | We should have the option to switch between km/h and miles/h |
| Cruise control setting | The GUI should display the currently set cruise control target | Must Have | |
| Average speed over interval | The GUI should have the option of displaying the average speed over an interval (say 15 minutes) | Should Have | I found this extremely useful during ASC 2018, when choosing our cruising speed during the hilly parts. It's not critical for telemetry, but it is pretty important for strategy. I found that typically, we would end up averaging slower than our target speed by 10-15 kmph, due to the variation in road grades. |
| Battery pack module stats visualization | The GUI should display the battery pack module stats (voltage, temperature) in a visualization of the pack. If there is room on the main tab to display this, that would be ideal, otherwise it can go in a separate tab. | Should Have | Personally, I would like to see something like what Kentucky or Delft has implemented. Especially with our pack layout being split into a master/slave box, I think having the telemetry GUI representation reflect that layout would be really nice. I propose that we colour code the cells (like Kentucky), and then make the individual battery modules smaller (like Delft). This physical layout visualization isn't critical for telemetry/strategy, but it helped me understand hardware faults (on the AFE) as well as which areas of the pack required additional attention. I got around this during ASC 2018 with a separate spreadsheet that I marked out the pack layout in, which I would cross-reference against my data readings. |
| Total Pack Voltage | The GUI should display the total pack voltage | Must Have | This allows us to spot check SOC calculations and perform power calculations |
| Battery pack module voltage | |||
| Battery pack module temperature | |||
| Maximum module voltage | The minimum/maximum module voltages are used to determine how unmatched modules affect our capacity when charging/discharging (the minimum module affects our capacity when discharging, and the maximum module affects our capacity when charging). | ||
| Minimum module voltage | The GUI should display the minimum module voltage. | Must Have | |
| Average module voltage | During ASC 2018, I manually calculated this as the average discounting any outliers (ie. module inputs exhibiting hardware faults, unbalanced modules). | ||
| Battery pack current | Must Have | ||
| Discharge resistors enabled | At FSGP/ASC 2018, there were some concerns as to whether or not the AFE could handle enabling more than 1 bleed resistor per AFE, given we had observed that the board would heat up a significant amount. A new board revision is supposed to fix this, but we should follow up with this requirement when that is completed. This would also allow provide us with an interface to remotely enable bleed resistors. This can probably go underneath a separate tab that isn't the Main Dashboard. | ||
| Motor Controller Temperature | The GUI should display the motor controller temperature | Must Have | The |
| Motor Controller Status Flags | The motor controller gives us the following error flags:
And the following limit flags (which determine what control loop is limiting output):
Having this would have been critical for ASC 2018, where we dealt with a lot of issues with our motor controllers. | ||
| Motor Controller Bus Measurement | The GUI should display the motor controller bus current and bus voltage. | ||
| Motor Controller Velocity Measurement | |||
| Motor Controller Phase Current Measurement | Motor phase current used for the 3 phase BLDC motors | ||
| Motor Voltage Vector Measurement | |||
| Motor Current Vector Measurement | |||
| Motor BackEMF Measurement / Prediction | |||
| 15 V & 1.65 V Voltage Rail Measurement | |||
| 2.5V & 1.2V Voltage Rail Measurement | |||
| Fan Speed Measurement | |||
| Sink & Motor Temperature Measurement | |||
| Air In & CPU Temperature Measurement | |||
| Air Out & Cap Temperature Measurement | |||
| Odometer & Bus AmpHours Measurement | This is really useful in order to correlate telemetry data with road data. | ||
| Solar Sense (MPPT) input | Since we didn't have solar sense working at ASC 2018, we resorted to measuring the current entering the pack from the BMS (by coasting). This would be useful because:
|
Technology
- Golang: this is compiled (hooray for typed languages!), with less resources needed than Java/Node.js
- Standard web app stack
- TypeScript
- React
- sass
- Bootstrap 4
- Webpack
...
- Maintainable: I don't want to make choices that will result in the team rewriting the GUI every car
- Reasonable choices: I don't want these tools to become obsolete by the time changes need to be made
- Proven to work: 10 years down the road, will we still be using these tools?
- Testable: testing is key
User Interface
Essentially some sort of dashboard. I think it would make the most sense to use a similar design as Nuna, and
Overview
The