{"id":11183,"date":"2024-06-03T12:33:49","date_gmt":"2024-06-03T16:33:49","guid":{"rendered":"https:\/\/blogs.mathworks.com\/student-lounge\/?p=11183"},"modified":"2024-06-10T08:58:22","modified_gmt":"2024-06-10T12:58:22","slug":"how-amz-racing-designed-the-motor-controller-to-achieve-0-to-100-km-h-in-0-956-seconds","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/student-lounge\/2024\/06\/03\/how-amz-racing-designed-the-motor-controller-to-achieve-0-to-100-km-h-in-0-956-seconds\/","title":{"rendered":"How AMZ Racing Designed the Motor Controller to Achieve 0 to 100 km\/h in 0.956 Seconds"},"content":{"rendered":"
\n
For today’s blog post, Veer Alakshendra is excited to welcome Joel Fl\u00fcckiger and Lucas Gibson from the AMZ Racing Formula Student team. Joel and Lucas will be discussing the motor controller design that helped their team set a new world record for electric car acceleration.<\/div>\n

Who Are We<\/h2>\n
AMZ Racing<\/a> was founded in 2006, with the mission of creating an association that inspires the next generation of engineers, pushing the limits of electric racing and providing an environment ideal for the students of ETH Z\u00fcrich and HSLU to learn and innovate together.<\/span><\/div>\n
As part of the Formula Student community, AMZ builds a new prototype race car from scratch every year, to take part in international competitions where the car’s performance, design and financial planning are thoroughly evaluated. Young engineers from universities across the world meet, share ideas and push each other to build the best possible race car.<\/div>\n
In 2016, AMZ used one of their self-built formula student race cars \u201cgrimsel\u201d to set a new world record<\/a> for the fastest accelerating electric vehicle, reaching 100 km\/h in 1.513s. Six years later GreenTeam, the formula student team of the University of Stuttgart, managed to beat this time by 0.052s in the summer of 2022.<\/div>\n
Once again, AMZ decided to take one of their prototype race cars, push it to its limits and make a further new world record attempt. After one year of optimizing all parts of the race car, be it drivetrain, aerodynamics or electrical system, the team managed to regain the world record<\/a>, setting a 0-100 km\/h in 0.956s<\/span> on 01.09.2023.<\/div>\n
\"\"<\/div>\n
In this blog post, we will focus on one part of the car particularly, the inverter, or more specifically, the motor control algorithm and its implementation. We\u2019ll go over how we laid out our goals and why we decided to implement a custom solution for the inverter software. Furthermore, we\u2019ll discuss what sort of difficulties we faced, how we solved them and possible future design steps we might take to improve the overall design of the controller.<\/div>\n

What Motivated Us to Break the Previous Record<\/h2>\n
With the goal of making our first world record attempt in summer 2023 the time pressure was on. Hence, we focussed on the following goals:<\/div>\n
\"\"<\/div>\n
Figure 1<\/div>\n
Maximize performance at 100 km\/h:<\/span> Building on previous generations of inverters, we saw the potential for improvement. To maximize performance, we decided to redesign the motor controller from scratch, ensuring a thorough understanding of its implementation and tuning while reusing the rest of the interface of the existing inverter software. This approach would save time during the summer commissioning with the Electronic Control Unit (ECU) and the car.<\/div>\n
Initially, we defined the inverter’s design using mathematical models. Simulating a physical model of the electric prototype race car, we identified torque sensitivities, setting targets of 20 Nm for the front axis and 40 Nm for the rear wheels. To reach 100 km\/h in 1.2 seconds, the prototype required about 200 kW. Stable control up to 28,000 RPM was essential due to our motors’ small and lightweight design.<\/div>\n
Maintain accessibility for future use by the team members: <\/span>AMZ’s founding principle is to offer students a space to push boundaries, explore new ideas, and enhance their skills through challenges. Emphasizing knowledge transfer, our controller needed to achieve record performance to reach 100 km\/h swiftly, while remaining accessible for future students to use and modify.<\/div>\n
Identify errors and safeguard the hardware:<\/span> Much of the development focused on efficient error detection and hardware protection through simulation and testing. Using MATLAB\u00ae and Simulink\u00ae, we designed a custom model to accurately simulate control set points, implement testing modes, and create a modular build. This approach ensured that the system could be easily understood and modified by future AMZ students.<\/div>\n

Our Methodology<\/h2>\n
Figure 2 provides a high-level overview of our approach. To keep this blog concise, we will delve into specific aspects of our methodology, focusing on the modelling of the inverter, motor, and motor controller, as well as the hardware implementation.<\/div>\n
\"\"<\/div>\n
Figure 2<\/div>\n

Inverter Software Overview<\/h2>\n
To understand the approach, we took when designing the controller, we need to take a step back and review the general structure of the inverter software in AMZ. The software runs on a Zynq7000 System on Chip (SoC) module. This module features a ARM\u00ae dual-core Cortex\u2122-A9 and a Field Programmable Gate Array (FPGA).<\/div>\n
This gives us the option to implement standard tasks like ethernet communication with the ECU, high-level fault checking and data logging in C code on the processors.<\/div>\n
Furthermore, the slower speed control loop and field weakening calculations are also executed on the processors. The current controller that we designed for the world record, which runs at a roughly five times higher frequency than the speed controller, is implemented on the FPGA.<\/div>\n
\"\"<\/div>\n
Figure 3<\/div>\n
FPGA design is an incredibly complex topic and can easily become confusing. The design is implemented using a hardware description language (HDL), which is significantly different from programming languages and toolchains provided by the manufacturers. For the Zynq, this would be the AMD design flow.<\/div>\n
One of the tools AMD offers is AMD Vitis Model Composer, which allows users to build a model in Simulink\u00ae using AMD’s block library. This model can then automatically generate an Intellectual Property (IP) block for the FPGA design. We chose this approach because our previous inverter control algorithm was implemented this way, and our team had the expertise to build a new model efficiently. However, the limited AMD library required us to rebuild the golden reference model using only AMD blocks for code generation. Alternatively, teams can also use HDL Coder<\/a> that will allow them to remain entirely within the Simulink environment for controller development and testing. More on that later.<\/div>\n
\"\"<\/div>\n
Figure 4<\/div>\n

Motor Control<\/h2>\n
Now to the fun part, the motor controller. Field Oriented Contro<\/span>l is a control algorithm, often used in industry to control machines like a permanent magnet synchronous motor (PMSM). It relies on the coordinate transforms (Clarke and Park transformations) which convert the three-phase stator currents into the d-q reference frame aligned with the rotor flux. As it has robust control performance and deterministic switching characteristics, it was well-suited for the world record attempt and also meant that it could be used for the AMZ inverter in future formula student competitions.<\/div>\n
The image below demonstrates the functioning of the FOC. To learn more about FOC, please refer to this video series<\/a>.<\/div>\n
<\/div>\n
\"\"<\/div>\n
Figure 5: Overview of FOC [1]<\/div>\n
The previously implemented control algorithm running on the AMZ inverters was an adaption of Direct Torque Control (DTC). Unlike Field Oriented Control (FOC), which uses PI controllers to control the direct current id and quadrature current iq to regulate the motor performance, DTC directly controls the motor torque and flux using a hysteresis-based controller also known as bang-bang control. Like FOC it is also possible to weaken the field, where ideal torque conditions are sacrificed to reach higher rotor speeds. This controller offers a simpler implementation of the actual current controller than FOC (hysteresis vs PI controller) with a very dynamic response to reference values. However, for us, it came at the cost of highly unpredictable switching characteristics of the semiconductor modules and higher torque ripple which we wanted to avoid in the final motor control.<\/div>\n

Traction Control<\/h3>\n
For optimal traction control, our primary goal was to achieve a clean and particularly low-latency vehicle speed measurement. To accomplish this, we utilized the Kistler SF-Motion equipped with an additional IMU, updating the speed signal through a Kalman filter at 500 Hz on the Speedgoat unit. To maximize acceleration using straightforward calculations, we leveraged our existing knowledge of tires and conducted test runs to manage the desired tire slip ratio effectively. Consequently, three signals were transmitted from the ECU to the inverter: one for torque reference and two for motor speeds, defining the permissible motor speed range. This setup allowed the motor to operate within a specified torque reference as long as the motor speed remained within this range, corresponding to the tire slip ratio. Excessive tire slippage, indicated by motor speeds falling outside this range, triggered the inverter to shift from torque to speed control, using the band limit as a reference.<\/div>\n

Overview of Simulink\u00ae Model<\/h3>\n
Having decided which motor control strategy we wanted to employ, we started building a golden reference model in Simulink\u00ae which would set a foundation upon which we could build as we progressed further into the development of and deployment of the controller on hardware.<\/div>\n
Furthermore, the golden reference was a computationally efficient model aimed at verifying basic functionalities at a high level. This allowed for quick simulation results and easy verification of the model by simply defining a set point we wanted to track and then checking the results of the simulation. While this model ultimately is not a necessary step in the code generation and deployment on the FPGA, we saw it as a necessary step in the development process. Only once we were happy with the performance of our golden reference model, did we start implementing the version we would use for the HDL code generation. This saved us a significant amount of time during debugging.<\/div>\n
The Simulink\u00ae model consists of three main parts, the FOC motor control model (golden reference) which was our implementation of the standard FOC control strategy, the visualization which we used to keep track of all the interesting variables when running a simulation and a model of the hardware, needed to close the feedback loop of the controller. The hardware components were built using the blocks available in Simscape\u2122<\/a>, which enables you to rapidly create models of physical systems within the Simulink\u00ae environment.<\/div>\n
The three-phase inverter model consisted of simple blocks like MOSFETS, resistors, capacitors and voltage sources. Other components we used in our hardware model included the battery, PMSM and Encoder.<\/div>\n
\"\"<\/div>\n
Figure 6: Inverter subsystem<\/div>\n
\"\"<\/div>\n
Figure 7: Motor, inverter, and battery subsystem<\/div>\n
\"\"<\/div>\n
Figure 8: Motor controller subsystem<\/div>\n

Hardware Implementation<\/h2>\n
When we reached the stage of generating HDL code from our model, we encountered certain challenges. In order to deploy the motor controller on the AMD FPGA, we used the AMD Vitis Model Composer<\/a>.<\/div>\n
This toolchain allows for the translation of conceptual designs in Simulink\u00ae into functional hardware that can be deployed on the FPGA. Simulink\u00ae’s user-friendly graphical interface greatly simplifies the design process, allowing for intuitive modelling of the system architecture using interconnected blocks. It is then possible to fine-tune the Model Composer settings to align with the target FPGA specifications and synthesis preferences. After that, the Model Composer translates the Simulink\u00ae model into HDL code, preparing it for synthesis and implementation onto the target FPGA device.<\/div>\n
To ensure the final “hardware” or “AMD” version of the motor controller operated as desired, we opted for a stepwise approach. Having divided the FOC Simulink\u00ae model into various subsystems, each of these subsystems was iteratively replaced with an AMD subsystem. A pivotal feature instrumental in reconstructing the golden reference model during its implementation with AMD blocks was the use of Simulink\u00ae variant subsystems<\/a>. This feature afforded us the flexibility to select which model of a block in Simulink\u00ae would be compiled for every new simulation run. This iterative process allowed us to verify that the controller’s behaviour remained consistent after having replaced a subsystem with its AMD variant.<\/div>\n
\"\"<\/div>\n
Figure 9: Model with Simulink\u00ae blocks<\/div>\n
\"\"<\/div>\n
Figure 10: Simulink\u00ae model with AMD blocks<\/div>\n
Due to the seamless swap between AMD and Simulink\u00ae golden model variants, we were able to quickly detect minor mistakes as soon as possible every time we created a new AMD variant for a subsystem. These minor errors would have been extremely hard to find if we started building the whole AMD FOC model and only compared the result to the golden model, instead of checking the simulation results of each individual subsystem.<\/div>\n
Consequently, when generating HDL code for the complete controller, we simply had to connect all the AMD variant subsystems in one model and verify that the final version of the AMD controller exhibited the same behaviour as the golden reference controller.<\/div>\n
However, the interfacing between the model composer blocks and the rest of the Simulink\u00ae tools proved quite tricky. This is where using the HDL Coder<\/a> provided by MATLAB\u00ae and Simulink\u00ae could significantly decrease the difficulty of matching an HDL design to its desired golden model, since the HDL-coder is both a lot faster than the AMD Vitis Model Composer when simulating the model, and doesn\u2019t require the same interfacing of the variant subsystems, since the HDL Coder<\/a> is compatible with the rest of the Simulink\u00ae model for running a simulation.<\/div>\n

Performance Testing – Commissioning and Data<\/h2>\n
Testing the new Controller on hardware commenced with verifying the Bridge Leg Timing (BLT) at the end of the control scheme. It was crucial to confirm the accuracy of the inserted dead time on the hardware. If both a high gate and a low gate are switched on at the same time, the result could be a catastrophic failure if it is not prevented by the hardware protection. The verification was conducted by injecting a hardcoded sine wave into the PWM carrier and analyzing the resulting switching patterns using the Integrated Logic Analyzer provided by AMD (Figure 11).<\/div>\n
<\/div>\n
\"\"<\/div>\n
Figure 11: Dead time validation at a switching frequency of 50 kHz, 50% duty cycle and a dead time of 350 nano seconds.<\/div>\n
\"\"<\/div>\n
Figure 12: Intersection of the sinusoidal voltage reference and the PWM carrier wave (top) results in the switching states (bottom).<\/div>\n
<\/div>\n
The PWM carrier frequency was set to 50 kHz, derived from the highest revolutions per minute provided by the PMSM, which was 28,000. Multiplying this by the number of pole pairs and dividing by 60 yielded the highest frequency of the sine waves required for sinusoidal PWM. As a rule of thumb, we wanted our carrier frequency to be 10x faster than our reference signal. By introducing a safety factor of two we ensured a clean sine-wave output, resulting in a switching frequency of roughly 50 kHz (Figure 12).<\/div>\n
Once the integrity of both the modulator and the dead time insertion was confirmed, we needed to validate the PI controllers used for the quadrature and direct currents. The controllers’ functionality was assessed by applying fixed current step values and observing the inverter’s output response. Both 5 A and 10 A current steps for id and iq were examined (Figure 13).<\/div>\n
\"\"<\/div>\n
Figure 13: Q-current step response of the PI controller for a 10 A step.<\/div>\n
\"\"<\/div>\n
Figure 14: Speed controller step response for a mechanical reference speed of 3000 rpm to verify the controller functionality. The measured quadrature current and its reference provide information about the inner current control loop.<\/div>\n
<\/div>\n
Following the successful validation of the current steps, we implemented both field weakening and the speed controller on the ARM cores. The speed controller was a simple implementation of a PI controller in C, running at roughly 10 kHz. This allowed us to run various test profiles on our testbench, where we drove one motor with a certain torque, and set the other controller to a certain speed set point in the opposite direction. Figure 14 shows the successful implementation of the controller.<\/div>\n
After verification of the speed controller, we wanted to make sure we correctly calculated and applied the desired quadrature and direct currents at various power set points. To minimize any risks during commissioning, we ran most tests at a lower voltage before checking performance at higher power points.<\/div>\n
\"\"<\/div>\n
Figure 15: Verification of field-weakening operation at 100 V DC link voltage and 5000 rpm mechanical reference speed.<\/div>\n
\"\"<\/div>\n
Figure 16: Controller\u2019s ability at 21.5 Nm.<\/div>\n
<\/div>\n
With the field weakening, current PI controllers, sinusoidal PWM, and BLT all validated, we wanted to start increasing the load and power to see if there were any limitations on the hardware side that we hadn\u2019t anticipated.<\/div>\n
We wanted to tune the various gains for ideal dynamics. By setting a reference step of 10,500 rpm, the controller applied the maximum torque available on the test bench of 21.5 Nm. This test’s success demonstrated the controller’s ability to utilize the full available torque and provide robust control.<\/div>\n
The final step was to assess the controller’s behavior at maximum speed. Utilizing the golden reference Simulink\u00ae model, simulations were conducted to anticipate the resulting sine waves of the phase currents. For this, a simple rpm ramp was fed into the omega controller. The ramp started at zero rpm and gradually increased to 28000 rpm, where it maintained its speed for three seconds, and then returned to zero rpm.<\/div>\n
With the test yielding successful results we were able to compare the current measurements made on the hardware to the simulation results of our golden reference model in Simulink\u00ae. This allowed us to affirm the accuracy of both the golden reference Simulink\u00ae model and the simulation developed for the design of the FOC control algorithm. Having these tools available and a relatively realistic representation of our hardware allowed us to make a rough estimate of the PI controller gains we should use and save crucial time during testing on the track.<\/div>\n
\"FOC_Sim_28krpm_big.jpg\"<\/div>\n
\"FOC_HW_28krpm_big.jpg\"<\/div>\n
Figure 17: Comparison of FOC simulation and hardware test.<\/div>\n

Our Perspective on the Implemented Method<\/h2>\n
In this segment, we would like to list out our challenges associated with AMD based on our experience:<\/div>\n