Florence is ARES’ entry into the 30k COTS category of the 2024 Spaceport America Cup (IREC). When I joined UoM’s rocketry team half-way through 2023, ARES had just begun early development of what would become ARES most drastic change in design philosophy. It was designed in the wake of Project Deimos’ catastrophic failure at the previous competition (SAC 2023), failing due to a combination of fin flutter, instability, and extreme deflection of its thin body tube. ARES rockets had historically featured an aerodynamic transition to minimise parasitic drag while still fitting a 3U cubesat payload inside. Florence shifted to a uniform diameter to avoid the multiple failure modes that plagued Deimos, as well as featuring a brand-new single-separation, dual-deploy recovery design concept, student-developed avionics, and an air brakes active control system. I joined the Aerodynamics sub-team and within the month I was promoted to sub-team lead. I was in charge of drag analysis for the entire rocket to both ensure airframe parts were designed with minimal drag, and to increase the accuracy of trajectory simulations later into development. My job was to make sure ARES’ chunkiest rocket to date would still make it to 30,000 ft.

Deimos (left) and Florence (right) compared at similar scales.

Drag Analysis in Ansys Fluent

As a first-year undergraduate, I taught myself computational fluid dynamics in Ansys Fluent in incompressible and compressible flows up to Mach 2. I was helped early-on by the existing work done by the previous Aerodynamics lead which focused on the model settings required for an accurate drag result for supersonic rockets, and I combined this with sporadic lecture notes and videos to cover the subsonic flow regimes. I managed to organise weekly meetings with the lecturer for the CFD subject at my university, who helped greatly with running my simulations on the University’s high-performance computing system. By the end of semester, I had developed ARES’ first workflow to produce drag curves of our rocket, and the meshing techniques that are still used by the team to this day. CFD simulations in Ansys Fluent were automatically run in a batch job with scripting in Bash and Python, which swept over Mach numbers and automatically changed boundary conditions after the previous simulation converged, recording the drag value in a table. I would later iterate on this workflow to sweep over other parameters including geometric ones, which was helpful in the aerodynamic optimisation of the next project, Lemaire. I used my workflow on canonical models to verify simulation accuracy, and wrote detailed reports on each investigation from geometry creation to post processing to ensure the rest of the team (which at the time had no CFD capability outside of me) understood my work and could replicate it in the future.

Flight Modelling and Air Brakes

During Florence, I worked closely with the Simulations sub-team to make ARES’ most accurate trajectory predictions to date. Drag data from CFD simulations were utilised in RocketPy (a Python library) to predict the apogee of the rocket before launch, later verified in multiple test flights to be accurate to within 1%. I also developed my own simpler 3DoF MATLAB and Python scripts to help inform aerodynamic design decisions about the air frame.

Thank you to Nick Cotugno Morrison for these two visualisations.

CFD and RocketPy were also used to develop what would eventually become a PINN-based model predictive control system for active apogee control, utilising air brakes. CFD drag curves for a sweep of air brake extensions were used to produce an enourmous array of trajectory simulations from any possible state the rocket could be in mid-flight. These data were compressed by a PINN such that apogee-prediction (i.e. navigation and guidance) could be done live on the flight computer. The computer then found the air brake extension that produced the desired apogee via binary search, and commanded that extension.

Air brakes control scheme block diagram.

On the side, I used my CFD skills to help the team answer troublesome fluids-related problems. This included quelling concerns about the size of the camera hole on the side of the rocket, where I used a dedicated high-fidelity simulation to show the added drag (and induced moment) was negligible. It also included solving a mysterious feedback issue in the air brakes control system, where the pressure readings inside dropped immediately after the airbrakes deployed (which caused the control system to retract them). Any arguments about how Bernoulli’s principle applied in this situation quickly disappated when CFD post-processing showed exactly where the pressure loss was coming from. Tuning the air brake model also frequently required processing flight data from test launches, filtering barometer and accelerometer data to back-out the rocket’s Mach number and experienced drag. These little problems not only expanded my skillset in CFD analysis, but built skills in data analysis and intra-team communication that were useful far beyond the field of CFD.

I also found an interest in producing more stylised CFD results (for aethsetic purposes only, of course).

Competition in New Mexico

Florence was my introduction to ARES and the brilliant people that made it thrive. It was my first time working with like-minded people on such a demanding project and I learned so much more than how to simulate supersonic air. At the culmination of the project, I went to the U.S. with the competition team and made memories with my closest friends at university. Florence flew to 29,782 ft - just 0.7% off target apogee - which earned us the No. 2 spot in our category and No. 4 overall at SAC 2024. My love for CFD and flight modelling never left me, and even though I would work in larger and more diverse fields later on, my truest passion has always been in knowing where rockets would go before they arrived at the pad.