Arctan Telemetry: Daisy

All solar car teams strive to choose the most aerodynamic design, balance weight with durability and find high-efficiency solar panels and high-capacity batteries. These decisions are far from clear-cut, but let’s pretend there’s a definitive right answer. And let’s assume all the teams have unlimited budgets and, having chosen this right answer, can actually build the car it leads them to. Who would win?

Even with identical cars, it’s extremely unlikely the race would end in a tie. The factor that would separate the winners from the losers is race strategy. At a basic level, strategy involves deciding how fast to go given specific conditions on the road, in the car, and even in the atmosphere, but real race strategy is far from simple. We could derive an equation to tell us optimal speed if all that mattered was the power coming off the solar cells, but the solar car is a system with hundreds of variables, many of which have critical impact. Untangling this mess of variables is the task of the telemetry system and strategy team.

Snapshot of telemetry 2015 python code.
Snapshot of telemetry 2015 python code.

The inner workings of the actual strategical speed calculations will be left to another blog post (sorry if that’s what you wanted to see right now), because it’s first important to understand what all those variables going into that calculation actually are. There are 8 code-containing boards on the car, monitoring everything from the power from the cells and into the batteries, to turning on and off the headlights. All told, more than 110 distinct variables record the currents, voltages, and boolean state of everything monitored or controlled by these boards.

Getting the car to work involves building these boards and writing the code to manage them, but that’s only part of the problem: once they’re all put together, somehow drivers and support team members have to know what’s going on inside the car. That’s the role of the telemetry system. All of the variables are collected onto a single dedicated board, backed up onto an attached SD card in case transmission fails, then sent over a CAN bus (Google it) to be logged, parsed, and displayed on a computer in the chase vehicle. During the race, this allows every person in that vehicle to keep watch over the mechanical or electrical system they built to watch for failure or deviation from expected variable states, plus showing information of use to all and every system (like car speed, GPS coordinates, or the time the car’s internal clock thinks it is).

However, telemetry may be even more useful before the race than during. When the car is unveiled in early summer, there are likely still subtle bugs scattered throughout the systems, and these can be very hard to find. By early July the car can drive, but it is almost certainly not ready to drive across the Australian outback. One of the main tasks during the countless test drives over the summer is to tease out any potential problems and identify them while still in California, where they will be far easier to fix. But we don’t want a problem to get so out of hand something catches fire or otherwise becomes completely unworkable! Telemetry allows engineers to catch a bug before it gets out of control. Without this window into the inner workings of the solar car, we’d likely not identify an issue unless it manifested itself dramatically, and by that point it would probably be too late.

Screenshot of 2013 telemetry.
Screenshot of 2013 telemetry.

Every iteration of SSCP has had a telemetry system of some kind, even 25 years ago when computing power in the outback was extremely limited. But we’ve come a long way. When the 1989 team set out, they were operating a far less electrically sophisticated car and driving based on carefully calculated heuristics. We have the luxury of having enough storage and RAM to see pretty much anything we want to in real time, but that means far more work must go into developing a user-friendly and responsive telemetry front end.

A three-person team has worked for about four months on the 2015 telemetry system, nicknamed Daisy, building it up from the embedded systems on the car to a mostly-Javascript web display. The variables from the car are received over local wifi, converted from CAN packets to English variable names and numbers, and written into a sqlite database at a rate of roughly 400 packets per second. Then a python web framework creates a server accessible on any nearby computer, including phones and tablets, and the data is processed and displayed in both predefined and customizable real-time charts, plots, and graphs.

Pre-UI-testing Daisy overview page.
Pre-UI-testing Daisy overview page.

Previous editions of telemetry have attempted very different designs, most recently doing far more of the processing work on the car itself rather than in the chase vehicle. This resulted in some data loss and a lot of power consumption, leading to issues with overheating and overtaxing the car battery. Since these are both things that obviously are very bad for a solar car, the telemetry system in 2013 was nearly unusable and the only application for the myriad data streaming continuously from the vehicle was direct calculation in MatLab for speed determination. This left the team largely flying blind in all other areas. As a result, we’ve taken a very different approach with Daisy, hopefully to much better results.

Stay tuned and check back here after the first test drives to learn about telemetry in action!


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *