Race-ready Software: Using MATLAB and GitHub to Develop Control Systems for Formula Student

The BME Formula Racing Team (FRT) was founded in 2007 by a handful of talented engineering students, aiming to be the first Hungarian team to construct a race car entree in the global Formula Student series. Formula Student is a brand name for races held worldwide in which college and university students compete against one another in designing and constructing a race car. The competitions include various dynamic and static competitive events, such as those involving acceleration, endurance, skid pad, or engineering design. Starting with just 18 members, the team quickly grew, welcoming a second generation of 50 students. Today, FRT has close to 80 members representing the university’s various faculties.

Since 2011, the team has been developing electric vehicles. Starting in 2016, these vehicles have been powered by four motors. This is a huge advantage compared to rear-wheel drive, as by controlling four motors independently, torque vectoring can be used to enhance vehicle dynamics in various scenarios. The team has its own group, known as the Vehicle Dynamics and Control (VDC) group, whose task is to develop the control software. The system is developed in MATLAB/Simulink, which generates C code to run it on the vehicle’s microcontroller. Currently made up of nine members, it is crucial for the group to use methods that allow for collaborative software development.  

Challenge 

As the control software has become more sophisticated, the same practices used in earlier times resulted in a complicated Simulink model that was hard to understand as a whole, even for experienced developers. Also, as more students joined the group, the GitHub version control had to be streamlined to support contributions from several developers in order to fend off merge conflicts.

Moreover, due to the nature of student projects, group member fluctuation is high, with several new students joining every semester. For newcomers, it was even more difficult to grasp the overall system. Fortunately, MATLAB/Simulink’s solutions and best practices for handling larger projects came in handy for shaping the current code according to team needs.

Lastly, initially, the team did not have access to formal tools for validating the system’s various functions, and as things became increasingly complicated, some human errors were unavoidable. Of course, while the group had stated goals and requirements for the overall system and component specs beforehand, their validation also gained importance. The Simulink Requirements and Simulink Test toolkits provided just what the group needed to ensure high performance and helped to avoid blatant mistakes that would waste valuable testing time.

Solution 

To tackle these challenges, the VDC group took deliberate steps towards more agile software development: in early 2023, the team refactored the original Simulink model. Different high-level functions – such as input filtering, state estimation, longitudinal control, etc. – were divided into git submodules. The VDC model’s main repository references these submodules, which provides a huge advantage: it allows the group members to work on these functions simultaneously without having to work around merge conflicts. It allows for more freedom to experiment with various solutions, as the main repository can reference a previous commit of the submodule as an alternative if the new solution proves inappropriate. From the Simulink side, these functions were converted into subsystem references. Additionally, subsystem references were used for smaller components that were reused – such as the wheel slip control on each motor. By reusing previously validated components, there is less room for human error, resulting in a more robust code.

To create software that is more easily expandable, the data transfer between the submodules was recreated as well. Previously, signals between submodules were represented by separate links, making the model hard to follow and understand. To solve this issue, the team used buses to represent multiple signals with a single connection, resulting in a cleaner and more comprehensible model. This approach also means that there is no need to change the main VDC model even when, e.g., a new signal is introduced in a submodule from the bus. Additionally, the buses were further organized into nested bus structures, so various content signals could have their own bus. For example, the main channel in the “Car_state” bus is where most signals are transported through the model. It contains the “parameters” bus, “state estimation” bus, etc. Going even deeper, the “parameters” bus contains the parameter groups for various functions such as lateral (yaw) control, power limiter, and so on.  This method not only simplifies the wiring in the model but also helps developers find elements more easily.

Two MATLAB toolboxes were used to assess the final issue: Simulink Requirements and Simulink Test. The requirements of the former have been stated, starting from the vehicle level and beyond to unit level ones. Then, by defining test cases, every function can be tested both individually and in larger modules as well. The test harness interface includes various features for finding the most suitable solution to the given case, making it possible to input logs from on-track tests using import blocks. Using the “test sequence” block enables behavior inspection in critical cases such as sensor faults, not to mention that even plant models can be included to verify control performances.

Result 

The Vehicle Dynamics and Control group saw a huge work efficiency increase via the solutions outlined previously: we made it less time-consuming to manipulate refactored code, turbocharging the speed of the development process and, in the meantime, expanding the available resources for research and the experience with better control solutions. We also got new members up to speed much quicker, allowing them to contribute to the group’s work earlier. Finally, through the use of Simulink Requirement and Simulink Test, mistakes in developed code were drastically reduced. 

Summary 

Challenge 

Developing control software for a four-wheel drive electric racecar is a complicated task, even for experienced developers, but it is even more complicated for incoming students to jump in and build upon existing code. Three main aspects cause most of the headaches: 

• Version control must be used correctly to support development as the group expands; 
• As the model grows, S data transfer between functions must be streamlined; 
• Increasing complexity increases the likelihood of mistakes: introducing some programmatic testing tools can filter these out. 

Solution 

Members of the Vehicle Dynamics and Control group applied MATLAB’s and GitHub’s best practices in their approach to a growing project. First, a refactoring was done to divide the control software into submodules. Then, buses were created to simplify the transfer of signals between these submodules. To minimize mistakes to the greatest extent, the Simulink Requirements toolbox was used to define requirements, which the Simulink Test subsequently validated. 

Results 

The above-mentioned steps streamlined onboarding for new students, shortened the time needed to develop some functionalities, and corrected time-consuming bugs before any code was generated that would be used in the actual race car. 

Featured products

MathWorks® products:

• Simulink
• Simulink Test
• Requirements Toolbox
• Simscape

Learn more about Budapest University of Technology and Economics (BME) and the BME Formula Racing Team