How SpaceX lands Starship (sort of) | Hacker News Reader

How SpaceX lands Starship (sort of)

thomas-godden.medium.com

280 pointszeristor99 comments

Rocket science is easy when you have a very powerful general optimization package available. Classic rocket science is trying to find closed-form minimum-fuel solutions for those problems. See "Hohmann orbit" and related topics. That's hard.

Legged running for robots is a very similar problem. It's under-actuated (more degrees of freedom than actuators) and constraint-limited. I worked out some closed-form solutions for legged running with anti-slip control back in the 1990s, which were later used in robotics work at McGill. Now you can probably just crunch a solution out of an optimizer.

(I used to make the comment about that, "It's rocket science. Which is good, because rocket science is a solved problem.")

“Solved” in the way that a mathematician views a bucket of water and a hotel room fire as “solved”.

Well, of course; having demonstrated the existence of at least one fire brigade, actually containing a blaze is best left as an exercise for your graduate students.

Shots fired.

>closed-form minimum-fuel solutions

My dad used something called variational calculus to solve physics problems. It's beyond my understanding, but I gather it was more useful in the slide rule days. A former co-worker of his commented that once you could just throw computing power at a problem, being able to construct the elegant solutions was basically obsolete.

Yeah, there was a similar comment from one of my greybeard coworkers. That one of the biggest changes he had to get over as engineering moved on over the years was the gradual shift from very symbolic, human friendly (one might say 'elegant') mathematics into more brute force, pure crunching techniques.

> was the gradual shift from very symbolic, human friendly (one might say 'elegant') mathematics into more brute force, pure crunching techniques.

Conversely, in these days when anyone can go buy themselves a couple of teraflops at the shop round the corner, when you look at the way they solved problems back in day it feels very strange.

But then, they didn't have a choice of course.

However, when you look at modern physics courses (worst offender IMO is standard quantum mechanics courses), where huge swaths of times are expanded trying to find closed form solutions to Schrödinger's equation, it feels very bizarre (and a giant waste of time).

Just the other day I used variational techniques to show the bound on a Mott transition in terms of electron density to an undergrad who had been complaining to me that they "hadn't learned any of this stuff in class just Dirac notation"

Trust me, calculus of variations is still used! It’s even more important now that we have lots of computing power. Actually, the major way we solve differential equations, the finite element method, is a variational technique!

> the finite element method, is a variational technique!

Many calculus of variation (searching for extrema in function space) can be converted to a differential equation via Euler-Lagrange.

And cleverly vice versa. Many differential equations can be covered to problems in viv. Computers are great at optimization!

> but I gather it was more useful in the slide rule days

It is definitely useful today as well. There is some modern work done on using variational calculus for solving real-world optimization problem.

See this book if you want: https://www.springer.com/gp/book/9781461489443

> My dad used something called variational calculus to solve physics problems. It's beyond my understanding, but I gather it was more useful in the slide rule days

In (theoretical) physics, variational calculus is such a basic tool, it is no more obsolete than trigonometry! It's also quite mind-blowing and beautiful, how a single quantity (the Lagrangian) contains all information needed to derive complete equations of motion for a system, or the correspondence between symmetries and conserved quantities via Noether's theorem.

as a former physicist i couldn't agree more. in fact you can construct a lagrangian almost uniquely from the underlying symmetries of the system. it's literally the most used tool in theoretical physics, and it's so powerful and elegant that actually convinced myself to do physics in the first place.

I would argue that it seems quite likely that Lagrangian mechanics is more fundamental, in some sense, than any other classical formulation. The path integral formulation gives you a mathematical trick for understanding how the lagrangian “generates” other physical models (like Newtonian physics) via its effect on action/phase.

I get where you are coming from, but if it was truly "easy", there would be a lot more self-landing rockets.

It makes one almost-impossible thing... possible. Not "easy".

I mean, if you have perfect measurements of the state of the rocket and a complete model of it then it's just physics.

Problem is that measurements are random variables and your model of the rocket is probably not perfect and now somehow you need to make it work.

Everything is "just physics"

That's true, I guess I was imagining more of a Newtonian approach, modern physics has everything.

Newtonian model gets you a rocket in a vacuum without atmosphere or vibrations made of indestructivle materials.

In the real world there is the atmosphere, fluid dynamics of the fuel, combustion stability, material science as engines have to withstand hot and chemically aggressive exhaust, etc.

It makes me think of the Laputans in Gulliver's Travels, the race of scientists that are so caught up in their theories they can't do anything practical.

No matter how difficult the problems are - it still costs billions of dollars to develop a rocket program, and disposable rocket programs have the "advantage" for the industry of a steady order supply... which means the industry has no incentive to push for reusable rockets.

SpaceX has the advantage of being funded by a billionaire who isn't beholden to any political demands (including job creation/upkeep), and so they can do whatever promises the biggest profit.

> because rocket science is a solved problem

Some time ago I wondered why rockets keep blowing up because I thought rockets would be a solved problem by now. Given the time and money involved in launching an object into space there is every incentive to make it go right.

I'm not an expert in rocket science, physics, or mathematics but seeing rockets blow up before having left the atmosphere makes me think it is not a solved problem.

You're thinking of engineering, not science. The math is more or less all figured out. But how to apply it so things don't break? That's engineering.

Semantically that's correct, but when talking about rockets people think about actual real rockets, not theoretical ones. I guess this is one of those instances where the words we use and their exact meanings differ from what we mean.

Even if you are going to advocate that view, there is more science to rockets than just the rocket equation.

From combustion instability, to materials and design of closed cycle engines to behaviour of materials in space it touches on many areas of science where the answer can not be off by 3% or the thing explodes.

Absolutely correct. Arguing that "rocket science is a solved problem" just because we have the rocket equation and the rest is just engineering is basically saying that condensed matter physics is just engineering because we already have a deep understanding of the behaviour of elementary particles in isolation.

Reductionism is a useful conceptual tool but it's important to realise that's what it is, not some sort of ultimate arbiter of truth. You need to consider a system in it's whole as well as in it's parts if you want to truly grok it.

I don't know if you've ever looked into what goes on physically in the combustion chamber or even just the turbopumps? We are far away from having the physics identified, let alone the math figured out.

E.g., combustion instability is one of those phenomena where an engine explodes, but we don't understand what's going on (sure, sometimes it can be mitigated).

Sounds pretty sciency to me.

One of my hobby projects is a real-time optimal flight controller for Kerbal Space Program rockets, and it also uses CasADi! It's an absolutely fantastic software package that makes it dead simple for anyone to set up and solve NLP (nonlinear programming) problems. Indeed, a lot of hard work goes into making an online solver that can run in a reasonable time. I already have launch working quite well, but precision landing has proven more difficult.

For the initial trajectory, I use collocation (https://en.wikipedia.org/wiki/Collocation_method) to encode the physics constraints. For updates, I use the previous solution as the initial guess for the updated trajectory. In practice this seems to work quite well, but there are still some issues I need to iron out. Sometimes the trajectories it provides are unstable in the sense that if you slightly overshoot, it will generate a radically different solution. I believe the solution here will be to turn some of the constraints in my solver into soft goals instead.

It's difficult for me to say whether this is evidence that SpaceX definitely uses optimal control for their flight control, since we would naturally expect any reasonably efficient control algorithm to produce a similar trajectory. After all, if you have a solution that's 99% efficient, how much slack is there in a trajectory using only ~1% more time than the optimum? However, I would not be surprised if they do that - I'm just wondering how they test it, since my setup seems so finicky!

I’ve been using program blocks in Space Engineers to play with some parameters as well. I still need to install the orbital mechanics mod though. The math is incredibly hard (if you have basic training) , even if you have a simple model, but it’s fun to figure out.

Hats off for your project and what you’re trying to do!

There’s one really important aspect of starship control that this article mentions... starship control is stochastic. Spacex needs to minimize the area of an ellipse that represents the likely touchdown area of the craft. To do this they use another trick... they continuously recompute the optimal trajectory, in real time. Lars Blackmore has a paper on the process!

Yep, Lars learned GFOLD at JPL and took it to Spacex. GFOLD was invented by Behçet Açikmeşe https://www.aa.washington.edu/facultyfinder/behcet-acikmese

Though as I understand, spacex doesn’t actually use GFOLD, but a related (and secret!) development

Not to accuse spaceX of anything, but I've witnessed companies sell 'hyper-localised weather" where they take public weather information and average the nearest two datapoints to you.

So I always take 'secret' 'proprietary' data and algorythms with a bit of salt, as almost every time I dug into them, it was all spin on previous public stuff.

In this case, SpaceX is actually landing those Falcon boosters pretty reliably now. So maybe their secret proprietary stuff isn't as advanced as they make it out to be, but whatever they're doing it does seem effective.

The two have apparently co-authored the relevant papers. So perhaps both of them "learned GFOLD at JPL" in the same sense.

This sounds like model predictive control. Does anyone know the difference between the methods?

You can implement it as MPC and minimize e.g. the trace of the covariance matrix that describes the state uncertainty. Wrote my thesis on something similar.

Cool, do you have a link for the paper?

EDIT: Found I think [http://www.larsblackmore.com/nae_bridge_2016.pdf]

This is very interesting and I appreciate the author's take on his own work: That it's not, by a long shot, the whole solution. It's great that he modeled the physics and all, and he acknowledges that the amount of work to turn that simulation into a landed rocket is just staggering.

The scale of the complexity comes seems analogous to the complexity of starting with nothing- no raw materials- and building something complex like an internal combustion engine.

Step 1: Find iron ore. Wait, what?

Step .5 answer "What is iron?"

Step .4 "What is ore?".

Step .3 "shoveling is hard."

Step .2 Banging rocks together.

The author says exactly that at the end of the article:

Its tempting to go “woah I just figured out how SpaceX lands their rockets!!”, but sadly, that’s not really true.

Once you have generated a physically possible trajectory that gets you where you want to go, there’s a whole host of things that you need to do to actually go follow that trajectory: state estimation, closed loop feedback control, dynamically updating that trajectory based on real time conditions… and many more that someone who is an actual aerospace engineer (which I am not) would know. Beyond that, these solvers take a long time to run, and online (real time) optimization is incredibly hard to pull off correctly and safely: one wrong input and your solver could just spit back “fail”, causing the thing to fall out of the sky.

Indeed I was trying to allude to his own take on it, that it's just a fraction of what's needed. I reworded it clearer. :)

yeah, just not in the title. He's in fact way off.

This sort of thing always runs into 'need the tool to make the tool' loops, where you end up substituting an inferior version long enough to get you to the next level.

Bootstrapping a working metal workshop from first principles would require you to re-run a substantial part of history including the re-invention of lost processes. You'll also likely get killed because quite a few of those processes are anything but safe. Our modern days materials science is very hard-won knowledge, and there aren't a whole lot of shortcuts on that route even if you have the knowledge itself.

Indeed! After I posted I remembered the book "How to Invent Everything" which takes the case of a time traveler stuck in the past with a guide to invent civilization from scratch. It's a cool read:

https://www.howtoinventeverything.com/

Looks interesting, thanks for the recommendation. Another one is "The Toaster Project", about how a guy made (well, sort of) a toaster from scratch:

http://www.thomasthwaites.com/the-toaster-project/

Bootstrapping civilization is a bit of a sub-thread in the three Zones Of Thought books by Vernor Vinge. Definitely my favourite SciFi books

I got bored in the second one when I realized there wasn't going to be any space travel, but otherwise I agree.

Assuming you mean Children Of The Sky (second as in sequel to the first one published), that one actually deals with this topic (bootstrapping technological advancement) maybe more than the other two.

I assume you didn't mean A Deepness In The Sky (second published, but almost stand-alone, super interesting dealing with practicalities of interstellar civilization in a universe with real speed limits) or A Fire Upon The Deep (second in-universe timeline)

I can't keep the titles straight, but yeah, I think it was Children Of The Sky. I just remember the story wandered away from scifi into political intrigue and didn't really move on from that.

There was also a lot of discussion about bootstrapping technological advancement in the first book published, which was interesting.

Clickspring more or less did this with his antikythera mechanism build

Thank you, I'll have to check that out.

> Step .2 Banging rocks together.

a cpu is just a rock that we tricked into thinking. but not to make it seem overly simplified, first you have to flatten the rock and put lightning inside it.

:%s/thinking/computing/g

You're missing quotation marks around that quote.

“If you wish to make an apple pie from scratch, you must first invent the universe.”

    ― Carl Sagan

The YouTube show How to Make Everything. Did this. They started the tech tree from the very beginning by making simple hand stone tools and then building up tool by tool to more sophisticated technologies.

If all you have is a hand. Even getting the wood to make a handle for your axe is hard.

https://youtube.com/playlist?list=PLLXfVEsLI-qRC_MAQZcVxpjtF...

Seems to me like a lot of the difficulty would be that the natural resources you need, in the absence of civilization, are scattered all over the planet, let alone deep underground.

I vaguely remember reading something about how even in the earliest days of making flint arrowheads, there were massive centralized mines that archaeologists have found. It wasn't like just because you were in the stone age chipping rocks, every location was equally accessible to the resources you needed. Similar to now, where you need a particular type of sand for concrete, or for fracking, or...

Interestingly there's technologies we might not be able to replicate if needed, as we've mined out the purest resources that we know of.

Particularly nuclear technology, since so much early experimentation was dependent on ores like from the Shinkolobwe mine in Congo with 65% uranium. These days finding ore with 1% uranium is considered a good find.

https://en.wikipedia.org/wiki/Shinkolobwe

Maybe our nuclear waste will fill the same niche in a post apocalyptic reconstruction of society?

For one thing, it seems like the change in fuel mass, and its centroid relative to the body center of pressure, would be kind of important. But this was super- interesting as is. I’m glad it was posted here.

This is awesome! I'm working on a similar hobby project (an avionics software programming/simulation game) and have written some basic avionics software to fly/land Starship [1]. It's really satisfying when simple simulations give results that are close to reality.

The StackOverflow blog posts and this blog have been very well timed for me - I have a good list of things to learn more about now. In the initial avionics software that I've written I'm using a fairly simple approach involving a lot of PIDs to keep the ship on a predefined track. So getting some more dynamic trajectory plans in there will be a fun thing to explore!

[1] https://www.youtube.com/watch?v=TdLv62ZVl6I

Cool! I've been playing around a bit with X Plane and the library NASA open sourced for getting simulator data to see whether I could get autopilot software to fly upset recovery maneuvers better than pilots. What are you using?

It's a really interesting and fun area of programming to explore, did you have any success? I think I saw that the XPlane developers released a Starship model for their simulator too, which could be fun to play with.

I'm using Unity for the front-end visualisations, then the simulation & avionics are run on a headless server that currently uses Havok (realtime physics engine for games) with some layers to add aerodynamic forces and some tweaks to try to keep things as realistic as possible. More info & code behind the aerodynamics here: https://avionic.dev/blog/simulating-aerodynamics/

This video: https://youtu.be/GSJPm4uG42M is probably more interesting to the HN crowd than the one I shared in my last comment, and gives a little more context as to what's going on behind the scenes than the abstracted UI dashboard.

I had some initial succes in having the code do the same steps as UPRT training teaches pilots:

1. Unload the wings (usually push the stick forward)

2. Roll shortest path to level (easy to calculate, but needed a bit of tweaking to make a smooth roll input)

3. Set power according to energy state (slow = set full power, fast = set idle power)

4. Pitch back to level (9 out of 10 times this means pulling out of a dive)

Easy to combine 2 and 3 at the same time, more tricky than for humans to get 4 correct because you're often in an overspeed condition where just pulling sharply up will over stress the airframe. But if you take too long you're losing altitude rapidly and may hit the ground.

I think the correct software solution would be to always aim for a min(3.8, stall load) G pull (the maximum is 3.8 for a normal aircraft to not break), calculate the expected altitude loss for current speed and if you're going to hit the ground pull as hard as you need to miss the ground by a small margin and hope the aircraft doesn't break apart. I haven't written any code for that last part.

And I haven't added rudder input to it other than using the standard function to coordinate rudder with ailerons when rolling level (the sim has this built in).

If the airplane gets as far as to enter a spin condition the procedure above will no longer work and you really need rudder. And the power change for a prop driven aircraft or an asymmetric thrust situation in a multi-engine then has to happen at the start, everything idle even at low speed. So here you enter a more complicated area to determine what the state is and adjust the response as opposed to following the standard rules.

Really interesting, thanks for sharing. It will be a satisfying challenge to complete when you get it working reliably. I'd love to see more information when you're ready to share it, a blog post or video on that kind of dynamic control recovery would be super interesting!

I'll try, it's a very slow moving hobby that got a boost from lockdown but I'm now back to flying so a bit less time. Once I have something that works or is a good foundation for others I'll definitely put it on Github.

Nice work on the sim, that's really cool! Love the synced video as well.

This is such a fun space to fiddle around in as an amateur. I've been experimenting with using actor systems for automating Kerbal Space Program with the KRPC extension; first projject can get a Vostok-like ship into orbit [0]. I thought I knew quite a bit about rocket guidance & control until I started writing these wee projects! And that's even using the simple "auto-pilot" built into KRPC to keep the rocket pointing in roughly the direction I tell it. I've been very slowly starting out on a new system which uses parallel WASM runtimes, so you can program rocket control in any WASM-targetting language. Starship/Falcon style landings are definitely one of my goals.

[0] https://github.com/dmfutcher/strelka

Really cool project! I initially was planning on using WASM for running avionics in my project too (it's browser based so seemed like a good fit) because the amount of language choices that WASM gives you is pretty great. But my current plan is now to run the user's code through a sandboxed compiler in order to execute it. For each 20ms step, vehicle telemetry is passed in to stdin and system control commands are read from stdout.

I've starred your project on GitHub and will definitely check it out in detail later! It's so great to see other projects that explore this space!

FYI, the ESA (European Space Agency) has a python package, pykep, that implements these types of algorithms for you: https://esa.github.io/pykep/index.html

Check out the pontryagin optimization module, which uses the maximum principle: https://esa.github.io/pykep/documentation/pontryagin.html

"Minimize thrust output" is not a great constraint - the most efficient landing would run at 100% thrust to minimize the time spent thrusting against gravity. Another thing to take into account, which is that rocket engines have a minimum throttle setting, which for the Raptor is 40%.

“Minimize the integral of thrust probably would do ok as a proxy for “minimize the amount of fuel required”

Usually it is "minimize the integral of the thrust acceleration" (T/m).

Other metrics are to maximize the final mass, or to minimize the final time.

Yes but if the 100% thrust exceeds the mass of the rocket you need to exactly offset your momentum so that you reach zero velocity exactly as you touch down, which requires very precise timing and doesn’t leave much margin for error. Time it too late and you RUD. Too early and you stop short, run out of fuel, and then also RUD.

At least for Falcon 9, this is true even at minimum thrust. They don't have the ability to hover at all. The rocket is so light when empty that the thrust of a single engine at minimum throttle during landing is enough to make it take off again. That's why they do a "hoverslam" or "suicide burn" as you described. I assume they still throttle down as much as they can in the last few moments to minimize the impact of imperfections in the landing.

They likely just target a trajectory that falls at the center of their throttling capability. The controller can then handle a limited amount of trajectory error by throttling up or down. I.e. if they can throttle down to 70%, then they would compute a trajectory that would nominally require 85% thrust.

It does take that into account, the code given included:

    min_thrust = 0.4 * max_thrust

from this article, it seems like the thrusters must be doing lots of little micro-adjustments, similar to balancing a pencil upright on your hand, or riding on a Segway, correct?

I'm super interested in understanding what the actual mechanism is like for "aiming" the thrusters in different directions. I imagine they must need freedom of movement in a full 360-degree circle to adjust in all possible directions. How the hell is that achieved??

Gimbals -- https://en.wikipedia.org/wiki/Gimbal#Rocket_engines

What you're looking for is Trust Vector Control(ler). Most modern rocket engines physically gimbal the engine around with ~two linear actuators around a fixed point at the top of the engine. All of the plumbing and connections to the rest of the rocket must then be flexible.

https://en.wikipedia.org/wiki/Thrust_vectoring#Gimbaled_thru...

If you watch a video of a booster or starship coming down you can see the engines twitching around, pretty cool

The thrust vector control method in this case is gimbaling, and it basically means using linear actuators (I think these are commonly hydraulic, and Falcon 9's Merlin engines actually use the kerosene fuel in the TVC hydraulic system) to point the engine in a different direction:

Raptor TVC test: https://www.youtube.com/watch?v=3pD5CZZfnYk

Merlin TVC test: https://www.youtube.com/watch?v=Pigsq5rt-mY

Are you saying that they use kerosene fuel in place of hydraulic fluid? If so, wow, you just blew my mind. Would that be to save on weight?

Probably just as important to save on complexity.

Yeah, critically the rocket engine turbopump already produces very high pressure kerosene and liquid oxygen; so why not tap off some kerosene there instead of building a separate hydraulic pump system?

IOW, the best part is no part.

As others have said, there's already a turbopump providing kerosene at a high pressure. Also, the hydraulics are open loop; the dumped low pressure kerosene is fed into the engine. That's a lot simpler than a closed loop system, or an open loop system with a dedicated supply of fluid. There's no risk of running out of kerosene for the actuators because as soon as you do, you can't thrust anymore either and so the actuators don't matter.

They also use the kerosene to cool the engines' nozzles before it gets combusted. This keeps the nozzles from melting, and preheats the fuel so it combusts more efficiently.

Besides gimballed rocket bells, it looks like they also use side venting of fuel, oxidizer, or inert gas. It's not steady, it starts and stops apparently to give an extra torque moment when rotating the body or stabilizing the upper end just prior to and after landing.

https://youtu.be/Y_9FZDnCaoU

The big vents about midway up the vehicle are gaseous depressurization vents for the methane and liquid oxygen tanks; the RCS (reaction control system) that's designed to provide torque has thrusters at the nose and tail (to maximize the length of the lever arm.)

https://youtu.be/6iBnXy1ag8A?t=109

There's a fundamental difference between balancing a rocket on its thrust, and an object on a surface. The surface pushes up, the rocket thrusts along its axis. When the pencil strays from the balance point, the normal force of the support produces a net torque pushing it further out of balance. The rocket doesn't have that problem.

Here's a little montage of a project I did involving thrust vectoring for a model rocket!

https://youtu.be/pobaR6kSajg

A "fun" problem with thrust vectoring and multiple engines is that the engines can most likely physically interfere with each other when actuated to their opposite extremes. There may or may not be some software somewhere to explicitly prevent nozzle collisions, but it's kind of a no-win situation if that software needs to kick in. If the controllers are commanding thrust angles that the engines can't physically achieve, then the rocket is probably going to blow up anyway. In some ways it's better to just let the engines smash into each other and hope for the best, if it gives the controller slightly more control authority in exceptional circumstances.

You can see them adjusting in the last 30 seconds or so of this SN15 recap: https://www.youtube.com/watch?v=7CZTLogln34

This animation shows some of the movements the engines can pull off https://www.reddit.com/r/SpaceXLounge/comments/kf25kr/starsh...

In the recap video they are only using two engines though. I think on SN15 they relit all 3, and then the guidance computer picked either the two most stable (in the case one of them didn't relight properly), or the two with the best lever arm for the landing trajectory, then shut the remaining one down. Earlier landings tried just one (I think there's enough thrust and maneuverability to do it) but there was no redundancy if it failed.

SpaceX definitely use a dynamic solver, if only because they have to correct for wind gusts during landing.

I'd love to see this algorithm play Flappy Bird, seems like a similar challenge

No mention of drag apparently. It's a nice write-up but that is an important point that was simplified.

Because it helps with deceleration and with rotating the rocket.

Awww I’m disappointed his solver started in a bellyflop position. Would be interesting to see if a vertical position at higher altitude and higher velocity could discover the bellyflop maneuver.

That would also require a variable initial fuel. Which is itself dependent on takeoff.

Ok so now solve the full loop from launch, peak altitude/position, and return. :)

This would require adding the force of drag to the dynamics timestep, since the purpose of the belly-flop (after re-entry) is to minimize terminal velocity by maximizing drag. Currently his solver assumes no drag.

Calculating the drag on an ideal cylinder is non-trivial to begin with. It gets vastly more complicated once you start adding the flaps, which are what Starship uses to get itself into the belly-flop position in the first place. Simulating the whole belly-flop maneuver isn't going to be feasible on the scale of a blog post.

Great project, makes a complex topic easy to follow

There's a nice game that simulates this on iOS. Falcon Lander - SpaceX Edition

Reply on news.ycombinator.com