Designing a Valve for a Rocket Engine

May 2022 – July 2023 | Technical University of Munich

A valve seems simple enough. Open, closed, maybe something in between. But ask me to design one that controls cryogenic liquid oxygen flowing into a rocket engine at 65 bar, that absolutely must close if power fails, and that needs to seal reliably at temperatures that would freeze most materials solid, and suddenly simple becomes complicated.

In May 2022, I joined WARR, TUM's student rocketry team, to work on Project Nixus: building a bi-propellant liquid rocket engine. The team split into subsystems, and I chose Fluids, where I was handed one of the most critical components in the entire rocket: the main valve that would control both the ethanol and liquid oxygen lines.

The team structure itself was interesting. Six of us were tasked with valve development, but instead of working as one group, we were split into three competing teams of two. My partner and I would design a sleeve valve, while the other teams tackled poppet and ball valve designs. The best design would fly. Competition as collaboration.

We spent weeks on the initial design. The sleeve valve concept was elegant: a cylindrical sleeve that slides to open and close the flow path, with dynamic seals on both the sleeve and shaft, and a simple PTFE flat seal. The whole assembly was about 10 centimeters long including the spring mechanism. On paper, it looked good.

The trickiest part was the actuation force. The valve had to be normally closed, meaning if power failed during a test, it needed to slam shut automatically. This meant working against spring forces while also overcoming seal friction and fluid pressure, all with whatever electrical power we could allocate. We ran calculations, built simulations, worked through the force requirements dozens of times.

Then we took our design to the professionals. Engineers from Ariane Group and ESA reviewed our work. They liked the design. But they had questions about our requirements.

"What's your maximum flow velocity?"

We showed them the number from our requirements document. They looked at each other.

"That can't be right."

It wasn't. Somewhere in the project's history, someone had calculated the maximum velocity of liquid oxygen through the valve and gotten it wrong. That number had been copied from document to document, year to year, without anyone checking it. The actual velocity was four times higher than what we'd designed for. Our valve was far too large.

Back to the drawing board. We redesigned everything. A valve four times too large meant completely different force calculations, different seal selections, different manifold geometries. We ran study after study on the manifold design alone, trying to optimize the flow path while keeping the valve as compact as possible. Every change cascaded into ten more changes.

The new design was better, tighter, more elegant. It was also impossible to actuate with the solenoids we could find. The forces were still too high. We went back through the design again, looking for anywhere we could reduce friction, minimize pressure differentials, optimize seal geometries. Meanwhile, we talked with the electronics team about increasing our power budget. Could they give us more? Maybe. How much more did we need? We weren't sure yet.

Months of iteration later, we had something manufacturable within our power constraints. Budget was still tight, and we couldn't make all the parts exactly as designed, but it was close enough to test. To ensure we could machine the critical components precisely, I learned to use CNC mills and lathes, spending hours in the shop getting the tolerances right.

Then came pressure testing. We pressurized the valve incrementally, watching for leaks. At low pressures, it held. We kept going. Somewhere below 65 bar, it started to leak. Not catastrophically, but enough. The valve showed promise, but it wasn't ready.

Meanwhile, the same story was playing out across all three valve teams. Different designs, similar struggles. By June 2023, with the Spaceport America Cup approaching, none of us had a fully reliable, flight-ready valve. The decision was made: we'd use commercial off-the-shelf valves for the competition. Proven, reliable, boring.

My focus shifted to preparing the rocket's fluid system for launch, working with the COTS valves and gaining hands-on experience with high-pressure systems. I ended up on the hotfire testing crew, responsible for documentation. Sitting in the control room during engine tests, watching propellant flow through systems we'd designed, hearing the engine roar to life, was worth every frustrating design iteration.

Then, a week before the competition, our structures team raised concerns about aerodynamic stability. The numbers didn't look good. After heated discussions and last-minute analysis, we decided not to fly. The rocket stayed in Munich.

The unexpected extra time gave us a chance to return to valve development. Armed with lessons from the first round of testing, I started a new approach: testing individual sealing points in isolation rather than the entire assembly at once. Understanding exactly where and why each seal failed would give us the data we needed for the next iteration.

Looking back, we never got a fully functional valve. But that was never really the point. The project taught me to question requirements relentlessly, especially ones that had been around for years. I learned that iteration in hardware is painfully slow compared to software, every prototype costs real money and real time, and sometimes the fastest path forward is admitting your design isn't ready and using something proven instead.

I also learned that engineering education often glosses over how much of real engineering is dealing with incomplete information, inherited mistakes, and constraints that change halfway through. We started with bad requirements, discovered them late, redesigned under budget pressure, and ultimately didn't finish. That's closer to real engineering than most classroom projects ever get.

The valve project taught me more about engineering than any course could. Not because we succeeded, but because we failed in interesting, educational ways. We built something that almost worked, learned exactly why it didn't, and understood what we'd need to do differently next time. In student rocketry, that counts as a win.