Debugging Against the Clock
November 21, 2022
Blog
Jessie Guo describes how the University of Calgary (UoC) Solar Car’s software team succeeded in perfecting its solar battery technology in a race against tight deadlines.
Since 2004, the UoC Solar Car Team has been pushing the boundaries of solar vehicle technology. Being pioneers in our field, creating the first cruiser class solar car in Canada, we are continuously driving to make the next big step as we compete alongside numerous other skilled teams in the chase for glory.
Our current vehicle, Schulich Elysia, stands as the pinnacle of our efforts so far, having achieved a 1st in class and 4th overall finish at the Formula Sun Grand Prix (FSGP) upon its debut in 2019. Most recently, after nearly 3 years away from competition due to Covid, Elysia made its return to racing and the 2022 FSGP podium as the team achieved a momentous 3rd place finish.
This is a project that allows students to stretch themselves designing and working on a car that weighs 545 kg (1200 lbs), is 4.5 meters (15 ft) long, 1.2 meters (4 ft) high and 1.8 meters (6 ft) wide. We create the top shell of the car using carbon fiber reinforced EPS, and the bottom is a carbon fiber reinforced corecell EPS mix. The solar cells are 318 Mono-Crystalline Silicon Cells, and the batteries are 1353 Li-ion 1440 cells. We can achieve around 1000-1200 Watts of array power.
UoC Solar Car Team proudly shows off the Schulich Elysia race car, which packs a powerful solar battery that can store up to 18 kWh of energy – enough to drive over 300 km when there’s no sunlight.
Creating and evolving this car was no small feat and required the effort of our entire team to accomplish. We are comprised of 80 undergraduate students, each bringing unique skills to the table. With members from various faculties such as Engineering, Business, Arts, and Sciences, we can harness a wide range of skills and experience in our journey to develop sustainable energy solutions for a practical, efficiency-focused solar car.
Forced into lockdown by the pandemic, we spent time to deepen our understanding of how to move forward in creating our next-generation vehicle. As part of this process, we completely re-architected and rewrote the code for the all-important battery management system (AuxBMS) board, which is critical to the car’s operation. The microcontroller for the AuxBMS is an STM32F4 running FreeRTOS. This microcontroller is responsible for a variety of tasks such as monitoring voltages and opening and closing contactors.
UoC Solar Car Team gets help from Percepio Tracealyzer to rapidly debug the code for the AuxBMS board.
Although we finished the code during the lockdown, we were unable to test until this year. As the FSGP qualification deadline was rapidly approaching, we had little time to debug the new code fully. Luckily, we got free access to the Tracealyzer tool and the Percepio support team, who helped us set up the software successfully. Our team was amazed at the number of functionality and the sheer amount of information that we could obtain, such as when tasks ran, current state, length the task ran for, the priority of the tasks, mutexes obtained, stack usage, etc. These were exceptionally helpful to our debugging as we were able to see the execution timeline in front of us rather than going through endless GDB breakpoints.
One of the main issues with the AuxBMS was that it appears not to be sending any CAN messages. It should be sending CAN messages every so often to update the status of the battery to other boards in the car. Initially, we were debugging using GDB; however, we could not get out any information besides that the tasks that are supposed to be sending these messages were not getting reached. When we used Tracealyzer to stream and trace the execution, we obtained so much more information that led us to the solution in just a few days. Tracealyzer showed us that there were no running tasks and the system was idle for the majority of the time. With this new breakthrough, we realized that the task was being blocked by its delay function and not because another task prevented it from running.
Another use we have for Tracealyzer is its high-speed logging feature of user-configured events. Currently our telemetry logging happens every half second, but there are many critical features that occur much faster than that. One such example is in our driver controls board. Here most of the inputs from the driver get converted into CAN messages and sent to the relevant boards, and we sample and convert the pedal press of the acceleration and regen-braking pedals to a current request for the motors. Not only is the ADC sampling at a rate of 10 Hz, we also have a smoothing filter to avoid jumping from requesting a high current to regen-braking immediately, as the sudden change in polarity could damage the motors long term. This smoothing of current happens near instantly when switching from acceleration to regen-braking, at a rate of 100 Hz. Graphing the current over this short period of time would not be possible without Tracealyzer and helped us immensely in fine tuning the low-pass filtering and switching process.
Snapshot of our polled average acceleration and regen requests according to our ADC samples.
We were very relieved to have access to Tracealyzer; only using GDB like before we would have been stuck at this issue for months. Tracealyzer provides so much more information and has highly assisted our team by cutting down debugging time. Thanks to Tracealyzer we were able to make our target and finish debugging the AuxBMS with a week left to spare.
