Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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.

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.

  1. Vehicle speed

  2. State of charge
     
  3. 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.

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 

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'm not sure how useful the current time and run time is, which could probably be replaced with more critical information (like Motor Controller debug flags). Likewise with the speed graph, since in my opinion, that's not a critical metric that I'd be concerned about.

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

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

Basically their design is split across 2 screens


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 "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

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

Storage Requirements

The telemetry system should be designed to handle communication errors, so that data is logged to a local SD card/flash drive. It's probably easiest to just store the telemetry data as a flat CSV file (or even as raw CAN message data).

Hardware Requirements

If we are planning on entering WSC (where vehicle interiors have been known to exceed 50C), we should ensure that at minimum, our electronics can operate at 60C. In addition, ideally the power draw is as low as possible.

Desktop Telemetry Client Data

Realtime Data ("Critical" information)

  • Battery pack data
    • Voltage
      • Minimum Cell voltage
      • Maximum Cell voltage
    • Current
    • Temperature
    • State of Charge
  • Motor controller data
    • Voltage
    • Motor Current
    • Motor temperature
  • Maximum Power Point Tracking (MPPT)
    • Array Power
  • Status
    • Current cruise control value
    • Current limits

Energy Consumption Data

  • Driving energy broken into battery kWh
  • charging loss

State of Charge Data

  • Trip start/end SoC
  • Current SoC

GPS/Speed/Positional Data

  • After talking with Titus on September 29, 2016 we decided that it would be beneficial to also build GPS positioning as part of the telemetry system. This will be provided by an external GPS receiver that the microcontroller will interface with over UART (since it'll be easier to implement, compared to USB). Since the telemetry board will now have 2 peripherals that need UART (SD Card and GPS), this dictates that the new microcontroller we choose have at least 2 UART ports.
  • The purpose of this will be to provide positional data and compare the telemetry data against where we are on the race. In addition, we can run additional analysis if we know where we were and what data is associated with that position.
  • I believe Georgia Tech measures speed using a magnet attached to the hub of one of the front wheels of the solar car and a Hall-effect sensor
    • Hall-effect sensor is mounted near the rotational path of the magnet
    • As wheel rotates, the south pole of the magnet causes the Hall-effect sensor to generate some voltage
    • An capture/compare timer interrupt fires at each rising/falling edge, and using the circumference of the wheel, estimates the speed
    • We could potentially do something similar if we don't trust the motor controller's RPM readings
  • We should be able to get speed data from a GPS receiver, insead of doing some RPM calculation.

Transmission to Chase Car

  • CAN network broadcasts messages to the telemetry board
  • Telemetry board wirelessly broadcasts data to the chase car

Data Retention

  • The on-board telemetry system should be capable of storing at least a day's worth of data
  • Data received by the telemetry client should be logged as well, and timestamped

Technology

  • Implement a message parser for received CAN data packets

User Interface

Essentially some sort of dashboard

Questions

  • How much space do we need to store data?
  • Are we implementing a protocol on top of the CAN bus?
    • The motor controllers have a protocol defined by the manufacturers. The current plan is to have a separate CAN network 
  • No labels