https://x.com/deankolson87/status/1880026759133032662?t=HdHF...
https://x.com/realcamtem/status/1880026604472266800
https://x.com/adavenport354/status/1880026262254809115
Moment of the breakup:
https://x.com/deankolson87/status/1880026759133032662?t=HdHF...
https://x.com/realcamtem/status/1880026604472266800
https://x.com/adavenport354/status/1880026262254809115
Moment of the breakup:
Apart from obviously double-checking for leaks, we will add fire suppression to that volume and probably increase vent area. Nothing so far suggests pushing next launch past next month.
In my experience in corporate america you communicate efficiency by proclaiming a checklist of things to do - plausible, but not necessarily accurate things - and then let engineers figure it out.
Nobody cares of the original checklist as long as the problem gets resolved. It's weird but it seems very hard to utter statement "I don't have specific answers but we have very capable engineers, I'm sure they will figure it out". It's always better to say (from the top of your head) "To resolve A, we will do X,Y and Z!". Then when A get's resolved, everyone praises the effort. Then when they query what actually was done it's "well we found out in fact what were amiss were I, J K".
According to this website their current success rate is 99,18%. That's a good number I guess? Considering other companies did not even land their stages for years.
https://spaceinsider.tech/2024/07/31/ula-vs-spacex/#:~:text=....
There's an order of magnitude difference between them. If they were cars, it'd be like comparing the smallest car you can think of vs one of the biggest tanks ever made.
My tests keep failing until I fix all of my code, then we deploy to production. If code fails in production than that's a problem.
We could say that rockets are not code. A test run of a Spaceship surely cost much more than a test run of any software on my laptop but tests are still tests. They are very likely to fail and there are things to learn from their failures.
However if you see the stream you can see one of the tanks rapidly emptied before loss of signal
It seems this was not survivable regardless of fire or not
How would you test a rocket?
Honestly I thought they would be live testing fuel exchange in orbit by now. Seems pretty far from it sadly.
You’ll catch issues along the way, but you can’t catch all of them before a full launch test. That’s why there are launch tests.
What makes these launches “non-production” tests is that they are not carrying any valuable payload. Blowing up rockets like this is exactly what gives the company it’s advantage over competitors who try to anticipate everything during design stages.
19 people have died in the 391 crewed space missions humans have done so far. The risk of dying is very high. Starship is unlikely to change that, although the commoditization of space flight could have reduce the risk simply by making problems easier to spot because there's more flights.
> we had an oxygen/fuel leak
If that's correct, then you can't just remove air. The only option would be to cool things down so it stops burning.
I'd say that only the 7th mission was legitimately a failure, because there was some rerouting of flights outside the exclusion zone. The other six missions were successful tests since nothing other than the rocket itself was affected.
It's true that other rocket companies are treating launches as production, but SpaceX has always been doing "hardware-rich" testing.
They already implemented a whole host of changes to the vehicles after the first test back in 2023. There's a list of corrective actions here.
But that still means it’s not just taxpayer money, it’s mostly theirs. They’ve been raising equity rounds this whole time.
SpaceX also has a simplification streak: the Raptor engines being the canonical example. Lower complexity generally means less unexpected failure modes.
Early aviation was extremely dangerous. Now a plane is among the safest places to be.
Without Spacex, the typical cohort of gov contractors would have been happy bleeding NASA dry with one time use rockets that have 10x the launch cost and carry 1/4 the cargo.
Not necessarily. Your engine which used to have 200 sensors perhaps now only has 8. But you now don't know when temperatures were close to melting point in a specific part of the engine. When something goes wrong, you are less likely to identify the precise cause because you have less data.
Many of those sensors are not to enable the rocket to fly at all, but merely for later data analysis to know if anything was close to failure.
In yesterdays launch, if the engines had more sensors musk probably wouldn't have said "an oxygen/fuel leak", but would have been able to say "Engine #7 had an oxygen leak at the inlet pipe, as shown by the loud whistling noise detected by engine #7's microphone array"
I truly wish more software engineers thought this way. I see a lot of mentality in software where people are even impressed by complexity, like "wow what a complex system!" like it's a good thing. It's not. It's a sign that no effort has been put into understanding the problem domain conceptually, or that no discipline has been followed around reducing the number of systems or restraint over adding new ones.
I've seen incredibly good software engineers join teams and have net negative lines of code contributed for some time.
If we ever encountered, say, an alien race millions of years ahead of us on this kind of technology curve, I think one of the things that would strike us would be the simplicity of their technology. It would be like everything is a direct response and fit to the laws of physics with nothing extraneous. Their software -- assuming they still use computers as we understand them -- would be functional bliss that directly represented the problem domain, with every state a pure function of previous state.
We might get to this kind of software eventually. This is still a young field. Simplicity, being harder than complexity, often takes time and iteration to achieve. Often there's a complexity bloat followed by a shake out, then repeat, over many cycles.
Integration tests are the next where multiple units are combined.
Then there is staging.
That would be like comparing a 1-y.o.'s ability to run to a 10-y.o.'s. Of course the younger kid doesn't yet control their legs, but that doesn't mean it's going to stumble and fall forever.
https://www.reddit.com/r/aviation/comments/1i34dki/starship_...
[0] https://en.wikipedia.org/wiki/Shuttle-Centaur
- "The astronauts considered the Shuttle-Centaur missions to be riskiest Space Shuttle missions yet,[85] referring to Centaur as the "Death Star".[86]"
I love that this is also a model of reality. Everything is made of differential equations.
Real tests do all of this at once with no option to escape reality.
Again, one thing is automating thorough software tests, another one is testing physical stuff.
This is meant to be a human rated ship of course, how will you reduce this danger? I know this stuff is hard, but you can't just iterate and say starship 57 has had 3 flights without leaks, we got it now. Since I have no expertise here, I can imagine all kinds of unlikely workarounds like holding the gas under lower pressure with humans on board or something to reduce the risk.
Also water would make it hotter, given this is liquid oxygen.
Next engine revision (Raptor 3) should help, as it is much simplified and quite less likely to leak or get damaged during flight.
We know nothing, but the test having good data on what went wrong is a great starting point.
This can work. Fundamental structural components of airliners just can’t fail without killing everyone, and high reliability is achieved with careful design, manufacturing, testing, and inspection. I’m not sure if a gigantic non-leaky tank is harder to pull off that way, but they might have to regardless.
We’re going to have to accept that space travel is going to be inherently dangerous for the foreseeable future. Starship is in a good position to improve this, because it should fly frequently (more opportunities to discover and fix problems) and the non-manned variant is very similar to the manned variant (you can discover many problems without killing people). But there are inherent limitations. There’s just not as much capacity for redundancy. The engines have to be clustered so fratricide or common failure modes are going to me more likely. Losing all the engines is guaranteed death on Starship, versus a good chance to survive in an airliner.
All other practical considerations aside, I think this alone sinks any possibility of using Starship for Earth-to-Earth travel as has been proposed by SpaceX.
(b) is true and should make it substantially safer than other launch systems. But given how narrow the margins are for something going wrong (zero ability to land safely with all engines dead, for example) it’s still going to be pretty dangerous compared to more mundane forms of travel.
It is more like an "all or nothing" process.
Falcon 9 has had plenty of "ROI" but it wasn't really federally funded. Let's not get carried away though about "more than the entire US space industry combined," though.
How does Halon works?
For example, if system A has a failure probability of 10%, if A is redundant with another A', the combined failure probability is 1%.
That of course presumes that A and A' are not connected.
And you can have fires where both fuel and oxidiser are solid: thermite reactions.
"Fire point" seems to be more of a factor for conventional fire concerns, albeit I'm judging a phrase I've not heard before by a stub-sized Wikipedia page: https://en.wikipedia.org/wiki/Fire_point
The response to this was to make sure repairs are carried out correctly so the structure doesn’t fail, not to somehow make two redundant bulkheads or two skins.
A future starship could plausibly be the first rocket to fly to space unmanned, return, and then fly humans to space!
The idea is to design the airplane to survive an explosive decompression failure, not pretend that explosive decompression doesn't happen. For example, on the DC-10, the floor collapsed from explosive decompression, jamming the control cables and causing a horrendous crash.
The fix was not preventing explosive decompression. The fix (on the 757) was to locate the redundant set of control cables along the ceiling. Also, blowout panels were put in the floor so the floor wouldn't collapse.
It's not always practical to fix an older design like the 747. When it isn't practical, a stepped-up inspection protocol is added.
P.S. The 747 was designed to survive a decompression. The oversight was nobody realized that a failure of the rear bulkhead could destroy the tail section. Things like that happen in complex systems, and an airliner is incredibly complicated.
P.P.S. When I was a newbie at Boeing, I asked about the wing spar, too. That's how I know it is dual!