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.
Many calculus of variation (searching for extrema in function space) can be converted to a differential equation via Euler-Lagrange.
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.
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).
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
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.
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.
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.
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.
It makes one almost-impossible thing... possible. Not "easy".
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.
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.
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.
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!
Hats off for your project and what you’re trying to do!
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.
EDIT: Found I think [http://www.larsblackmore.com/nae_bridge_2016.pdf]
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.
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.
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)
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.
― Carl Sagan
If all you have is a hand. Even getting the wood to make a handle for your axe is hard.
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...
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.
Maybe our nuclear waste will fill the same niche in a post apocalyptic reconstruction of society?
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.
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!
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 . 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.
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!
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.
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.
Check out the pontryagin optimization module, which uses the maximum principle:
Other metrics are to maximize the final mass, or to minimize the final time.
min_thrust = 0.4 * max_thrust
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??
Raptor TVC test:
Merlin TVC test:
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.
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.
Because it helps with deceleration and with rotating the rocket.
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. :)
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.