Lessons I Learned as a SpaceX GNC Intern
And how they apply to engineering practice in general
During my senior year at the University of Illinois, a few friends and I worked on making a tiny “flying inverted pendulum”: A stick autonomously balanced on top of a quadcopter. It was a passion project of mine and meant to be a culmination of my long obsession with inverted pendulums. I went through the standard steps of building a control systems project: modeling the system, coming up with a controls scheme, setting up the hardware, implementing the algorithms in code, and putting it all together, and…it didn’t work. The best we got the stick to balance was about half a second, and even that was a fluke at best. What followed was a few all-nighters filled with haphazard parameter tuning and painful re-soldering of delicate hardware. It was not a pleasant experience and although I thought we were making progress at the time, we really were just running around in circles. This was not the way the professionals did things to get rockets to fly like straight darts or for landers to touch down softly on the Moon.
From almost the beginning of my career as an aerospace student back in 2019, I have focused on learning about and working on rocket GNC (guidance, navigation, and control) systems. But clearly, I wasn’t doing things the right way with my personal projects.
During the summers of 2023 and 2024, I got the chance to elevate my GNC experience from undergraduate projects to a professional setting as an intern on the Starship GNC team at SpaceX, working on making superheavy booster landing and catch a reality. I chronicled some other aspects of my internship in Tagg’s anthology article here: Aerospace Internship Insights - Part 1. My team almost entirely consisted of professionals with 10+ years of experience at the cutting edge of rocket reusability GNC. Among them was me, the intern. People say, "If you're the smartest person in the room, you're in the wrong room." Good, because I was the dumbest person in that room. Plus, these very smart people were willing to teach me, so I really had hit the jackpot. It was a daunting environment, but it was also the best place for me to learn the lessons that would fill the gaps in my GNC methodology that resulted in my personal projects never working.
My takeaways, distilled
There were many lessons I learned over those two summers that have helped shape my work as a GNC engineer, but below I’m highlighting a few key takeaways:
First, get to the root of the problem
Say you're starting a big project that deals with multiple systems that is going to be flight-critical or is a semester-long research project. My initial tendency was to spend about 3 hours understanding the problem, and then going head-on into getting results, thinking I'll figure out the rest along the way. This often led to convoluted, over-engineered, patchwork designs. But instead, if you spend a few days, instead of hours, understanding all the systems surrounding the problem, you'll have a significantly more elegant solution to the design. Understand the whole problem, why it needs to be solved, what systems are already in place, and what the simplest solution to the problem could be. This is also the first few crucial steps when taking on a project in academia and is generally covered by a good literature review.
Deep, methodical investigation is critical
Okay, you've understood the problem and implemented a solution, but when you test it, it just doesn't go well and there are a few failure cases where the design should have worked. Initially, I would just try to patch that problem at the surface level, test again, keep patching, and keep running simulations until things looked okay. This was too big a feedback loop to get to a working design in a reasonable time. Instead, once you see a problem in the results of your method, analyze those failure cases very carefully. A methodical engineer can spend 3 days in an in-depth investigation of one simulated failure case and come out with more findings than a hasty engineer can find in an entire month of doing patchy investigations over hundreds of cases. This methodical, patient method not only can result in a working design faster, but also in better designs.
Results need to be airtight
No one benefits from you saying, "Yeah I think this works okay-ish". Be confident in your design and have the analysis to back that up. Hand-wavy results that you think are mostly right won’t cut it in the real world. It might be exciting to see a pattern that looks cool in a class project, but you need to own all aspects of your analysis if it is going on flight-critical software. This also feeds back into getting a deep understanding of all your work. You don’t just want to deliver results; you want to make sure you understand how every aspect of your results came about.
Clear communication of design is key
This is a direct follow-up to the airtight results. No one knows your final solution better than you, so now it’s time to showcase all those clear results (and maybe even the points you are confused about) to your team as clearly as possible. When you're presenting these results, it isn't acceptable if your team has to keep asking you for the “why” or “what” behind each bullet point. That has to be presented by default, with all the findings shown as a clear story ending with the results you want to showcase. There are a lot of small rules that help this, such as avoiding acronyms, proper labeling, and good graph design (which is quite an art), but at the end of the day what needs to come through is a clear presentation of your solid results.
What all this means
As I was putting together these lessons for this article, I realized: all of these are just wider engineering lessons! They don’t just apply to GNC, and in hindsight seem kind of obvious. They all come down to reasoning with a methodical, clear, and critical mind through the entire engineering process. I realized that these are crucial points for proper engineering design, and analysis and apply whether you’re working on some academic paper or designing an expansive industrial machine.
Yet, I needed to learn these the hard way, by stumbling along the way with my own projects. Let’s go back to the starting example of the flying inverted pendulum. What did I do wrong there? Firstly, when I found out that the system wasn’t working as expected from simulation, I didn’t conduct a methodical investigation. I just started trying a bunch of parameters hoping I’d go in the right direction. What I should have done was realize that “if the real system was failing, then the model I used to design things is incorrect”. I should have then found where the differences were, corrected it, and then solved the next problem that arose. This would have helped deliver the airtight results I was aiming to achieve.
Lessons are easy to say and hard to implement. I still need to remind myself to follow these steps as I’m working on my own projects, and I don’t always follow them successfully. However, over time they are starting to become ingrained in my engineering methodology. The goal is that one day, they become second nature enough that future new hires learn the same lessons from observing my work. Hopefully, these engineering lessons resonate with your own past experiences, and you find them useful in your own future journey!
Anshuk
Very insightful! Thank you for sharing.