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 4 Next »

For ASC, we would like to create a reliable telemetry system. In order to accomplish this, we are currently want to use LTE to dump CAN messages from the solar car onto a server, where it can be distribute it to other clients.

Challenges

I. Finding a reliable LTE solution (see Telemetry LTE research)

A major challenge that needs to be overcome in order for this project to succeed, is the hardware selection. We need a reliable LTE module / dongle. We've narrowed down our criteria to the following items:

  • Cost
  • Will work on Verizon or AT&T networks, as well as with Canadian carriers so we can test it here
  • High upper bound on termperature. It's going to get toasty in the car, and transmitters will also heat up even more when they are operational. Additionally, some manufacturers included an "overheat protection mode", where the connection is throttled or straight up killed after it reaches some threshold.
  • Works on Linux, ideally plug and play with the Raspi
  • Good reception. This one is hard to test without the actual hardware. We might have to consider moving the Pi around the car / or having a second one

Another key point is that we have to order this soon, or else we won't have enough time to validate that it works / reorder a different one.

II. Getting the CAN data onto the Pi

Previously, we were using can_dump project to get data off of the CAN bus and into the telemetry go backend. This needs to be thought through again, because of changes to driver controls [citation needed, what changes?]. We can choose from one of the following options:

  • Throw another controller board in the driver display compartment and continue to use serial over can_dump
  • Refactor driver controls to dump the serial CAN messages as well
  • Use socketcan via the PEAKCAN CAN/USB dongles
    • Pros: Easiest to setup
    • Cons: We won't have data from the motor controller bus
  • Use the Tritium CAN/Ethernet dongles
    • Pros: We can get the motor controller CAN data
    • Cons: difficult to setup, will probably need a router or Ethernet to USB adapters. Need to make changes to the telemetry backend to support reading off socketcan or wherever the CAN messages come from (it looks like Karl has been tackling this here: https://github.com/karlding/tritiumbridgetools maybe we can learn something from this). We also don't have a way to parse the motor controller bus messages yet.

III. Getting CAN data off the Pi onto some server (and other backend things)

There's currently no mechanism to get data off the Pi. I've been working on a way for two telemetry servers to communicate with each other ( ELEC-610 - Getting issue details... STATUS , ELEC-613 - Getting issue details... STATUS ). Bascially one telemetry backend starts streaming CAN message to another via HTTP chunked encoding. This seems to work well enough. I also added some basic authentication, and will hopefully be able to add letsencrypt support so that we're not streaming everything over plaintext.

Also, we currently don't have a way to query / display historical data. Might be an issue, maybe something we can improve.

Finally, we need to settle on a host for the cloud server. Will probably be Amazon or GCP. Probably doesn't matter that much, we'll go with whatever works, and whatever people are familiar with using. We can have a real database running on the server as well, instead of just using sqlite3. At the moment, I don't have any strong opinions about running an sql instance so we can leave it as is for now.

IV. New telemetry GUI for the chase car

Currently we have a telemetry GUI for the driver display panel. It look fine and displays enough information for the driver (although we also want to add motor controller temperature to it as well). However, this GUI would not be enough for people in the chase / pace car. There is not enough information there. As a result, we will need a seperate GUI for this. Since the GUIs are actually just HTML pages, hopefully there will be many people able to take this challenge up.

Ideally, we want all information the infomation we have presented in a sensible manner. As well, we'd want this GUI to probably calculate things like state of charge / discharge curves and things like that (still fuzzy on exact requirements).

The new GUI should display at least the same things as the current on does, and also:

  • Motor controller temperatures
  • Cell voltages
  • List of faults that have occured (if it's possible to get that data before the car shuts down)
  • Please add more things...



In summary: we still need an LTE solution, we still need to figure out a new way to feed the Pi CAN messages, we've almost finished writing code to send CAN data to "the cloud", and we need another GUI.

  • No labels