Rapid Control Prototyping for Vehicle Electronics

How to Master Complex Vehicle Electronics

Two Formula student teams share how they use a Speedgoat real-time target machine in their testing setup

Model, Deploy, Test, Repeat

Have you ever wondered how teams make use of the sponsoring package provided by MathWorks^® and Speedgoat? Two of the best teams in Formula Student, Electric Greenteam of University Stuttgart and AMZ Racing of ETH Zurich, share their approach to rapid control prototyping, model-based design, and how they plan on using the testing setup in the future.

As part of the sponsoring package, sponsored teams receive a Baseline real-time target machine that they can customize with the I/O modules according to their requirements. The I/O modules can be (but not restricted to these) Ethernet, CAN, CAN FD, EtherCAT, TCP/IP, UDP, or even configurable FPGA I/O modules to many other protocol functionalities such as PWM or encoder measurement. Typically, the Baseline real-time target machine acts as the main ECU of the car; it is quite literally speaking "the brain" of the vehicle. How do the best teams in the world of Formula Student use model-based design and Speedgoat hardware to excel in these competitions?

As you might know, both teams have been top 10 teams in the FS World Ranking consistently, namely the GreenTeam of University Stuttgart and AMZ Racing of ETH Zurich. The latter even ending the 2018 season as #1. Other significant victories include Guinness World records, podium positions, and wins at Formula Student Germany, to mention a few. Daniel Kiesewalter (AMZ Racing) and Patrick Schwarz (GreenTeam) shared some critical insights about their rapid control prototyping approaches at the FSG Germany 2019 competition.

Why Rapid Control Prototyping?

In series production, hardware for rapid control prototyping is only used during development and prototyping, whereas the final products are equipped with embedded controllers. Equipment for prototyping is typically more robust (#1) and more flexible (#2) but also a bit heavier than embedded controllers (#3). While Formula Student teams do not care much about #1 and #2, the teams and Speedgoat jointly worked on hitting the weight targets, #3. In race mode, teams use the Baseline in an open frame configuration with custom housing and cooling.

Moving the needle towards using a real-time target machine for the control development of a race car, is the tight interface to Simulink^® via Simulink^® Real-Time™. It takes minutes to go from design iteration to deployed algorithm running in the vehicle, enabling extremely high development speeds. You need "Simulink^® and the Speedgoat libraries, and no other software or interface," says Daniel.

Even auxiliary tasks such as post-processing or logging data can be performed by running a MATLAB^® script or using an app created via MATLAB^® App Designer. The latter especially helps MATLAB^® inexperienced team members change between car setups, driver profiles, do parameter tuning, and data processing.

How to Master Complex Vehicle Electronics

The electronics of a Formula Student car are quite sophisticated. Industry-grade components and custom-built PCBs are assembled jointly and are controlled by a central computing unit. The interface between all components is handled by real-time capable I/O and specific communication protocols. This is where the beauty of Simulink^® Real-Time™ and Speedgoat comes into play: for every interface need, there is a corresponding I/O or protocol driver block in the Simulink^® library. Therefore, various actuators and sensors can be connected in Simulink^® and then deployed to the controller.

Both teams can demonstrate by way of example, that there is no need for restriction to specific communication protocols. Greenteam uses Ethernet-based communication (TCP/IP and RT UDP) and EtherCAT, highly expandable in conjunction with CAN. EtherCAT has been used to interface with the car inverter. AMZ has relied mainly on CAN, which is still the mainstay protocol used in passenger cars. Their telemetry is transmitted via TCP/IP, and the inverters are controlled via RT UDP.

Control Algorithms – Overcoming the Challenge of Torque Vectoring

Both vehicles are 4WD race cars with wheel-hub-mounted 3-phase motors, a central battery pack, and inverter units within the chassis. While this powertrain concept leads to a phenomenal ratio of weight and usable torque, implementing torque vectoring is a challenge. The controller requires the signals of several sensors such as steering angle, yaw rate, vehicle velocity, and motor encoders to be fused in real-time and to send driving-maneuver-appropriate torque commands to the motors. Torque vectoring is commonly applied in conjunction with a traction controller. Ka.Race.Ing. of KIT published an article in the MathWorks^® Racing Lounge blog that exemplarily outlines a torque vectoring system.

Such complex systems require a professional approach of testing and validation to use the optimal performance. These aspiring engineers do not plug hardware together and optimize through hands-on racing. Both teams have well-thought cascades of testing and optimization.

Control Algorithms – Overcoming the Challenge of Torque Vectoring

Design of the individual subsystems in a desktop environment
Verification of subsystems with the actual sensors and actuators
Assembly of high-level controls in Simulink^®
Closed-loop simulations using a vehicle model
Racetrack testing

Since every lap out on the racetrack requires a vast amount of preparation and effort, teams make sure they show up on the tarmac with pre-optimized controller parameters and assure they spend every minute of the car in action wisely. Teams go through pre-defined test routines, log data, and real-time tune parameters of their algorithms.

Formula Student - Model, Deploy, Test, Repeat

Two Teams, Two Powerful Workflows

An essential criterion for Patrick (Greenteam) is that with a Baseline real-time target machine, they "always have sufficient computing power even for advanced control implementations and sensor-actuator configurations," to focus on prototyping their ideas without worrying about computing constraints.

Another crucial reason is the strong integration of Simulink^® software to Speedgoat hardware and the simplicity of the deployment.

Furthermore, all tasks from deployment to data log and parameter tuning is done from within MATLAB^® and Simulink^®. What you might find surprising is that both teams appreciate the convenience of the workflow. "You don't have to be a crack in C++, "says Patrick. So, it is a workflow that all domain experts in the team are comfortable to use to integrate their designs. Daniel emphasizes that he likes being able to "connect controllers to car components through IO blocks and generate code by a few clicks. So, for testing and parameter tuning, flashing the real-time target is very easy." This is especially vital for agile development and testing, such as testing on the racetrack.

Key Takeaways

This article is aiming to explain the reasoning behind using a real-time target machine for rapid control prototyping. No matter which workflow you decide to implement, the most important thing to keep in mind is to make sure you have fast and robust workflows for software to compute hardware integration. This is far more important than having the most advanced and complex systems. Having these systems tested and operational with high robustness makes the whole difference to having them envisioned and designed.

Also, a powerful software stack and virtual testing makes you independent from access to the racecar or racetrack infrastructure. We are all learning right now how essential digitalization and virtualization are, not only in times where in-person gatherings at a racetrack are suspended.

It's these robust processes that enable you to: Model, Deploy, Test, Repeat.

For more information on model-based design, make sure to check out the following resources shared by both teams. Thanks for the great community spirit!