Another interesting thing SpaceX is doing is to use consumer-grade chips in triple redundancy configurations instead of using $100,000+ radiation-hardened aerospace/defense grade chips.
If it's no stronger than a sudden wind gust, it's just something the controller has to be able to take care of without a heads-up.
Then the next launch crashed due to slosh induced oscillation - and the one rocket after that had anti-slosh baffles. ;-)
More fluid dynamics
By their very nature model predictive controllers operate in a world where not everything is perfectly modelled. Engineers do their best and whatever is left is the "error" the controller is trying to deal with.
Sort of like how you can balance a few pitchers of beer on a tray in your hand by remaining aware of the weight, even when people remove one! hahaha :)
Which is why we use wind tunnels, for example.
These are indeed heavy computations. What I meant is that VoF is one additional equation to be solved besides the N-S equations (either filtered as in LES or Reynolds-averaged as in RANS), the energy equation, your turbulence model equations, and so on. Certainly, not instantaneous at all, but simply an additional "simple" model that we can hook into our current way of doing CFD.
So, my point was, sloshing is a problem that we know how to simulate, although certainly you need HPC resources. Though, looking at those 100k NVIDIA H100 Elon has, I guess they have them! :P
I think it's a huge problem when re-lighting the engines in orbit, though.
Bug tanks make sense there & they might not be always full. So I can imagine all kind of interesting ways you can work with the fuel in zero go to avoid not only slosh but also the need for ullage thrusters. Eq. some programmable nozzles using in-tank gas to nudge liquid fuel blobs to move in the right direction. Or even some nets or bags that herd in the fuel in the middle of the tank + prevent it from directly touching the side, reducing boil-off or refrigeration requirements. :)
Even a real-time simulation should have some measurements to self correct to some degree. Otherwise it'll diverge.
They used trios of regular consumer grade disks/servers etc as a cluster and it looked like a single node.
They had to replace a LOT of hardware but this was still cheaper than big iron industrial grades servers.
This has been known in the high availability and safety systems industry for a while and a good book to learn these reliability engineering techniques is "Reliability Evaluation of Engineering Systems".
The book is available on amazon: https://a.co/d/1nH824K
https://www.epa.gov/radiation/radiation-basics#:~:text=Gamma....
Maybe you could improve the system availability considerably by a bit of gamma radiation protection combined with some more parallelism of the components ..
A second layer blockage for the secondary particles wouldn't have to be as dense or am I missing important physics?
(I guess a lot of gamma radiation would still reach this second layer so please ignore my question :)
https://www.wolframalpha.com/input?i=+lead+cube+with+side+le...
So something might be off with your assumption of 1500 usd / kg.
I can't decide if I'm joking or not.
(Though likely not of course ;)
But would using redundant systems separated in space connected with each other not offset the chance that they all would be affected at the same time? This is actually not rocket science .. just hard engineering and hardware/software design for redundant systems which is also usable on the ground.
"Hollman also found that creativity got him a long way. He discovered, for example, that changing the seals on some readily available car wash valves made them good enough to be used with rocket fuel."
"Elon Musk" by Vance pg 123
I doubt any Lowes parts made it to space, but you know some went into test articles
Perhaps the key is to be relentless, and resourceful.
The Fukushima and Deepwater Horizon disasters show that this knowledge has not penetrated other industries.
But it turns out, it doesn't matter how many redundant backup diesel generators you've got if a 45-foot wave comes along and they're all left underwater.
the orbital and planetary mechanics kind of suck. They're meant to provide a decent 'arcade realism' for the sake of player/player interactions and pvp/pve.
if you want to experience fuel slosh/weight during a vertical ascent/descent go with kerbal. It models a lot of that stuff without mods -- and mods can make the model even more accurate.
Algorithms can be faulty as well.
Which was never claimed.
That paper is a little bit about Erlang and a whole lot about OTP and other methodology and design technique.
It is still, very much "the paper" for distributed systems, though its applicability to this particular problem is limited.
Does anyone know (or have educated speculation on) what kind of hardware is running these algorithms? Like, do they have a linux machine that's running the control loops? Are we talking megabytes, gigabytes of SRAM?
I would think no -- you would definitely need hard real time for something like this. But my only experience with real time systems is in tiny MCUs with kb of SRAM. That's definitely too small for a controller like this.
Really curious about the nuts and bolts of this.
When you build something like this, you're torn between having a big model that represents everything and a smaller model that is easier to validate and reason about. Based on simulation, you might go for a smaller model that "knows" to stay away from operating areas where hidden variables (like really complicated tank slosh) invalidate the small model.
I doubt the actual control loop is too much processing, but it's certainly possible to build controllers with SDRAM, millions of variables of state, and hard realtime processing, though I wouldn't build it on top of preempt-rt. ;)
>probably involve some kind of fast numerical fluid simulation
https://ntrs.nasa.gov/api/citations/19700023342/downloads/19... (search for "slosh" or "shaping network")
My stepfather worked as a programmer on the Apollo program, and the thing he always talked about as his biggest accomplishment was working on the "slosh problem" -- so yeah, props to the SpaceX team for managing that landing. And props to my stepdad for managing it on hardware that was... a billion times less capable? :-)
I am curious but clueless about these problems, can you expand more?
Well, that makes perfect sense considering that both the spaceport infrastructure, and the booster need to do their calculation on the ground level instead of the highly radiated environment that is space. However, for the rockets themselves, which happen to reach that harsh environment, they may use more resilient and expensive hardware in the future, after passing over the current "let it splash in the Indian Ocean" development and testing phases.
Surely this isn't necessary with a small enough sensor granularity or whatever the terminology is. You can have very dumb software if it reacts quickly enough to changes in perception.
Instead, it's more common to use gasses injected at the top of the tank to push the liquid to the bottom. Falcon 9 uses helium. Starship uses https://en.wikipedia.org/wiki/Autogenous_pressurization as well as small header tanks for the landing propellants.
does anyone have any literature about how the Rocket localized itself with respect to the chopstick arms? It must've been some combination of GPS and Radar pings to the arms?
And then the onboard IMU to make sure it hits it straight.
To speculate more, they could also be using something like ultra-wide band positioning. This relies on the same time-of-flight principle as GPS but instead of using satellites in orbit to provide the precise time information you rely on various nearby ground stations. Would only be useful right at the final approach, the last couple hundred meters, but it's another way they could get very very precise position information. (fun fact: Ultra Wide band positioning is also how iPhones can locate AirTags with centimeter accuracy)
In the wide open sky, I’m guessing it’s pretty reliable.
Vision systems would be pretty useless with the low visibility of the smoke and fire. So I thought maybe it was some kind of radar configuration.
Anyways, I’d pay a lot of money to pick the brain of the GNC team here.
Fuel is the vast majority of the vehicle weight at launch, kind of like an empty vs full can of soda.
They ignite a subset of engines just a few seconds before landing for the final slowdown and maneuvering.
Edit: here is a video from further away that shows the rocket gliding in under control of the grid fins before the engines light and execute the final landing maneuver:
They sure made it look easy...
Surprising to see this work first time though - I don't recall them doing any hover and lateral movement tests, but I assume they must have done.
What's also wild is that the booster isn't being caught/supported by those giant grid fins, but rather by small lifting pins just below them, and seems to only have two of these (one on either side), so it also has to get it's rotational position right so those pins engage with (are supported by) the arms.
Watching the video, it looked like the bottom of the rocket was glowing hot, but the engines were cool. I imagine that means they were probably running some amount of methane through the engine bells to cool them.
Also I don't think the telemetry on the feed is that accurate, so with all of the atmospheric braking, it was probably going a bit slower than the 1200km/h at engine reignition.
Going by the telemetry of the seconds before the landing burn and noting the speed vs time, it seems drag was around 40 m/s^2 when it was going at around 3000 km/h. Since drag depends on velocity squared though, it had reduced to just above 10 m/s^2 just before the engines lit at 1250 km/h, and so would quickly become negligible once the engines lit.
Going by Wikipedia, the Super Heavy[1] has 3400000 kg of fuel at launch, so 3% of that is about 102000 kg. For the landing burn, it used 13 Raptor v3 engines[2] to scrub speed. Each Raptor flows about 650 kg/s max, so 3% fuel is enough for about 12 seconds for the 13 engines.
The empty mass of the Super Heavy is about 275000 kg, so about 377000 kg before the landing burn with 3% fuel.
Using the sea-level vs vacuum performance of the Raptor v2 engines, one can estimate that each Raptor v3 produces about 2.45 NM of force at sea-level. So 13 of them would produce about 31.85 MN of force.
Using Newton's second law, F=ma, this gives an initial deceleration of about 84 m/s^2 and about 104 m/s^2 when empty. If we do a rough spreadsheet integration, we get that a burn of roughly 4 seconds is needed to scrub the speed assuming no other forces.
Now, comparing this with reality, the full 13 engines were lit for a little over 5 seconds.
In my simplified calculations I was assuming full throttle the whole way, which obviously isn't realistic, and I also assumed 3% fuel. So over all I think that's a pretty decent estimation.
[1]: https://en.wikipedia.org/wiki/SpaceX_Super_Heavy#Engines
So, 34M kg of fuel has to be burned (in this booster alone) to facilitate a flight ... and I see that the propellant is CH4 / LOX[1].
Burning methane is much, much better than simply releasing methane but the release becomes CO2 instead ...
What is the back-of-the-envelope conversion of 34M kg CH4 vs., for instance, 34M kg of kerosene/JP ?
[1] https://en.wikipedia.org/wiki/SpaceX_Super_Heavy#Engines
[1] https://www.engineeringtoolbox.com/co2-emission-fuels-d_1085... [2] https://x.com/elonmusk/status/1298426245991063554?lang=en
IIRC there's a tradeoff between efficiency and thrust as well. Heavier fuels aren't quite as energy-efficient, but it's easier for them to develop a lot of thrust, which is important for the initial stages of launch. If I'm remembering events described in Ignition! correctly this led to "thrust density" being something that was optimized for - to the point that there were experiments with mixing mercury into the fuel!
[0]: https://world-nuclear.org/information-library/facts-and-figu...
Long ago though so rusty, $dayjob doesn't involve any advanced math at all.
edit: To expand, the "rough spreadsheet integration" was just the Euler method[1] assuming a constant acceleration. So
v(t+dt) = v(t) + a * dt
v(t+dt) = v(t) + F/m(t) * dt
m(t+dt) = m(t) - 650 * dt
Using dt = 0.1 seconds, I got almost exactly 4 seconds until the velocity reached zero.
That should of course be 13 * 650 * dt.
Anyway, plugging in the Raptor V2 thrust numbers the approximation increases to 4.25 seconds. This is in line with the thrust I used for the V3 being ~8% higher than the V2 thrust figures.
Had flashbacks to playing Jupiter Landing on the C64!
https://en.m.wikipedia.org/wiki/Jupiter_Lander
Edit: SpaceX should create a simple 'catch' the rocket game. Play in browser style. Just for kicks and marketing.
there is, it was discussed in the FAA thread.
lunar.unnecessarymodification.com
They did: https://starshipthegame.spacex.com/
The last part of the live stream they showed footage from a different angle and there it didn't look too bad though! For sure controlled.
Scott Manley put out a tweet that they went down towards a non-tower position until they were at three engine controlled burn, and only then did the side shift.
Absolutely impressive accuracy and precision.
Where his vision hit a lot of speed bumps is second stage reusability. Starship is a beautiful second stage to throw in the ocean. They’ll probably get it landing but the heat tiles will require a lot of refurbishment between flights. They’re going to have to figure something else out.
This likely means they are targeting 10 flights in a day at least. They've mentioned 1000 trips to Mars during one transit window, which means ~10000 Earth launches within 3 months, or >100 per day.
"Is there a word for that - something out of fiction becoming mundane?"
Musking?
But I lump both these together as the *"Wiseass Movable Feast"*
Check Steve Brunton youtube channel, he is one of the leaders in this area: https://youtu.be/gb_C9LcjDSI?si=xUjqUZ9-0MIFohX6