Nothing could have prepared me for how that catch looked. I was sure the rocket was careening into the tower at the last second before it straightened out. The control algorithms must be incredible for the landing system to work within those small tolerances.
MIMO and nonlinear control theories are probably some of the hardest topics in all of engineering. SpaceX control system also has to compensate for the fuel moving inside their rockets so the control algorithms probably involve some kind of fast numerical fluid simulation.
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.
> control system also has to compensate for the fuel moving inside their rockets
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 might be misremembering but I think slosh was the failure cause for one of the three failed Falcon 1 flights. It was number 11 out of a pre-flight list of top 10 most likely failure scenarios. Definitely a difficult problem.
> 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.
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".
One downside of using non-rad hard parts is degradation from TID (gamma) and latch up effects. You can have chips monitoring other chips to reset whenever they latch up but TID is mostly permanent. The good thing is that TID in LEO, where SpaceX mostly operates, is relatively lower than GEO so they can get by with mostly commercial parts. It's not like the big defense contractors haven't figured out the same thing, they do fly stuff using commercial parts as well, they are just slower to adopt the same culture. SpaceX and the companies that built components using commercial parts are building the new-space industry.
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.
High energy gammas have a relatively low cross section, most are going to pass right through the chip. If you add a too little shielding, or don’t layer shielding appropriately you are going to stop more gammas but produce lower energy x-rays from the shielding, which have a higher cross section, potentially increasing your chip dose.
Would it be possible to create a "skip" EM shield that does the opposite - increasing the energy of the gamma rays thereby reducing the likelihood of stopping them?
No idea how. Energies of most chemical bonds / electrons around atoms are not very high, not sufficient to emit proper gamma rays AFAICT. High-energy gamma rays are produced in nuclear reactions. While "clean" nuclear reactions that emit only gamma rays and not neutrons do exist, they are very high-energy and thus hard to initiate, and I don't think it would be easy to capture the energy of incoming gamma efficiently enough.
No, that's correct. Of course there's still some level of reduction beyond which the gamma rays don't matter, but where you want to place it is somewhat arbitrary.
A box with 1.3’ walls seems doable, actually, depending on how small the chips are. Might still be cheaper and more effective than specialized chips. But I know nothing, so am probably wrong.
Hah, beat me to the nerd snipe. Moreover, that sphere would cost $10k to make and, at a launch price of $1500/kg, cost $4.5 million to launch into orbit.
The aim for the launch price of the entire rocket is to be around 5 million (once it's fully re-usable and in production). Basically the price of fuel and maintenance.
So something might be off with your assumption of 1500 usd / kg.
Yes, it's based in the real world. This was the Falcon 9 launch price that I could come up with in the amount of time I was willing to spend on a shitpost. I agree that launch prices will continue to come down, but launchers will always be mass-constrained and launching lead spheres into orbit will never be a practical solution.
IIRC the CPUs are much less susceptible to damage when powered-off ? So have a bunch of them in cold standby or even as additional pluggable modules on missions with humans on board & swap to good ones when needed? :)
If the only thing that effectively shields these processors from radiation is lead, concrete etc (per earlier comments), what design changes / quality improvements can compensate?
You don't need to block gamma radiation completely to increase the electronics reliability :)
Maybe you could improve the system availability considerably by a bit of gamma radiation protection combined with some more parallelism of the components ..
The point is that shielding turns a single high energy particle that would otherwise strike and probably destroy a single transistor, into a veritable spray of lower energy particles causing bit flips or worse all over the circuit. This spray of particles can be stopped... with 1.3 feet of lead shielding.
"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."
I have seen some people who decide to keep moving forward with whatever they have at the time. Sure what they produce is way less than perfect, but what they produce is way ahead of what everybody else is doing.
Perhaps the key is to be relentless, and resourceful.
Considering the political views of Elon Musk, it might be worth noting that his biographer is not the same Vance who is currently running for election as vice-president of the USA!
From an article for this I remember one more interesting side effects of this approach - the flight computer ends up as a generic x86/ARM board that the engineers can just have on their desk during development. Previously the dev boards would use the same rad hard chips and would be as expensive and scarse as flight hardware, resulting in much harder development & engineers having much less experience with the real hardware.
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.
I always thought the liquid sloshing would be one of the hardest to simulate (considering how chaotic fluid mechanics is). Interestingly, I think this caused the 2nd Falcon launch to fail (the LOX sloshing).
It is difficult, but there are modeling approaches that work, such as VoF (https://en.wikipedia.org/wiki/Volume_of_fluid_method). Basically, in addition to velocity, pressure, temperature, etc., you store an additional scalar in each cell of your computational mesh representing the liquid's volume fraction. Then, you solve an additional equation to transport that scalar.
Solving the Navier-Stokes equations numerically in 3D is very time-consuming, even on HPC clusters, not to mention the additional modeling required for multiphase flows. Your answer implies that the solutions are obtained almost instantaneously, which is not the case.
I think the reason these kind of simulations are fast enough is because they are very coarse and approximate. Don't think of asking how exactly the foam swirls around the individual longerons, more like a very rough estimation of which side of the tank the liquid is slumped to. Remember it doesn't have to be "exact" just close enough to be useful.
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.
Maybe they don't need to model the fluid dynamics, they just need to detect the mass movement / acceleration forces caused by it, and use those sensor inputs to inform a picture that's fed into their correction thursting.
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 :)
Still if there indeed is "free" mass moving about, you need to make sure your control inputs don't make it slosh harder, so you compensate for that, so it sloshes even harder, etc - basically avoiding oscilation. :)
Oh no, apologies if that was the impression I gave!! I actually perform CFD simulations in HPC clusters, and in fact I'm an admin of the small cluster at my research institute =)
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
It really depends on the problem to be solved (domain size, complexity of physical phenomena such as turbulence model, heat transfer, acoustics, multiphase flows, combustion, etc., number of time steps required...). In our case we perform for instance simulations of turbomachinery acoustics that can take 3-4 weeks running in a few hundreds of CPU cores, combustion acoustics simulations that can take a week or two running in 1k-2k cores...
They don't need to solve the Navier-Stokes equations, they don't care how the fluid is actually behaving, they just need to approximate how the mass is moving within a margin of error that the control system can handle.
Maybe the tank is just not a large hollow structure but contains fins/compartments/whatever to restrict the sloshing motion and it's not that big a contribution to the overall motion.
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.
I remember a very similar anecdote about Von Braun & the early Juno/Jupiter rockets - with someone pointing out issues with sloshing on a press conference & Von Braun brushing it off as insignificant.
Then the next launch crashed due to slosh induced oscillation - and the one rocket after that had anti-slosh baffles. ;-)
At least for the retro-propulsive landing burn, I think the modeling problem is probably aided by the high G-forces that must keep the fuel very close to the bottom of the tank. Even before re-light the booster is falling near terminal velocity (I think?), so the fuel is likely sitting at the bottom.
I think it's a huge problem when re-lighting the engines in orbit, though.
Also IIRC the massive main tanks in Super Heavy should be basically empty at landing & the landings propelants come from a set of small header tabks that are near the central axis of the vehicle & arr completely full. This should reduce or even fully remove sloshing issues at landing time.
I think some Kerbel Space Program players have attempted to approximate the liquid sloshing as an inverted single or double pendulum problem inside the rocket that the control algorithm has to take into consideration in addition to the primary control of the rocket.
Has it been considered to spin the fuel via some centrifuge mechanism as a way to remove sloshing from the equation, or is that more complex/expensive/error-prone than just predicting it via simulation?
I'm thinking we will eventually end up with "active fuel management" techniques like this for in space vehicles.
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. :)
Interestingly cheap redundancy is also how life does things for the most part. Most biological organisms just replicate a lot to guarantee success, so it's clearly a good strategy and an efficient use of energy.
People don't realize how powerful applied math (especially in the areas you've mentioned) has become. Same tools can be applied to people in the ad tech/social media.
Just as a note, Space Engineers has a mod that accounts for fuel in the tanks and also various orbital mods. If one feels inclined to try it for themselves ;)
as someone who absolutely loves SE -- please don't.
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.
I know MPC takes a LOT of compute power. It's not like a finely tuned PID loop or even a cascade of PID loops, computationally.
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.
MPC doesn't need to take a ton of compute power. It all comes down to how sophisticated the underlying model is. You can have a MPC with 20 variables and run it at multiple kilohertz on a tiny microcontroller.
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. ;)
"instead of using $100,000+ radiation-hardened aerospace/defense grade chips"
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.
Less than 5% of a full load. Any extra fuel you brought to the edge of space and back is lost performance, so substantial efforts are made to minimize this lost mass fraction.
>probably involve some kind of fast numerical fluid simulation
Sometimes even a simple approach can work. On Apollo they developed (at the time cutting-edge) passive RC filter networks, to avoid the control system "exciting" the rocket at frequencies of the slosh/bend/torsion modes.
I never thought of using fluid dynamics in the rocket stabilization algorithm—maybe it's something that could be useful to prevent many of the accidents involving liquid-transport trucks
I have been told by people who worked on them that you get radiation hardened aerospace/defence grade chips by backing off the clock speed about 20% to give signal stabilization slightly longer time. I can understand the population being confused about this but industry being confused seems to have more to do with regulatory capture and beaurocratic moats which SpaceX does seem to be bypassing.
You also have to add massive amounts (relatively) of static sink by approaches like ‘silicon on insulator’ to prevent energetic electrons from hopping into the transistor layer.
> SpaceX control system also has to compensate for the fuel moving inside their rockets so the control algorithms probably involve some kind of fast numerical fluid simulation.
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.
(Not an engineer either) My understanding is that it's been done before on smaller scales but having a giant piston in the tank requires a good seal, railings to keep it straight, and overall way too much mass and rigidity. Consider that the tank walls are only a few millimeters thick.
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.
That's amazing footage, and you're right about the perspective: from the official feed the distances seem compressed compared to what we see in this footage.
I certainly can explain it, I'm just not sure I can do it in a way that you could understand. If you yell me what's one of the greatest things you have seen and why, I might be able to better relate.
I know the control algorithms are the mind-blowing part here but,
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.
Great question! Could just be Real-Time Kinematic (RTK) GPS like someone mentioned. Essentially the landing arms know their position very precisely and they measure the tiny errors in GPS data, and send that correction data live to the rocket in real-time as it's landing. Once the rocket gets very very close it could also just be using vision systems to zero-in on exactly where the chopsticks are.
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)
Why bother with GPS or other "absolute" coordinate systems? Once the rocket's in close, all that matters is relative position and orientation of the rocket with respect to the landing apparatus. Eg, if you had many sensors in known locations on the rocket and many sensors in known locations on the landing apparatus, and you could measure relative positions between all pairs of these sensors, you could get extremely precise relative position/orientation information without beaming information to satellites or whatever.
From the control point of view, isn't this exactly the same as F9 landing on a pad, except the pad is virtual, floating in between the chopsticks and the ground? Or course one difference is that the approach needs to be from the correct direction.
I seems to remember some article mentioning the Falcon 9 using radar (+ presumably other sensors) & even having a landing site map uploaded (mainly for the return to launch site scenarios) with prioritized exclusion zones in case of a landing failure.
A major difference is that F9 (landing on a wide flat pad) had a quite wide acceptable horizontal error, 10 meters or more, whereas I think this (landing between two chopsticks) needs like ~1 meter accuracy in the radial direction.
The booster was falling at 4500 Km/h 30 seconds before the catch with 2-3% fuel left. How is that amount of fuel remotely enough to stop the downward momentum?
First off, the booster was going about 1250 km/h when it started its landing burn, it relied purely on drag to get it slowed down to that speed.
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.
Methane has 28% more energy per kg than kerosene and also produces slightly less CO2 (2.75kg CO2/kg burned vs 3.00 for kerosene) when burned [1]. SpaceX uses a 78:22 LOX to CH4 ratio, so for 34M kg of fuel burned, 20.57M kg of CO2 are produced (34×0.22×2.75).
Somewhat tangential, but as far as rocket fuels go energy per volume is also an important metric to consider. It's one of the (several) reasons hydrogen isn't quite as good for rockets in practice as it is in theory - while hydrogen has tons of energy per unit mass (120-142 MJ/kg for hydrogen vs. 50-55 MJ/kg for methane and 43.1-46.2 MJ/kg), it has a far lower density (70.85 kg/m3 vs. 422.8 kg/m3 for liquid methane and 820 kg/m3 for kerosene). As a result, you need quite a bit more tankage for a given amount of energy from hydrogen compared to what methane/kerosene requires.
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!
That's excellent work, only nit is I think these were not the v3 raptors. I think they're just now starting production of those, so they still have a bunch of earlier ones they need to use up in these early test flights. This actually makes your calculation more accurate, as earlier versions will need a slightly longer burn time.
Ah, good catch, I must have misread the Wikipedia page. I misread that they were included in the rocket in August. Reading the Raptor page more closely I also see that the 2.75 MN of the Raptor V3 are supposed to be at sea-level.
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.
Just a programmer, though been interested in physics since I was a teen and did take a bachelor degree in simulation (mainly physics).
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
The acceleration comes from F=ma as mentioned, where F is the force of the engines (Newtons), m is the mass of the rocket (kg) and a is the acceleration (m/s^2). Solving for a we get a = F/m and we get
v(t+dt) = v(t) + F/m(t) * dt
To make things easy I assumed the weight of the rocket was constant at each timestep, but if we take dt to be small enough it's a decent enough approximation. For each timestep I also updated the mass using the estimated mass flow:
m(t+dt) = m(t) - 650 * dt
I started with m(0) = 377000 kg, v(0) = 1250 km/h = 347 m/s, and a constant -31850000 N force from the engines.
Using dt = 0.1 seconds, I got almost exactly 4 seconds until the velocity reached zero.
Newton's laws of mechanics are high-school physics IIRC; my son studied them at 8th grade or so. They are really simple; an evening with Wikipedia or 3blue1brown or whatever floats your boat will let you get sufficient understanding, provided you're also comfortable with high-school math.
The atmosphere does its bit to slow down the booster as well. It’d be interesting to see a plot of the power output over time on reentry but I’ve always assumed the motors aren’t doing a lot of work other than keeping the booster stable, until the very end.
Yes, for most of the booster return it’s ‘gliding’ with the rocket engines completely shut down.
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:
> Yes, for most of the booster return it’s ‘gliding’ with the rocket engines completely shut down.
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.
Super heavy probably makes certain aspects (unrelated to the tower catching the booster) of landing much easier, by virtue of its greater mass. Timing with the Falcon 9 was always essential, because the minimum thrust (with one motor, throttled all the way back) of one of the engines was enough that if you left the motor running, the booster would start to rise. Time the beginning of the final burn incorrectly and you had a real problem, with the booster either crashing or rising at the end and... then crashing, but with Super Heavy, it might simply be a matter of having to compute a slightly different sequence for shutting off the engines.
Super Heavy is easier to control on landing because it's using 3 engines so has better directional control, and it can throttle those engines down into a sustained hover, which is what it does before being "caught" by the arms.
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.
Yeah, but even without fuel the booster weighs 200 tons. It's pretty wild to have 200 tons of steel incoming at supersonic speed, then nailing a gentle pinpoint landing like that !
Yeah if the engines didn’t light and it hit the launch facility that whole place would be a crater. The whole thing was shocking to me but how fast it was coming down was extra shocking haha. I wonder what deceleration forces were at play because when the engines lit the booster slowed down very fast.
It weighs about 10% of what it did at liftoff, but half of the engines fire to slow it down.
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.
Note that the energy of 3% of the propellant (~100 GJ) could theoretically get the empty booster (100,000 kg) to a little over 5000 km/h if properly applied.
Very cool :) I got a good enough score in the basic scenario by playing around a bit but it would be cool if you could link some kind of tutorial (e.g. to a digital PID video or something like that).
I thought the same, screamed out "ouch that doesn't look good!" right before the catch.
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.
A clip from some news program popped up on YouTube, just a two minutes clip of the catch, I was convinced that it was reversed. The fact that this is possible, that they made it work is nothing short of amazing.
When Musk first proposed this, I thought he was crazy. It seemed like something a school boy would draw up. Now I think this will become routine and forgettable after a few more successes. Is there a word for that - something out of fiction becoming mundane?
I thought it was plausible given the accuracy of F9 landings, though I still wonder how it will work at scale if one failure destroys the landing site. That could ruin the cost benefits.
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.
It took months to more than a year to repair shuttle’s heatshield in some cases. SpaceX replaced the entirety of the heatshield with a new design and a new ablative underlayment in a matter of weeks. I suspect they will be able to do it even quicker with design and process improvements. Small scale repairs of the heatshield between flights probably wont be all that big of a deal.
The fact that Starship is unmanned probably helps expedite the change process quite a bit vs. the manned Space Shuttle. If you want to "just try something" the most you can lose is money, and not create a national political scandal.
I think the problem with shuttle was more fundamental. most of the tiles for Shuttle were custom cut to fit exactly one spot on one orbiter. I've read that NASA replaced about 75 tiles per mission, and that 2/3rds of the cost of refurbishing a shuttle after flight was the TPS. so the cost of trying something out was massive.
I really don’t think it will ruin the cost benefit as much as you suggest, especially when they have multiple sites and multiple locations. It wound be catastrophic, but they are presumably building Tower like the rest of their hardware, and every time they launch it represents a $100M saving compared to the competition.
I'm expecting that SpaceX will have lots of towers, not just one (currently) or 3 or 4 (under way). It won't just be for redundancy. The duty cycle of a tower might simply not allow for the cadence that SpaceX wants to maintain. With Falcon 9 they currently have a 3x weekly launch cadence (which is unbelievable enough). With full reusability they might be able to get to daily and better cadence, so if the duty cycle of one tower does not support that (I assume right now it does not) then they'll need more towers.
A flight to Mars is currently going to require 10 tanker flights just to get enough fuel into orbit for 1 Starship trip. Containing liquid fuel for long in orbit will not be easy.
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.
2 related expressions:
1. Creeping Determinism - the idea that even magical leaps forward were somehow inevitable and were anticipated.
2. Nihil Admirari - the idea that wisdom is anticipating every possible thing that could happen, therefore a wise person would never be surprised.
But I lump both these together as the *"Wiseass Movable Feast"*
This happened with LLMs in a big way. Basically humanity surpassed some kind of AI milestone and we zoomed past the turing test in a big way. But thanks to social media everyone is sort of rolling their eyes at it.
Yes, indeed. But I will add that the sheer size of the rocket helps in this regard. I think it is rather hard to appreciate the massive scale of the feat by watching videos.
If I had to bet, I would bet against it. Boston Dynamics for example, for the longest time, didn't use anything other than Model-Predictive Control. Only recently have they started using RL
