For today’s blog post, Veer Alakshendra is excited to welcome Joel Flückiger 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.
Who Are We
AMZ Racing was founded in 2006 by students of ETH Zurich, 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 students to learn and innovate together.
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.
In 2016, AMZ used one of their self-built formula student race cars “grimsel” to set a new world record 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.
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, setting a 0-100 km/h in 0.956s on 01.09.2023.
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’ll go over how we laid out our goals and why we decided to implement a custom solution for the inverter software. Furthermore, we’ll 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.
What Motivated Us to Break the Previous Record
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:
Figure 1
Maximize performance at 100 km/h: 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.
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.
Maintain accessibility for future use by the team members: 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.
Identify errors and safeguard the hardware: Much of the development focused on efficient error detection and hardware protection through simulation and testing. Using MATLAB® and Simulink®, 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.
Our Methodology
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.
Figure 2
Inverter Software Overview
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® dual-core Cortex™-A9 and a Field Programmable Gate Array (FPGA).
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.
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.
Figure 3
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.
One of the tools AMD offers is AMD Vitis Model Composer, which allows users to build a model in Simulink® 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 that will allow them to remain entirely within the Simulink environment for controller development and testing. More on that later.
Figure 4
Motor Control
Now to the fun part, the motor controller. Field Oriented Control 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.
The image below demonstrates the functioning of the FOC. To learn more about FOC, please refer to this video series.
Figure 5: Overview of FOC [1]
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.
Traction Control
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.
Overview of Simulink® Model
Having decided which motor control strategy we wanted to employ, we started building a golden reference model in Simulink® 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.
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.
The Simulink® 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™, which enables you to rapidly create models of physical systems within the Simulink® environment.
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.
Figure 6: Inverter subsystem
Figure 7: Motor, inverter, and battery subsystem
Figure 8: Motor controller subsystem
Hardware Implementation
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.
This toolchain allows for the translation of conceptual designs in Simulink® into functional hardware that can be deployed on the FPGA. Simulink®’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® model into HDL code, preparing it for synthesis and implementation onto the target FPGA device.
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® 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® variant subsystems. This feature afforded us the flexibility to select which model of a block in Simulink® 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.
Figure 9: Model with Simulink® blocks
Figure 10: Simulink® model with AMD blocks
Due to the seamless swap between AMD and Simulink® 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.
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.
However, the interfacing between the model composer blocks and the rest of the Simulink® tools proved quite tricky. This is where using the HDL Coder provided by MATLAB® and Simulink® 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’t require the same interfacing of the variant subsystems, since the HDL Coder is compatible with the rest of the Simulink® model for running a simulation.
Performance Testing – Commissioning and Data
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).
Figure 11: Dead time validation at a switching frequency of 50 kHz, 50% duty cycle and a dead time of 350 nano seconds.
Figure 12: Intersection of the sinusoidal voltage reference and the PWM carrier wave (top) results in the switching states (bottom).
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).
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).
Figure 13: Q-current step response of the PI controller for a 10 A step.
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.
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.
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.
Figure 15: Verification of field-weakening operation at 100 V DC link voltage and 5000 rpm mechanical reference speed.
Figure 16: Controller’s ability at 21.5 Nm.
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’t anticipated.
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.
The final step was to assess the controller’s behavior at maximum speed. Utilizing the golden reference Simulink® 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.
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®. This allowed us to affirm the accuracy of both the golden reference Simulink® 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.
Figure 17: Comparison of FOC simulation and hardware test.
Our Perspective on the Implemented Method
In this segment, we would like to list out our challenges associated with AMD based on our experience:
- We need proficiency in Model Composer, Vivado, and Vitis.
- Lack of experience in FPGA was another challenge.
- The time required for synthesis and implementation can impede development progress.
The workflow with HDL Coder is proposed as a viable alternative to program the AMD Zynq system-on-a-chip. It enables high-level design for FPGAs, SoCs, and ASICs by generating portable, synthesizable Verilog®, System Verilog, and VHDL® code from MATLAB® functions, Simulink® models, and Stateflow charts.
The transition from AMD to HDL Coder presents an optimistic outlook for streamlining the workflow and simplifying the deployment process, as depicted in Figure below. Despite challenges such as compatibility, the benefits of having a unified code base and direct programming onto AMD SoCs outweigh the drawbacks, rendering it an appealing option for future code development endeavors.
Figure 18: Possible implementation of the software and firmware with HDL Coder.
What We Are Working on Now
Hardware in the loop simulation for traction control
System modeling of power electronics enables the establishment of a hardware-in-the-loop (HIL) simulation environment for traction control. This setup involves utilizing one motor to simulate traction force and the other to represent the counter torque of the tire.
This setup proves particularly valuable for tuning controllers aimed at achieving a world record acceleration for an electric car, offering pre-tuning capabilities without the necessity of a car, test team, or track. To execute the vehicle model in real-time and provide the inverter with reference signals, the performance computational unit from Speedgoatcan be utilized. Operating the vehicle model at 200 Hz is both feasible and sufficiently rapid to accurately represent the maximal relevant tire dynamics at a frequency of 20 Hz.
For implementation, the power electronics hardware and motor control software must be replaced by Ethernet communication to and from the inverter. Moreover, the mechanical model and its associated tire counter-torque are no longer necessary as this feedback is realized on the test bench. Figure 19 below provides a high-level overview of the Simulink® implementation as described above.
Figure 19: Possible implementation of the hardware in the loop simulation running on the Speedgoat performance.
