Getting Good at GNC (?)
Part 2 of some reflections from the second half of 2024
Every year, I fly back to India for December break. The >16-hour flight offers a great time for reflection over the previous few months. These reflections in the past have included a wide spectrum, from planning goals for the next semester to thinking about my social life.
This time, I thought it would be good to take this time to finish part 2 of my SpaceX and grad school reflection.
Learning Engineering Lessons from the best
Most of the SpaceX teams my friends are on have a higher concentration of E1 or E2 engineers, some senior engineers, and occasionally a principal engineer (My view of a principal engineer is someone who's experience includes making significant changes to the way the company does things, on a BIG scale. It is not a title that is handed out lightly).
But instead of the occasional principal engineer, my team had my team lead, 3 principal engineers, a navigation expert, and 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.
I was surrounded by people who not only had immense amounts of GNC experience but also were willing to teach me. This was a jackpot opportunity. Unfortunately, the downside was that the benchmark was high, and during my first summer this led to a downward spiral in confidence in my ability as an engineer that I had never experienced before. My second summer, I knew what I was coming into and kept my mind focused on the simplest of goals: "Learn and deliver, don't overthink". Though it wasn't without its own setbacks, this summer went much smoother.
Overall, from the summers of 2023 and 2024, I learnt an immense amount from my cracked booster recovery GNC team. Here, I tried to put together the main lessons I learnt:
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, overengineered, 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. Basically, I now understand the importance of 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's a few failure cases where the design should have worked. Initially, I would just try 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. One of the principal engineers on my team would spend 3 days in an in-depth investigation of one simulated failure case and come out with more findings than I had probably in my entire month of doing patchy investigations over hundreds of cases. This methodical, patient method not only can result in a working design faster, but 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's going on flight-critical software. More on this in the next section.
Clear communication of design is key. No one knows your final solution better than you. 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. Make it clear enough that the imaginary 5th graders listening get it.
I realized that a lot of these lessons are relevant to engineering in general, not just GNC. In fact, I think a lot of this also applies to academic research.
Extreme Ownership
SpaceX strongly emphasizes extreme ownership amongst its engineers, whether they are Directors with 10+ years’ experience or interns who started a week prior. What does this mean? SpaceX doesn’t have “systems engineers” in the traditional sense of the word because every engineer is expected to be a systems engineer for their work. As the responsible engineer, it is your duty to understand everything that your work may affect and collaborate with others involved to make good decisions (I know interns who worked 1:1 with VPs). Many friends were pulling long hours not because their managers asked them to, but because they wanted to get their stuff working right and couldn’t rest until they were satisfied. I personally am still far from capable of making the best design decisions quickly, but even as an intern I was handed some pretty large responsibilities that pushed me in the right direction.
Another thing that's very common at SpaceX is questioning the requirements and deleting the part. It's the responsibility of every engineer to question the higher-level architecture of what they're working on, and think about how they can simplify the system. That could even mean deleting your project, as the best part is no part at all. SpaceX engineers take ownership very seriously.
"Delete the Part" vs. Academic Research
I've tried to incorporate the same philosophy of "question the requirements" and "delete the part" at Stanford too. The problem is that academic research tends to have a lot of projects that aren't actually useful. Some projects are also just out of curiosity (I'm working on one like that right now) but actually are not the best way to approach a problem. This is quite off-putting to me. I don't know if I'm being hyper-critical, or maybe I don't fully understand the motivation for all the projects I read about.
I want the project to be motivated by a strong question. Basically, a "why?" exercise. For a given project, keep asking yourself "why?" all the way until you're confident about your answer at every level. I’ve realized that it’s actually not very hard to find the gap in a particular stream of research to tackle, people talk about these gaps all the time. The harder task is motivating that gap in a strong manner.
I want to be driven by the primary research goal of “how can we better land on Mars?” and then tackle problems that directly address that question. There is definitely no professor at Stanford who is purely motivated by that problem, but there could be someone working on relevant research for that problem. Unfortunately, I did not find a solid problem statement here either, and no professor to help me with that problem statement. The current research landscape is, instead, asking questions along the lines of robot autonomy, i.e. how can we make robots operate better, on their own? That doesn’t really align with my motivation.
The other half of me went through another mode of logic: “just do a research project? It’s better than nothing”. I tried this but didn’t feel the same level of motivation, and since then have ended in a limbo.
So, here’s the conclusion I’ve reached: I’m going to continue with my “delete the part” method, and research the Mars landing controls problem from the fundamental level, and then decide what the problem statement I’m going to address is, then push hard to solve that problem statement as much as I can. With 6 months remaining, this is going to be a wild ride.
That’s the end of my two-part first blog! I plan on writing more stuff here, mainly related to personal opinions on controls, aerospace, and grad school. Some of my writing will probably overlap with stuff I post for The Overview. I don’t know, maybe I’ll do some live-blogging of the controls class (ENGR 205) at Stanford that I’m a course assistant for in the winter (inspired by Ben Recht’s live blogging of the convex optimization class at Berkeley). Stay tuned!
Anshuk