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 6 Current »

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


At this point we know that viable options lie in two main categories - modules and dongles. All Huawei dongles (e.g. e3372, e8372, which are reportedly some of the more reliable models out there) have operating temperature limits of +40 Celsius, which is very likely going to be problematic during comp. So, we must either use a beefier LTE module, dig deeper in the world of LTE dongles (which is surprisingly limited),  likely going off-brand, or come up with a cooling solution for a dongle that may otherwise fail at temperatures seen at comp. 

Future Electronics is sending us a SIM7600V-H module with an EVB kit. Once we have that in our hands we'll have some time to play around and see if we can get it to work. The form factor of the module itself should be mini PCIe, so if the kit boards are too bulky we can use something like the sixfab rpi hat to interface with the pi. If we can get this module to work, it can provide us with a lot of flexibility. Otherwise, we'll double down on finding an appropriate dongle solution. 


As a lower priority task, we'll also triage the XBee communication. If we can figure out what went wrong at ASC 2018, this communication method may still be a good choice for a chase car. If not, the changes being made for  ELEC-610 - Getting issue details... STATUS  would enable communication within a WLAN network as well. This would require some more thought, however, FSGP remains the top priority right now.

II. Listening on CAN - 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. Backend Business - Getting CAN data off the Pi onto some server

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 in plaintext.

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
  • MPPT voltages and temperatures
  • List of faults that have occured (if it's possible to get that data before the car shuts down)
  • Cautionary alerts for temperature/current measurements exceeding certain thresholds
  • Please add more things...

A simple approach could be to add two more GUIs, in addition to iterating over the existing driver display page. One page would be a more detailed real-time GUI as described above, and the other would be a page to view historical data and analytics. The new real-time GUI would have be mocked out and broken up into tasks implementing components in a prioritized order. Exactly how this second page would be implemented - from scratch or using existing tools such as SuperSet/Redash/Metabase (to quote the ASC 2018 Telemetry Retrospective) will depend on how progress on the core telemetry functionality goes. I think that using an existing tool would be the best solution, although we may have to make changes to the existing SQL db dumping to better fit the application. 


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