Second Year
Rocket AirBrakes
In 2024 the Waterloo Rocketry sub team, for the first time, began working on active in flight controls in the form of air brakes. A primary aspect of the competition we take part in is to most accurately hit a target apogee you declare prior to the launch of your rocket. In the past achieving this target was only possible through rigorous simulation and precision manufacturing, which in 2023, allowed us to be within 1500ft of our 30,000ft apogee, resulting in the 4th closest apogee amongst all 32 teams present (best in the hybrid/liquid engine category). This year we decided to try to further improve that result by introducing air brakes on the rocket. With air brakes we would gain the ability to actively control our flight thus more accurately being able to hit our target apogee. For the past year (2023-2024) I have been working as a key member involved on the air brakes subsystem, working the full stack from mechanical, simulations, and firmware.
First I did a lot of design research into what other teams have done in the past, as well as spoke to mechanical engineering professors at the University of Waterloo to come up with a design that me the following criteria:
-
Must only use one relatively low power servo motor to drive the mechanism
-
All 3 panels of the air brakes must extend simultaneously and ALWAYS be in sync
-
Rotational motion of the servo must be linearly proportional to the extension of the panels
-
Be as compact and light weight as possible
There are several mechanisms to address the first criteria, however finding one that was linear to meet #3 was challenging. Eventually I settled on the following cam and slot mechanism, however, the profile had been modified from the traditional slot profile to allow for a linear relationship between degrees rotated and linear extension.
Based on this I designed the spinning plate to include 3 of these spirals to move each of the 3 panels, and then built the rest of the design shown below around this.
While designing the mechanical air brakes I was also working along side one other team mate on Ansys computational fluid dynamics (CFD) simulations of the air brake panels to do two things.
-
Validate that by adding the air brakes we don't move the rocket's center of pressure (COP) too far in front of the center of gravity (CG) as to cause the rocket to be unstable
-
Determine our coefficient of drag (CD) at various different air brake extensions so we could develop a model that would be needed to begin work on the trajectory prediction model
Below you can see some visual representations of the simulations we performed.
Finally, the last thing I was involved in, alongside roughly 10 others on the subteam, was the firmware development for our flight boards designed to control these air brakes. While code does not present nearly as interesting pictures as CFD or CAD, it was nonetheless one of the most challenging and interesting parts of the project. We developed embedded C code on an STM32 microcontroller within a FreeRTOS environment, implementing Kalman filters for state estimation, 4th order Runge-Kutta methods for trajectory prediction, and a PID controller for dynamic control of the fin extension to achieve hitting a target apogee as accurately as possible.
The results of all this work? Well we still haven't launched our rocket yet, so I will update this page once we do!
Automated Measurement System
This system, was designed for quality assurance in industrial automation lines, it automates the validation of part tolerances right after manufacturing. Parts are placed on a rotary platform where computer vision, facilitated by Python and OpenCV, rotates each part for precise measurement. The system employs a moving clamp with a rotary encoder to gauge critical dimensions through force sensing, automatically halting upon secure contact with the part. Measurements are converted from rotary motion to linear distances, ensuring accurate dimension verification.
As the lead firmware engineer, I developed the core system functionalities using C++. My responsibilities encompassed programming the ESP32 and the main control unit to manage motor operations, dimension derivation, and the user interface. I also established a custom communication protocol akin to I2C between the ESP32 and the system's main brain. Additionally, I collaborated on integrating Python-driven rotation data into the C++ framework via web sockets, enhancing the precision and reliability of the measurement process. Any parts failing to meet specifications trigger automatic logging of the discrepancy, coupled with a visual alert on the display, ensuring seamless quality control.
Custom Communication Protocol
The VEX V5 brain is required to receive data from a PC regarding what angle it should rotate the object to (the PC is using computer vision to determine this, more on this below). However, because the VEX V5 brain uses proprietary software and firmware, standard communication protocols like UART, I2C, SPI, etc… are not available on the brain. The only thing that was available was the ability to read a wire as being a digital high, or digital low (0 or 1). Based on this our team worked on creating a custom communication protocol such that an ESP32 could be used as a middleman to wirelessly receive data from the PC and then send that data over 2 wires to the brain using our custom uni-directional, peer-to-peer, communication protocol, which was loosely inspired by I2C, carrying over the concept of a clock and signal line. We began by converting our angle into binary, and then transmitting it using our communication protocol (90-degree angle shown in the image above) to the brain, and then decoding this signal back into motor encoder ticks for the turntable motor to rotate the object to the correct orientation. There were several challenges, and innovations made regarding this custom communication protocol, though the details are out of the scope of this project. The result however is the system is able to receive an angle input from a PC wirelessly thereby being able to rotate an object to its correct orientation
UW REACT: FRC RI3D
With a grand total of 3h of sleep over the course of 2 days this was definitely an intense event. As team lead of UW REACT I had the responsibility of organizing this "robot in 3 days" hackathon style event, this meant a lot of work, both technical, and non technical prior to the event, and truly some of the "hardest fun I have ever had" during the event. Despite only having 30% of the member turnout I projected we would need, me and 4 other team mates scrambled over 48 hours to go from quite literally nothing, to what you see above. In fact the very nature of the challenge is you don't even know what your robot is supposed to do prior to the start of the challenge. This meant a lot of trips to Canadian Tire and Home Depot to grab extra supplies, despite doing A LOT of planning before hand to try to account for every raw material we might need. Despite the personnel and time constraints I think we did a great job of meeting the challenge objective (to take those rings and launch them into a goal), hopefully serving as inspiration for many of the high school teams that will get the next 6-8 weeks to work on their robots.