SpaceX First Stage Propulsive landing Discussion

[MaverickSawyer]

Perhaps because we're actually in touch with reality?

 

[Urwumpe]

There is no risk what-so-ever associated with trying to soft land the 1st stage. The 2nd stage will already be on it's way to orbit.

Again, the problem is not what happens AFTER the second stage separated. The problem is, that you have to launch with the modification. Even if it is just software, even if it is just software that should not be active... the first Ariane 5 flight also failed just because of software, that should not be active.

 

[garyw]

the first Ariane 5 flight also failed just because of software, that should not be active.

No, that's incorrect. The software it was using was the wrong software.

Based on the extensive documentation and data on the Ariane 501 failure made available to the Board, the following chain of events, their inter-relations and causes have been established, starting with the destruction of the launcher and tracing back in time towards the primary cause.

• The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher.
• This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine.
• These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data.
• The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception.
• The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds period) for the same reason as SRI 2.
• The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.
• The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.
• The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5.
• The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time.
• The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values.

You do know that the shuttle needed a few software changes for each launch to cater for various payloads?

 

[Hlynkacg]

Again, the problem is not what happens AFTER the second stage separated. The problem is, that you have to launch with the modification. Even if it is just software, even if it is just software that should not be active... the first Ariane 5 flight also failed just because of software, that should not be active.

That is a fallacious argument.

If everything must be flown before it is allowed to be flown how does one ever fly anything new?

From my end your argument appears to be space flight is risky and thus requires prior testing. Testing is risky therefore our tests require prior testing. Testing for the tests is risky therefore...

Tell me, just how far down do the turtles go?

 

[Urwumpe]

No, that's incorrect. The software it was using was the wrong software.

No, it was the right software, read the summary again. The Ada program was taken from the Ariane 4 without documenting the constraints and limitations of it, and was not tested with the correct trajectory. All simple errors in the development, but fatal.

The software module that caused the problem was only required prelaunch. But it was kept activated during flight, because it permitted the Ariane 4 a quick realignment of the INS, should it be required in emergency. But this function was also not needed on the Ariane 5 because of the different prelaunch sequence.

But when the function failed while just lurking in the background of the computer, it caused the equivalent of a BSOD. Both computers of the INS failed and started transmitting diagnostic data.

Because of another stupid design error, the main computer of the Ariane 5 treated this diagnostic data as valid navigation data and tried to steer the rocket according to it. Which was a disaster.

You do know that the shuttle needed a few software changes for each launch to cater for various payloads?

Yes, but there are different levels of software changes. The Shuttle had seen actually quite many software changes, but they also had a very strict and rather slow change management.

It is a difference, if you just add a new user application in System Management to cater a special payload, or change the GNC software.

Also, the software load of the Shuttle was created new for every launch, because the mission data was compiled into it (Initial load).

But then, there had been procedures and testing standards for every small change, and a lot of paperwork for it. The kind of process and paperwork, that SpaceX tries to avoid.

---------- Post added at 09:20 PM ---------- Previous post was at 09:14 PM ----------

That is a fallacious argument.

If everything must be flown before it is allowed to be flown how does one ever fly anything new?

From my end your argument appears to be space flight is risky and thus requires prior testing. Testing is risky therefore our tests require prior testing. Testing for the tests is risky therefore...

How far down do the turtles go?

That is your argument, not mine. My argument is, that such changes can't be done as piggy-back option late in the development of a new untested rocket. You need to start it soon and inclusive. Or in the development of the next iteration, after the first few regular flights.

And its turtles all the way down to the Elephants.

 

[Hlynkacg]

That is your argument, not mine. My argument is, that such changes can't be done as piggy-back option late in the development of a new untested rocket. You need to start it soon and inclusive. Or in the development of the next iteration, after the first few regular flights.

Please explain the difference then. The above characterization does not appear to gel with the reality.

And its turtles all the way down to the Elephants.

You've also got that backwards, It goes Elephants then Turtle...

 

[Urwumpe]

Please explain the difference then. The above characterization does not appear to gel with the reality.

Difference: Have no late major changes after definition phase vs adding new features late in development. The latter one is responsible for 45% of all project failures.

 

[Hlynkacg]

Difference: Have no late major changes after definition phase vs adding new features late in development. The latter one is responsible for 45% of all project failures.

Where are you getting this whole "major changes late in development" idea?

SpaceX announced their intention to develop a propulsive landing 1st stage booster long before they publicly announced F9 v1.1 and it's probably fair to assume that a good deal of definition and design work occurred before the public announcement.

Which brings us back to my earlier point. So long as the 2nd stage is on it's way, SpaceX has absolutely nothing to loose from playing R/C rocket with the 1st stage. Infact it is exactly the sort of testing that the SpaceX nay-sayers say they need to do more of.

 

[Urwumpe]

Where are you getting this whole "major changes late in development" idea?

By the fact that Musk announced it now - and not already when the Falcon 9 1.1 upgrade was announced. Musk had been announcing the new Merlin engines already months before they actually knew what they are developing.

SpaceX announced their intention to develop a propulsive landing 1st stage booster long before they publicly announced F9 v1.1 and it's probably fair to assume that a good deal of definition and design work occurred before the public announcement.

Announcing and developing are two things. There was never such a feature mentioned at all in the Falcon 9 1.1 plans.

Which brings us back to my earlier point. So long as the 2nd stage is on it's way, SpaceX has absolutely nothing to loose from playing R/C rocket with the 1st stage. Infact it is exactly the sort of testing that the SpaceX nay-sayers say they need to do more of.

Luckily, such an attitude is already punished in Orbiter. But you can of course claim now, that developing Orbiter add-ons is much harder than building a real rocket.

 

[Hlynkacg]

Announcing and developing are two things. There was never such a feature mentioned at all in the Falcon 9 1.1 plans.

Except that SpaceX's plans to develop a propulsive landing first stage, predate the F9 v1.1 so obviously it's something that they were thinking about early in the design process. Obviously if they were planning to land the 1.1 they would have gave it landing gear but you still haven't articulated why using it as test bed is such a bad thing.

Luckily, such an attitude is already punished in Orbiter. But you can of course claim now, that developing Orbiter add-ons is much harder than building a real rocket.

Are you saying that when you develop an addon that you don't plan ahead or leave openings in your code for features that you'd like to add to later versions?

 

[Urwumpe]

Are you saying that when you develop an addon that you don't plan ahead or leave openings in your code for features that you'd like to add to later versions?

If I would do so for all eventualities and options, I would NEVER get done.

 

[Alfastar]

To break in the arguments. We forget that Musk wide PR'd this idea to try a soft-landing on water. If Musk did planned this, but not wide PR'd this idea, then it was totally not really a problem if it was a success or a failure of the soft-landing of the first stage. But, because Musk did wide PR'd this, there are much more pressure to do this idea successful, and that is something what Musk did not good. He caused a unneeded pressure to doing this concept.

 

[Mader Levap]

Logical fallacy ahead. You demand that I proof that something I suggest is not. That is something we should better leave to the moon landing hoaxers and try the opposite: Positive proofs.

I did not claim anything. You are one that claims they did not designed and tested for this maneuver from day one. You claim that they started thinking about it only recently.

You offer no sources, no proof, just speculations and nice made up stories. For example:

(...)At the beginning of the year, they reported to the powers that be, presented their findings. And the powers had been impressed by the recovery test idea and decided to push ahead.(...)

Any evidence they started it at beginning of 2013? Or you will say again "I don't have to prove it"?

To be clear, of course you don't have to prove anything. Just don't expect I will take serioulsy these baseless claims.

By the fact that Musk announced it now

Dont tell me this is your whole argument for "they started it just recently".

 

[Urwumpe]

Dont tell me this is your whole argument for "they started it just recently".

Do you have a better one, aside of: "I strongly believe that SpaceX doesn't do something stupid, they would NEVER do that."

 

[Hlynkacg]

Do you have a better one, aside of: "I strongly believe that SpaceX doesn't do something stupid, they would NEVER do that."

It's only stupid if they haven't been planning to do something along these lines since development of the F9 1.1 began. There is a substantial amount of circumstantial evidence that they have.

So please explain why it is stupid.

 

[garyw]

SpaceX HAVE been planing first stage recovery since DAY ONE.

This isn't a new idea for them. Since SpaceX's very beginnings, they have talked about recovering and reusing at least the first stages of their rockets. What's been conspicuously lacking is any visible progress toward that. Now this might change.

Source: http://www.newscientist.com/blogs/shortsharpscience/2011/09/falcon-rockets-to-land-on-thei.html

Dated? September 2011

So if they had been planing it way back then and at that point, as per the article, had been planing it for sometime this cannot be called a new idea.

 

[Cosmic Penguin]

IMHO whether such a test is "stupid" or not depends on how the test procedures is integrated into the normal rocket operations - and this one definitely ranks as a higher risk one. However I don't think anyone here has enough insight into the process to make an independent analysis on its chances of affecting the normal launch operations.

What Dennis is trying to point out is that for a machine in a new configuration, even small errors in assumptions on using systems from other existing machines can led to disastrous results, and even more so if such changes are added late in the design process. (examples are abound, even in the aerospace industry) I am not sure if F9-RC1 () is designed with the first stage doing such a maneuver in the first place, but keep in mind that SpaceX tried some other recovery method during the F1 and F9-Beta1.0 days, and the v1.1 has been under development for some time already, so there is a chance that such a feature has been added somewhere downstream of freezing the design. And I am not so sure that SpaceX has enough engineers doing all the analysis on the effect of such an addition on the prime mission - so probably this is done with an understanding from the customer that the flight may carry some kind of additional risk. (although I am not so sure about that either - it was reported that someone in charge of the future launch of a NASA satellite (Jason-3) wasn't happy with being forced to switch the launcher to the v1.1 after the launch contract was signed with the v1.0 being explicitly mentioned as the satellite transport)

But I don't think we have enough data to claim if SpaceX is being "stupid" or not here. However Dennis' point that SpaceX engineers can cause SNAFU is valid - they have several such cases before, and no organization is perfect - especially in spaceflight, where margins are hairy thin.

 

[Cosmic Penguin]

SpaceX HAVE been planing first stage recovery since DAY ONE.



Source: http://www.newscientist.com/blogs/shortsharpscience/2011/09/falcon-rockets-to-land-on-thei.html

Dated? September 2011

So if they had been planing it way back then and at that point, as per the article, had been planing it for sometime this cannot be called a new idea.

Not with the boost back though. (back in the Falcon 1 and the first few Falcon 9 days it was envisioned as simply dumping the first stage down-range with parachutes and recovery done at sea) Unfortunately it is difficult to see if v1.1 is designed right from the start with boost-back in mind, since its lineage from earlier F9 evolution options (like the smaller "Falcon 9 Block II") is extremely unclear.

Wasn't the boost-back optioned only surfaced after the first Falcon 9 flight? :idk:

 

[Hlynkacg]

What Dennis is trying to point out is that for a machine in a new configuration, even small errors in assumptions on using systems from other existing machines can led to disastrous results...

Yes but that doesn't make it a less silly argument.

If we require hardware to be flown before it is allowed to be flown no new hardware ever gets flown.

Not with the boost back though. (back in the Falcon 1 and the first few Falcon 9 days it was envisioned as simply dumping the first stage down-range with parachutes and recovery done at sea) Unfortunately it is difficult to see if v1.1 is designed right from the start with boost-back in mind, since its lineage from earlier F9 evolution options (like the smaller "Falcon 9 Block II") is extremely unclear.

Wasn't the boost-back optioned only surfaced after the first Falcon 9 flight? :idk:

As I understand it after the first couple of flights telemetry from and the physical condition of the 1st Stage caused them to conclude that a conventional parachute recovery would not be practical. After all, as NASA learned with the shuttle, there's no point making a spacecraft reusable if the recovery and overhaul effort will cost as much as a new spacecraft.

The first permit applications for Grasshopper showed up in September of 2011, so as of that date we know that they had decided to attempt propulsive landing / boost-back of the first stage.

 

[BruceJohnJennerLawso]

SpaceX HAVE been planing first stage recovery since DAY ONE.



Source: http://www.newscientist.com/blogs/shortsharpscience/2011/09/falcon-rockets-to-land-on-thei.html

Dated? September 2011

So if they had been planing it way back then and at that point, as per the article, had been planing it for sometime this cannot be called a new idea.

Yes, that is correct. If the grasshopper idea is news to anyone, they probably havent been paying attention to SpaceX news.

If we could actually talk about the design itself for a minute, I get the impression that the plan is for an all-propulsive hover landing. Wouldnt it be easier to float 90% of the way down on a parachute before doing that? Maybe a parafoil could be used if more control were necessary.