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.")
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.
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!
> 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.
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"
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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:
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.
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.
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.
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.
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.
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!
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.
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!
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.
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
"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%.
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.
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??
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.
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.
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.
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:
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.
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?
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.
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.)
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.
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.
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.")