In the world of FSAE, aerodynamics are an interesting gauge of a team's level of advancement. Not all cars have aerodynamics packages, and many cars perform well without them, but you can tell a lot about a team by looking at their wings if they have them. Although aerodynamics packages are somewhat common among FSAE teams, active aero is a much rarer sight. This refers to when the car's wings are able to change their angle of attack while the car is driving. I can only recall two teams at 2024 competition with active wings, and one of those teams basically had their rear wing explode during their autocross run. Needless to say, these systems are very complicated to set up, with a combination of clever mechanical, aerodynamic, and controls design.

For a good number of years, our team at Terps Racing has sought after an active aero system for our car, but we have had little to no promising developments until the 2024-25 season. For this season, our aero team did a fantastic job designing mechanical linkages and simulating the benefits of the system (which we estimate to be 5% fuel savings across an endurance run). When the time came to consider the control method for the system, I volunteered to employ what I have learned as a computer engineer to help develop the software controller for the system. Most of our team is made up of aerospace and mechanical engineers, so I was uniquely qualified to work on the design

Our ambition for the system was to create a fully autonomous active aero system which would be able to adjust the wing angles automatically without the driver thinking about it. The few teams who have active aerodynamics often just use a simple DRS (drag reduction system) button that the driver has to activate, but in our analysis we found that the decrease in the driver's focus resulting from needing to hold down the button offset any lap time benefit that the system would deliver.

We wanted to use a machine learning model to determine what the wings should do, as the front and rear wings can adjust their angles independently so the car's balance can be adjusted by different combinations of front and rear angles, but in the short term we settled for an automatic advanced DRS system. For this system, I chose to design a finite state machine (FSM) to determine what the wings should be doing at any given time, as the machine could be designed to be simple with easily adjustable state transitions. It also meant that the servos controlling the wings only needed to be addressed whenever the state changed, which is preferable as the servos are quite noisy and draw a decent bit of power whenever their position is updated.

I started by defining three states: High Downforce, Low Drag, and Medium Downforce, and their corresponding state transitions. I made the decisions for the state transitions through discussions with our aerodynamics team, and selected the sensor values that the machine would depend on based on the need for graceful degradation (i.e. if a sensor fails, will the machine still behave safely). After defining the state transitions, we coded the machine in Arduino C (as the RP2040 which controls the servos is able to be easily programmed using the Arduino IDE). The code itself consisted of reading CAN values from our data unit's CAN bus, a next state function to calculate what the machine should do, and then an update state function to update the state and move the servos correspondingly.

After writing the shell of the next state function, I copied its structure into MATLAB in order to simulate what the machine would do using real car data. By doing this I was able to debug any mistakes in the state transition logic, and manually fine tune the transition parameters until they behaved exactly as we wanted them.

With a base set of parameters determined, I set up the data unit's CAN bus to send the necessary sensor values to the controller, and made sure that the RP2040 was receiving them correctly. Then it was time to test the system on the real car and do some further fine tuning of the parameters based on data and driver feedback.

The first goal with testing the system was to verify that it behaved the same in reality as it did in the MATLAB simulation. To do this, we set up cameras watching the car's wings, and drove a test course to observe and record the behavior of the system. We could then visually verify that the system worked the way we wanted, and we could also cross-reference the footage with the data put through the MATLAB simulation to confirm its accuracy.

The first test went well from a behavior perspective, as the system seemed to do exactly what the simulation predicted it to do. This was a big day for the team as it was crazy to see such a cool and advanced system working on the car for real (again, our team had been dreaming of an active aero system for quite a while). The only big issue from our first test was the system power consumption, as we were attempting to run it off of our DAQ's sensor power supply. The active system worked fine, but with the sacrifice of making our data unit (and consequently the car's dashboard) quite unhappy. After seeing this, we decided to give the board it's own power supply cabling directly from the battery via a cig-lighter port, as we already had a 2 port one in the car powering the dashboard (1 open port available to use). We also set up a software power saving measure by detaching the servos after a short duration when they were not being told to move, which eliminated the power draw from their self-centering.