BUT Pneumobil

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 task 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 severely 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).

System design

The control system has several tasks:

Pneumatic control = pneumatic valves timing, race modes, optimizations for top speed or air consumption,...
Source of informations for driver = Car speed, selected race mode, air pressures,...
Logging and telemetry = saving car data to SD card and sending most important stuff to the pc

To increase reliability and maintainability I split 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:

ECU

The Engine Control Unit is the most critical one. It does:

Valves control - 4 valves control air flow in the propulsion system, timing and the valves opening/closing scheme determine motor characteristics, top speed, air consumption, etc.
Reading user inputs - brake, throttle, horn,...
Measuring car speed, gear shifted,...
Measuring pressures in the pneumatic circuit
There are few spare inputs and outputs for e.g. electronic shifting (the gearbox is controlled manually be lever for now),...

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 functions to one big common connector. It minimizes a risk of connecting a cable to an incorrect connector and increases rigidity of the car cabling.

HMI

The Human Machine Interfaces serves primary as a source of informations for driver. Additionally 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:

Race screen - shows speed, average speed, distance travelled, pressures in various points of the pneumatic circuit, allows driver to switch between several race modes and restart data logging system
Status screen - shows all important values from the car - battery voltages, currents, inputs state, piston position,...
Setup screen - interface to set system time and race modes parameters
Debug screen - simple interface for engine control - manual valves control, etc.
Console screen - System messages are printed here

Also there's a slot for SD card where system log (simple .txt) and race log (to .csv file at 100 Hz) are stored. Additionally 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.

SDU

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.

PSU

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.

RF2USB converted

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.

Wiring and placement in the car

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 chassis welding, etc.). Harness is tied to the frame using zipties, quick and dirty, but it works well.

Software

This time I came into a conclusion 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:

Log system - storing logs by printf like functions with 4 severity levels and indication of the message origin. Anyone can subscribe to the log module and receive data that it's interested in. Each log source (system, drivers, ECU,...) can be filtered by required severity, etc. This way I'm able to send all logs over CAN to other modules, store info and higher severities on the SD card, sending critical messages over RF to the computer, etc. It's useful especially for debugging when I can set the log module to send debug logs only for required module.
Configuration system - common interface to set and get bool and int values, all non-volatile configuration is stored here. There's currently only one storage backend - i2c eeprom - but it's easy to add more in the future (SD card,...)
Communication stack - link layer is generic, messages can be sent either over can, uart or rf link. Higher layers are there to match reply with corresponding request, resend data when lost, decode messages meaning, etc.

Telemetry

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.

Race 2019

We won the top speed price in the competition. Unfortunately 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.