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

Version 1 Current »

Important Note

Previous team members have put an incredible amount of thought into telemetry already, documented here: Telemetry Server . Of special importance is the architecture used at FSGP 2019, pictured here:

(Telemetry at FSGP 2019 ). Previously the telemetry backend was a Golang binary, which may prove difficult to work with considering very few people know go. God bless Aaron Tan for putting this together. Note: For this setup, emphasis was placed on having CAN messages directly available via telemetry for debugging purposes. This could be skipped to simplify the architecture significantly, depending on team confidence.

Goals

Telemetry data is important for not only optimizing the car’s performance but also having human eyes on the current state of the car, which may not be possible for the driver and passengers to provide. Thus, a robust telemetry system that gives remote members insight into the data produced is essential to building a winning solar car.

Usage Conditions

There are two major scenarios in which this system will be active.

  1. The Formula Sun Grand Prix (FSGP), a track race in Kansas

  2. The American Solar Challenge (ASC), a ~1700 mile long race across America

FSGP

The FSGP portion will take place at Heartland Motorsports Park, on the track shown:

The team will be placed in a track-side pit area while the car does laps. The furthest point the car will be from the pit area is ~1.2 km [citation needed]. This creates the limitation that car will frequently be out of wifi range from the team. However, LTE coverage should be good over the whole track and pit area.

ASC

The ASC portion brings us from Kansas to Idaho, crossing through cities, countryside, and national parks. The solar car will be accompanied by both a lead car and a chase car to guarantee safety. This creates the limitation that the car will sometimes be out of LTE range (in national parks). However, in those circumstances, it’s highly likely the chase / lead cars will be able to stay within wifi range of the solar car.

Data

The data sources for the telemetry system are:

  1. The system CAN bus of the car

  2. A GPS module attached to the raspberry pi running the telemetry system

At a minimum, the things that should be logged via telemetry are:

  • Battery stats (voltage, temps, state of charge, estimate of distance remaining)

  • Relay states (MCI, BMS HV, BMS ground, solar, charger)

  • Solar stats (voltages, temperatures, other)

  • Power consumption (unsure on this, potentially able to pull data from power distribution)

  • Charging (current, voltage, time-to-full, etc.)

  • GPS data (initial condition + offset)

The data rate of these is TBD.

Requirements

The above information leads us to the following requirements.

The system must:

  • make all stated data available to the team

  • be robust in conditions where there is poor LTE connectivity

  • be robust in conditions where there is poor wifi connectivity

Broad Architecture

As stated in the upper level page, the physical architecture will be along the lines of a Raspi connected to the CAN bus and a GPS module, using both an LTE dongle and a wifi router as outputs. Data should be sent over both outputs. Data sent over LTE will be stored in a cloud server, while data sent over wifi can be transient and simply update a web interface in the chase/lead cars.

Architecture diagram is a TODO. In general:

  • Center console raspi runs a python script that:

    • sends websocket messages to driver display (flutter app running on same pi)

    • sends websocket messages in a TBD format to some cloud database/pubsub/message broker service for storage over LTE

      • sends same websocket messages over wifi for infotainment and chase car

  • Cloud server:

    • collects websocket messages and stores them, influxDB + Grafana is not a bad bet

    • log / mirror data to another longer term but less convenient storage (AWS or GCP?)

  • Clients accessing telemetry data

    • view through the Grafana dashboards

    • Access long term storage directly (for further analysis)

Preliminary tasks

Preliminary because all this is very much up in the air.

  • Come up with a proof of concept for sending web traffic over two different network interfaces on linux. This seems non-trivial without linux networking experience.

  • Determine an expected data rate of the telemetry system

  • Come up with all the CAN messages we need to grab for telemetry

  • Determine the best method for long term storage

  • Develop script to grab GPS data

  • Determine the best format for sending data (MQTT? HTTP? Websockets?)

  • No labels