In 2017 I became a member of Pneumobil Racing Team Brno, a group of students designing and building pneumatically powered racing cars for the Aventics Pneumobile competition. My taks was to design and build electronic control and telemetry system. The first iteration was far from perfect. The pneumatic circuit was controlled by atmega MCU, logs were collected by the well known bluepill STM32 board. As the budget was severly limited I used cheap connectors that were far from perfect. During the arcade race one of the connectors failed and we lost the race. For season 2018/2019 I started from scratch (and made this project my masters thesis).
The control system has several tasks:
To increase reliability and maintainability I splitted the system into 4 separate parts that are interconnected by the automotive CAN bus. This way I can completely change the pneumatic control board for new car next year and keep remaining boards unchanged, etc. The general layout is below:
The Engine Control Unit is the most critical one. It does:
As I mentioned there were few issues with the connectors last year, so for this season I used connectors with proper mechanical locks and grouped similar functios to one big common connector. It minimizes a risk of connecting a cable to an incorrect connector and increases rigidity of the car cabling.
The Human Machine Interfaces serves primary as a source of informations for driver. Additionaly it provides a debug interface and there's a SD card for storing race logs and a RF module to send data to PC during the race.
The main part is a 5 inch touchscreen which is used to display several screens:
Also there's a slot for SD card where system log (simple .txt) and race log (to .csv file at 100 Hz) are stored. Additionaly most important car state data are periodically sent over RFM69 at 868 MHz to remote PC. I was also planning to copy the data from the SD card to USB flash disk on user's request, but I didn't have enough time to implement this functionality in software before the race day.
The Speed Display Unit is the simplest board. It's just a STM32 MCU with buffers to power three 7 segment LED displays. It's there to display car speed. The speed is shown also on the race screen of the HMI, but these huge 7 segment displays are much easier to read on sunlight and during the race.
The Power Supply Unit was actually the most troublesome board. The car electronics is powered from 24 VLi-Poly battery. The circuit isn't complicated, two switching buck regulators are generating 5 V and 12 V for other boards and STM32 MCU is measuring currents and voltages in all power branches.
The power regulators wiring is taken from example in the datasheet, but it doesn't always work as expected. Few times (with load disconnected) the buck regulator IC literally melted when I connected the battery. And I really mean melted, even a spark jumped out of the IC and made a hole in the black plastic that covers the semiconductor inside. With no load connected, with circuit design from example in the datasheet. And yes, the polarity of the battery was correct. I was not able to find the cause before the competition itself, so I just thrown two buck regulators from ebay (per $2 or so) and it worked well during the race. The cause of burning down the buck regulator ICs is yet to be found.
As mentioned in the HMI part, I'm sending telemetry from the car to remote PC. This board is really simple, data received from the HMI board are sent over virtual uart over USB to the PC. Rest is done on the PC side. Nothing really special to talk about here.
PSU and ECU are placed in installation box with IP 67 protection (that was somewhat compromised by drilling few holes into it :)). Interconnection with outer world is made by DSUB connectors for low current signals and heavy duty 4 pin connectors for valves and power. All connectors have a mechanical lock system (screws, nuts,...) so the risk of accidental disconnection is minimized.
All the wires in the car tied up together with cable wraps creating a rigid cable harness that can be simply disconnected and removed from the car if needed (e.g. for chasis welding, etc.). Harness is tied to the frame using zipties, quick and dirty, but it works well.
This time I came into a conslusion I need a RTOS, I have some experience with the FreeRTOS, but I always wanted to try a ChibiOS. It has opensource license for non-comercial use and I really liked the system design, especially the HAL layer that is shipped together with the ChibiOS itself. The HAL is trully marvelous, simple, small, but fully functional and easy to use. Just forget the horrible STM HAL, not very finished libopencm3. This HAL is a state of art. Together with mx2board script it's even possible to generate header file with GPIOs configuration from stm32cubemx tool project file. That was the last piece I was missing. Because of the HAL abstraction, I was able to reuse most of the code on all boards of the system without any typedefs and similar workarounds. And I'm using several different STM32 MCUs, from STM32F0 to STM32F4, but the API is still the same. Beautiful.
So, there are several important parts present in each board firmware:
The data received over RF link on the PC side are processed and displayed by graphical telemetry app I wrote in python and QT, currently it only supports showing the telemetry data, but in the future I'd like to extend the functionality a bit to be able to completely control the car state, set log levels for various endpoints, change configuration in the config module, etc.
We won the top speed price in the competition. Unfortunatelly we lost arcade race due to a failure of one of the pneumatic high pressure connectors that was torn apart during second round. Long distance was not bad, but also not perfect, but as the Falcon car was not designed with minimising the air consumption in mind, 7th place wasn't that bad after all. During acceleration race we lost few seconds during start because of the gearbox malfunciton, so we ended up somewhere between 5th and 9th place IIRC.