priority inversion — my l2 Rocket
9:12 AM on Sunday, August 8th, 2021 (West Lafayette, IN)
After getting my L1 certification with my rocket Skydiver, I was ready to jump into my next goal, which was to get my L2 certification. If you haven’t, I would recommend reading about my L1 certification rocket experience before this article, as a lot of this content will build off of what was presented there.
The first thing I had to do was take and pass an exam that is administered by Tripoli. It is a multiple choice exam that features two main sections; one details rocket safety protocols and the other details rocketry basics such as what determines if a rocket is aerodynamically stable, and specific impulse. To do this, I showed up at a local launch near Purdue one weekend where I was able to take the exam. I am happy to say that after a day of studying I was able to get the minimum score needed to pass, with 100% on the safety section and missing 5 problems on the rocket section. Oh well; a 90% was passing and I am just thankful I didn’t have to take it again! To anyone who is looking to take the exam, I can confirm that it is pretty much word for word the practice problems that Tripoli has online.
With the exam out of the way, I just needed a rocket. In theory, I actually could’ve attempted flying Skydiver with a J, K, or L motor to get my L2 certification, but there were two problems with this: Skydiver was my baby, so I didn’t want to lose it on a large motor, and I wanted to do dual deployment. Dual deployment is a very simple technique to make sure your rocket doesn’t drift far from the launch site as it descends from apogee. The idea is that at apogee, the rocket will deploy a small stabilizing drogue parachute. This is just enough to keep at least some order in the system as it is falling back to Earth. Then, once a specific height above the ground is detected, maybe something like 1000 feet, an additional ejection charge will go off and the main parachute will deploy and slow the whole system down for a safe descent and landing. To do this, I wanted to make my own system that would detect this altitude, and then trigger an ejection charge using a MOSFET or relay. Besides this goal, there was also the implicit assumption that another camera system would get a ride on the rocket as well. For this, I simply duplicated my camera system from Skydiver.
So, the last question was of what I was going to build it out of, which actually has a very simple answer. The truth is that before Skydiver, I had actually bought a premade rocket kit with the intention of using that kit for my L1 and L2 certification flights. However, once I started learning about the whole build process, I really wanted to design Skydiver, so I went that route instead. So, I had a perfectly fine 4 inch diameter 6 foot tall dual-deployment-ready rocket kit by Loc Precision. All I would need to do is bevel the fins, modify the nose cone, and assemble the whole thing and I was golden. This was a welcome change after Skydiver, since by this point in the summer (early June) I had started an online class in addition to my remote internship. So, this article won’t be as build-focused because I didn’t have to make as many interesting decisions since it was just a kit rocket. Additionally, due to the time crunch on this build and since it wasn’t my own design, I took considerably less photos but I will do my best to detail the work that is actually important!
design and naming
In a footnote on the syllabus for my Systems Programming class this past spring was a link to a lecture on what happened on the Mars Pathfinder mission, and it had a catchy title: Priority Inversion. Intrigued, I clicked on it and read through the presentation and was instantly captivated. It’s no secret that embedded systems have caused some problems for spaceflight and space exploration before — just look at the overflow error that took down an Ariane 5 rocket. This particular example that was presented in my Systems Programming class comes from the Mars Pathfinder mission, which landed and then was promptly met with lots of issues, all stemming from a case of priority inversion, in which a high priority task is indirectly pre-empted by a lower priority task and is thus blocked, hence the resultant inversion of the relative priorities of the two tasks in the mind of the computer. Whew, was that a mouthful. I just found this really interesting as we were learning about task scheduling and mutex locks and semaphores in the class, and I noticed my own case of priority inversion occurring with this rocket — here I was balancing an internship and a class and this rocket was still at the forefront of my mind. So it seemed like a fitting name in more ways than one, and I ran with it. Thankfully, the software engineers for the Mars mission were able to correct the error, and restore the priority scheduling on the lander, which was something I was also hoping to do post-launch so I could focus on my class and internship.
For Priority Inversion, the only thing I really had to design were the nose cone modifications I needed to hold the camera system and then the design for the livery so I could cut out the vinyl decals with an X-Acto knife. Besides this, the rocket kit I had gotten already had a built in avionics bay and everything else, so there wasn’t much to do there. For the nose cone, I simply designed some canards that could be printed out and then epoxied to the stock nose cone that came with the rocket. This way I could cut out access ports within the nose cone so I could have a camera looking down one canard, and an indication LED and switch coming out of the other one for easy access. Very similarly to my L1 rocket, I used a 1/4 inch threaded rod to keep everything in place, and this was once again epoxied to the apex center point of the nose cone. This way I could just slide in the camera sled (pictured on the right below) on this rod. The other thing I needed was a sturdy bulk plate to attach to the nose cone. This is because in the case of dual deployment, the nose cone would be ejected, so we need a strong attachment point to attach a shock cord. To do this, I settled on a 2-plate system. One plate would be epoxied to the inner portion of the nose cone, and would have 3 T-nuts spaced evenly apart. This bulk plate has a large hole in the middle to allow the camera sled to pass through. Then, there would be a bulk plate which has a U-bolt. The camera sled would get bolted to the ends of the U-bolt that poke through the assembly, and then the whole camera sled and bulk plate contraption would be slid into the shoulder section of the nose cone so it is flush with the inner bulk plate that is epoxied in place. Then, everything is secured with 3 long bolts that go through the aforementioned T-nuts. I probably didn’t explain that too well, but it ended up working just fine so in the future maybe I’ll publish some content on stock nose cone modifications. Below you can see my CAD work for the nose cone, as well as a simulation of the toolpath that the CNC used to cut out the bulk plates. Note that the canards are each 3D printed with holes to insert threaded inserts into; this way the camera and switch/LED combo can be screwed securely in place.
construction
Like I had mentioned, the construction for this rocket was like clockwork compared to Skydiver since the components came precut. So, I just honed my fillet skills and endeavored to use less Bondo this time to reduce the weight. Unfortunately I don’t have a lot of photos from this time due to my busy schedule, but below are some highlights from the fillets as well as the painting. For this rocket I was also very wary of the attachment points, and made sure that all of my eyebolts were heavily epoxied since this rocket is considerably larger than Skydiver and would be launching on a higher power motor. Besides general assembly, this is also the point when I put together my nose cone modifications, which required some Bondo to look nice as well. I think if I had to do this again, I would probably mold my own nose cone again. Granted it was a long process, but I really enjoy the freedom of choosing your own shape, and how sturdy it is.
dual deployment computer
Since the main body of my rocket was premade, the main part of this project for me was the flight computer. The objectives for this computer were to:
track flight state (ie are we at apogee, are we descending, has the flight concluded)
have dynamic data logging (ie don’t log for 45 minutes, but rather log once ignition and ascent have been detected)
log xyz acceleration data, xyz rate of rotation data, altitude data, and temperature data
be able to trigger an ejection charge for the main parachute at a specified height after descent has been detected
emit a loud buzzing noise once landing has been detected for location
All of these tasks in their own right are relatively simple. For example, logging data was already figured out from the Skydiver flight computer. Emitting a loud noise is as simple as sending a high signal to an output pin instead of a low signal; likewise for triggering an ejection charge with a MOSFET or relay. The real challenge for me as a CS student was figuring out metrics to determine what state of flight the rocket was in. Some immediately come to mind and seem foolproof, such as apogee detection. For example, you could simply say that once you surpass 300 meters, you have reached apogee once your altitude readings are no longer increasing and are now decreasing. As one can imagine, this implies that you were going up and now you’re coming down, which means you’ve reached the height of your flight. But, how long did the measurements have to be decreasing? If you read one measurement and if happens to be decreasing, who is to say it isn’t a momentary fluke with the sensor? Read for too long to check the condition of ‘decreasing altitude’ and now your computer is behind, even if by a second. This was the hard part for me: how much is enough, and is it really foolproof? It really made me appreciate the safeguards and redundancy that people build into modern systems, because it certainly isn’t easy, or at least it wasn’t for me. I think the tougher part was that I couldn’t really test it until the actual flight. In the future I am going to devise data sets for mock flights that can test that my system can weather all of these edge cases, but at this point in time I just didn’t have the time. Likewise, I didn’t have a test rocket or drone to take the thing up on, so I settled on trusting my flow charts for the time being.
As for components, my first change was to get a better barometric pressure sensor. For this computer, I went with a BMP280 which gave beautiful readings that didn’t fluctuate randomly during tests which was a welcome sight. The MPU6050 worked well for Skydiver’s maiden flight so I kept that the same. Besides that, the other components I got were a MOSFET breakout board that I could use to trigger the ejection charge that would be wired to 18 volts (just to be sure!), a buzzer, and a micro SD card breakout board. At first I did test out this system with a 5V relay, but the mechanical stress the system experiences on ascent and drogue deployment made me table this design choice in favor of a MOSFET. As for the microcontroller this system would depend on, I went through a lot of internal back and forth. For all of these tasks, parallelizing them would be really nice, and very doable with a Raspberry Pi. Meanwhile, an Arduino made things so easy to interface with, with lots of preexisting libraries for the sensors and peripherals I was using. In the end I went with an old knock off Arduino UNO I had, because it had multiple benefits: easy to power because it had an onboard voltage regulator and DC jack, lots of pins to experiment with, and a relatively small form factor (not the smallest, but good enough for me). Once I had established this choice, I made the wiring diagram below so that I could reference it during assembly. Note that in this diagram, an LED is shown in place of the ejection charge.
Now, all that was left to do was CAD up a sled. The avionics bay on Priority Inversion consists of an 8 inch long section of airframe that has a diameter slightly smaller than 4 inches due to a stiff coupler that resides in the area for the bulk plates to rest upon. It has 2 1/4 inch threaded rods that run through the assembly, so I kept that in mind for the design, which is shown below. The idea is that the components get mounted on the front and back of the sled, with the MPU6050 on a little shelf in the center so that the readings are more accurate relative to the rocket this time. Due to space constraints, I also threw out the extra battery for the ejection charge, since some testing showed that a fully juiced 9 volt battery should do the trick.
By now it was the Wednesday night the week of the launch, which was that Saturday. I set up the sled to print overnight, and prayed that the build plate was level and it would be there in the morning when I woke up before work.
And thankfully it did! So, that morning before work I used my soldering iron to place the threaded inserts around the piece. Then, after work, I set about soldering everything together. In some instances I used jumper wires with Dupont connectors, such as in the case of the Arduino UNO which already had header pins soldered to it. This even further solidified my wish to make my own PCB as by this point I was quite tired but just needed the system to come together in time for the launch. Thankfully, I was able to get everything connected, at which point I began to put everything together for an ejection charge test. The idea of an ejection charge test is that you calculate how much black powder you need to blow the two airframe sections apart, and then test this amount of black powder and your system by igniting the ejection charge and making sure the parachute is ejected.
Here was my first mistake: the minute you’re working with black powder, you should be outside or at least in your garage. Embarrassingly enough, I assembled all of Priority Inversion in my living room, and then weighed my black powder charge in my kitchen. Then, I went back to Priority Inversion, and turned on my system and inserted it into the avionics bay. Then I went back and got my ejection charge, and wired it in, and then fully secured the avionics bay. By this point, everything was packed together. As a side note, the flight computer was not running production code at this point; rather, it had a script that waited until a button on the side was pushed, at which point it would beep out a 5 second countdown and then trigger the ejection charge. So, I was resting my fully assembled 6 foot tall 4 inch diameter rocket against my couch with a live ejection charge, when I hear the 5 second count-down begin. To my horror, the button must’ve gotten accidentally triggered before I could carry the rocket outside. In a moment of terror, I angled the rocket into a pillow, and then heard a small ‘poof’ as the ejection charge went off. To my great luck, the nose cone was hardly displaced and the rocket looked almost exactly as it had before, besides the acrid smoke now curling up from the rocket. I’m still not sure quite what happened, but I’m glad that either my black powder ejection charge calculations were off or that I didn’t pack it tight enough. This was the Thursday night before the launch, and at this point I knew I had to take a step back. My work was getting sloppy, and some black powder had just ignited in my living room. So, with a heavy heart I tabled the flight computer for this flight. Granted I could’ve attempted to launch later, but on the Sunday after the Saturday launch, I was flying back home to California and I wanted to have my L2 certification in my back pocket. So, I figured the flight would be good enough with the camera system all by itself and I could treat this launch as a simple one I could just enjoy since the stakes weren’t very high.
I’m currently working on fully implementing this system with a Raspberry Pi (now with ground telemetry!), and will write about that more soon, but my hopes of a flight computer for this launch were at this point, dashed. Some may point out that I didn’t need to include this rather embarrassing mishap in this article — and they’re right. But I think it’s important to show that everything doesn’t always go as you think it will, and that people make mistakes, and that that’s alright so long as you learn from them.
launch and recovery
To launch Priority Inversion, I went to Princeton, Illinois again for another Quad City Rocketry launch on June 19th. This launch was considerably smaller than the last one, so I was glad I got to know the ropes at the last launch. I prepared Priority Inversion with the help of my boyfriend, and got the camera system set up. Originally, I had intended to use a 48 inch main parachute and a 10 inch drogue parachute, but since I was now going single-deploy, I settled on a 36 inch main parachute. At the launch I also bought a J250 single-use Aerotech motor, as that was what I had used in my preliminary simulations.
By this time however, the crops around the launch site had gotten around chest-high! This meant that if your rocket drifted even 100 feet, it would fall into a thicket of corn that would eat your rocket up and quite possibly never give it back. Thankfully, one of the Quad City folks let me borrow his RF tracker, and I even got to learn how to use it. The idea is that you put an RF beacon in your rocket, and then use a directional antenna to locate it after it has descended. I’m very thankful I got to borrow the tracker, as if I hadn’t I likely would have lost Priority Inversion.
With the camera set up, ejection delay drilled, and tracker turned on, I was ready to launch! To the right is Priority Inversion on the launch rail, ready to go with the igniter in. Check out the launch footage below:
Priority Inversion soared to an estimated 2000 or so feet! Since I unfortunately didn’t have my flight computer ready in time, I didn’t get any concrete data but that’s my best estimate based on the footage and simulations. It was quite a sight to see it bolt up into the sky though!
Post-launch happiness!
Now, you may notice something with the onboard footage from the video on the right above. . . it’s terribly blurry! You see, with the time crunch I was facing, I had thought that since the system worked for Skydiver, that if I replicate it for Priority Inversion, it would work perfectly with no issues. Which was partly true, besides the footage being blurry. This was a painful lesson to learn, as it would’ve been such an easy fix, if I knew I had the problem. All I had to do was focus the camera, or possibly clean off the lens. But likewise, it was kind of funny because it was so simple, and in the end I’m just glad the flight went perfect, even if my systems didn’t. In the end my boyfriend and I were able to locate my rocket using the tracker deep in the corn, and recover it! Despite the trials and tribulations of this project, I was able to get my L2 certification the day before I left Indiana which made me happy. Now I have more experience, and can make sure I don’t make these mistakes as I continue to perfect these systems and make new ones.
To the left is my favorite photo from the launch; it’s right after I recovered Priority Inversion in one piece and knew I would get my L2!
what i would do differently
Check the camera system. Check the camera system. Check the camera system. A million times over, if I could do this launch again, I would’ve run a test on the camera system. Seeing that the video was perfect in every aspect except for it being blurry was heart-breaking, but I also couldn’t help but laughing. Of all the things that went wrong, I’m just glad that it wasn’t flight critical and that Priority Inversion gets to see another day.
This project also taught me a lot about the dangers an accelerated timeline can pose to a project, and its creator. Doing some things on the fly was really fun, like soldering up the flight computer. Other things though, like an ejection charge accidentally going off in my living room were not so good, and it did make me kind of sad that I couldn’t get the dual deployment computer ready in time for the launch date. But, I lived and I learned, and now I have a whole new set of experiences to draw upon for the next launch! I’m just glad I was able to get my L2 and I now have a license to spend even more money on more rockets. Onwards and upwards, right?