Why not four pairs of SuperDracos in the F9 S1 interstage?

[LouScheffer]

1.  The operational envelope of first-stage reuse is at least sometimes limited by winds at the landing pad.

2.  Launch windows which require eg synodic or Lunar period phasing or a rare rendezvous, launch windows which are not just tightly bound to a few seconds, but *sparse*, with long periods between them, mean you don't have much flexibility in when the launch occurs (or what the weather is at the landing pad).  If F9R's first stage becomes frequently reused, this minority of missions which have a go on launch but do not meet conditions for landing, become the limiting factor for first stage lifetime.

1.  Same winds would also prevent launch

2.  not true see #1

My first thought was that the reply to (1) can't be known yet.  Surely the operational envelope for landing, with one engine at partial thrust and empty tanks, will differ from launch, with full tanks and the control authority of 9 engines at full thrust.   But considering there has not yet been even one successful landing, any talk of an operation envelope, much less claiming that any winds that prevent landing will prevent launch, seems very premature.

But before I posted, I looked to see if anyone had already made this point.  I found it, just two posts earlier:

because it expands the operational envelope of first stage reuse, something that exponentially increases the lifespan of a first stage in SpaceX's fleet given a fraction of missions targetting specific orbital windows.

It does nothing of the sort. 
1.  First, you don't know what is limiting the operational envelope, much less knowing the life span and what increases it.
2.  Don't know what orbital windows are much less what they have to do with launch vehicle reuse.  If you mean launch windows, they too have no effect on stage reuse.

[llanitedave]

Musk said 50% more hydraulic fluid is all they need to nail the landing.  Why should we doubt that?

I'm more of a believe it when I see it type of chap. Not that I don't believe they can do it - I'm sure they can, but until they have actually successfully landed it on the barge it seems foolish to say it's a foregone conclusion as some are doing here.

Since no-one here knows exactly what happened on the water landings or the attempted barge landing, I'm going to wait before cracking the champagne. But I really do expect them to do it. They've had three tests so far. That is not a huge amount, but the progress has been rapid and impressive. Fingers crossed for the next one!

Not believing until you see it is not really consistent with inventing all kinds of wild schemes of extra gear and methods to add to the first stage just because you haven't seen the simple stuff work yet.

Even if I'm skeptical about the simple, straightforward solution (which I'm not, considering the results gained so far in limited practice), that's only a reason to be far more skeptical about hare-brained schemes that involve rebuilding the whole rocket.

[Jim]

My first thought was that the reply to (1) can't be known yet.  Surely the operational envelope for landing, with one engine at partial thrust and empty tanks, will differ from launch, with full tanks and the control authority of 9 engines at full thrust.   But considering there has not yet been even one successful landing, any talk of an operation envelope, much less claiming that any winds that prevent landing will prevent launch, seems very premature.

Should have used the word could instead of would.  ;-)

The presence of the erector and the low speed of the vehicle at liftoff is very constraining as far as ground winds.

[JamesH]

Musk said 50% more hydraulic fluid is all they need to nail the landing.  Why should we doubt that?

I'm more of a believe it when I see it type of chap. Not that I don't believe they can do it - I'm sure they can, but until they have actually successfully landed it on the barge it seems foolish to say it's a foregone conclusion as some are doing here.

Since no-one here knows exactly what happened on the water landings or the attempted barge landing, I'm going to wait before cracking the champagne. But I really do expect them to do it. They've had three tests so far. That is not a huge amount, but the progress has been rapid and impressive. Fingers crossed for the next one!

Not believing until you see it is not really consistent with inventing all kinds of wild schemes of extra gear and methods to add to the first stage just because you haven't seen the simple stuff work yet.

Even if I'm skeptical about the simple, straightforward solution (which I'm not, considering the results gained so far in limited practice), that's only a reason to be far more skeptical about hare-brained schemes that involve rebuilding the whole rocket.

Sorry, but that's cobblers. What is hare brained about having the centre engine have a slightly lower power rating IF it makes landing successfully more likely?  Requires no change to the octoweb,, its basically a version of the Merlin with less power. Since they are constantly striving for MORE power, reducing it (and I am guessing here because I am not a rocket scientist) shouldn't be as difficult to do. They already have experience of a machine with a T2W ratio of the same value (Grashopper etc) so they already have more experience with hovering rockets than hoverslamming ones.

I'm also confused as to why a 'hoverslam' landing is 'simpler' than a  slower approach with a possible (but not essential) hover to line up accurately with the landing pad. If it were simple, why wasn't it used on the moon landings, or by helicopters every day.

But please don't get me wrong, I'm more than happy to see them land in whatever way they see fit. But so far, no one commenting has really given a good reason why the ability to hover doesn't make it easier to land safely. I can certainly see that hovering uses more fuel which might be in short supply, and the need for a lower T2W engine is necessary, which reduces payload. Perhaps these reason a are good enough to make the entire idea a non-starter. I expect so. But not hairbrained.

[cambrianera]

There is only one field where performance is more important than in rocketry, and is racing.
When you say “hovering uses more fuel“ you say the magic words, but forget “much“.
Carrying the fuel needed for hovering your F9R becomes useless, with little or no payload.

[IslandPlaya]

Indeed! Why hover when you can nail it first time!

[mme]

... What is hare brained about having the centre engine have a slightly lower power rating IF it makes landing successfully more likely?  ...

1. Increased complexity (three engine variants instead of two).
2. Lowering the total thrust of a rocket many consider on the under powered side of the spectrum.
3. Please show any evidence that "hovering" would make landing easier for a fully automated flight control system.

... its basically a version of the Merlin with less power. Since they are constantly striving for MORE power, reducing it (and I am guessing here because I am not a rocket scientist) shouldn't be as difficult to do.

They have so much experience increasing the power because they want more power.

I'm also confused as to why a 'hoverslam' landing is 'simpler' than a  slower approach with a possible (but not essential) hover to line up accurately with the landing pad.

All evidence is that with functioning grid fins will always be lined with the landing pad.  If a gust happens high enough to seriously devert the rocket, it can counter that in real-time with the fins and TVC.  If it happens so low that it can't compensate, then it lands a few meters from dead center.  If the gusts are so strong that they could topple the rocket during landing, then the rocket is probably screwed no matter what.

If it were simple, why wasn't it used on the moon landings, or by helicopters every day.

Because a human was controlling the descent and landing while searching for a safe landing spot.  The F9 is being controlled by a computer in real time and targeting a specific GPS coordinate.

The comparison to a helicopter (also being controlled by a human) is a huge stretch, but look up "autorotation landings."

But please don't get me wrong, I'm more than happy to see them land in whatever way they see fit. But so far, no one commenting has really given a good reason why the ability to hover doesn't make it easier to land safely. I can certainly see that hovering uses more fuel which might be in short supply, and the need for a lower T2W engine is necessary, which reduces payload. Perhaps these reason a are good enough to make the entire idea a non-starter. I expect so. But not hairbrained.

And I've seen no evidence that hovering makes the landing any easier for an automated system or that there is any real world situation that it would help.

[llanitedave]

I don't think any of the unmanned probes that have landed on the Moon or other planets ever hovered.

[MarsInMyLifetime]

Mars Science Laboratory (MSL) was delivered by cable to the surface by a descent stage in a station-keeping position, but it had arrived at its final position by that time, and the reason for the hover was not for last-second decision making. The Chang'e 3 lunar lander noticeably hovered for last minute terrain checking and then sideslipped to a smooth location for landing. These were both very specific mission requirements that had the cost of added fuel and sensors, and had nothing to do with recovery. Most other landers have gone straight for the touchdown while doing some safe-zone seeking on the way down, and most have shut off for a short drop to minimize surface disturbance. All in all, these are simply very different requirements from the Spacex goal of using available assets and least resources to put the stage at a predetermined point. I agree with others saying that the ROI of stage recovery from a business point of view requires little else. If you were designing for different requirements, then by all means do what is right for that scenario, being aware of your trade-offs vs benefits as you add features.

[MarsInMyLifetime]

Apart from technical and business rationale, there is also a risk-to-actuarials consideration here. If a craft or its payload is so valuable that it must be saved at any cost, then some of the proposed hover/guidance solutions may be appropriate (much like LAS for Orion or Dragon). On the other hand, if the business plan assumes a certain degree of replacement, then the tolerance for loss goes up, and with that comes the freedom to take more risk with landing solutions. The state of the industry is expendable stages, so this CRS-5 event was hardly any greater a loss than all launches that have gone before. I have no doubt that they'll actually get bigger chunks back home next time, growing their reliability and fleet of slightly-used vehicles with each additional launch.


Also by comparison, we tolerate enormous (value-wise) accident attrition in military air operations (http://en.wikipedia.org/wiki/List_of_accidents_and_incidents_involving_military_aircraft_%282000%E2%80%9309%29), which I view as being in the same odds as Spacex stage retrieval. Let them lose a few; it's the big game that matters.

[JamesH]

Interesting replies above, thanks.

But...and you just knew there would be one....I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer). Getting a rocket to land exactly in the right place in a near vertical descent, from miles up, in random wind conditions is difficult. Getting the vertical component to zero at ground zero is also very difficult when you have an engine that needs to restarted within a 10ths of a second of the right time, with difficult to measure stage weight and a slow engine response. That's two very difficult things to do that must coincide exactly.

If SpaceX succeed, and I think they will, that is an extraordinary feat.  Note that Musk has given the next flight a 60% chance of landing OK. So they are still not sure.

My point about the ability to hover is that it gives more time to get those two components right. Even for a computer, time is important.

Note about autorotation landings for helicopters. Those are used for emergency landing when a normal landing is not possible, therefore not relevant as a counter example. They are also difficult to do and not as accurate as a normal landing.

[ChrisWilson68]

I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer).

I'm a software engineer too, and I think it's going to be no problem for the software to do the hoverslam.  It's the kind of thing that's easy for software.  Once you've correctly modeled the effects of control inputs, assuming you have reasonably accurate sensor data, it's a simple set of calculations to figure out the right control inputs.

[JamesH]

I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer).

I'm a software engineer too, and I think it's going to be no problem for the software to do the hoverslam.  It's the kind of thing that's easy for software.  Once you've correctly modelled the effects of control inputs, assuming you have reasonably accurate sensor data, it's a simple set of calculations to figure out the right control inputs.

But that, in one paragraph, is an awful lot of stuff to get right. Modelling the stage is difficult, getting accurate sensor data is difficult (for example, there has been a lot of discussion that the barge doesn't transmit anything to the stage, but if that is the case, how does the stage know the wind conditions at the barge? Something you really need to know). Add to that the need  for a very reliable engine ignition and control, accurate positioning data (GPSD) and accurate speed data.

It is all very complicated! Solvable? Yes, I think so. Hopefully in the next couple of flights, fingers crossed. But I wouldn't be counting my chickens yet. There a lot of stuff they probably still don't know well enough for reliability.

[Jim]

I'm also confused as to why a 'hoverslam' landing is 'simpler' than a  slower approach with a possible (but not essential) hover to line up accurately with the landing pad. If it were simple, why wasn't it used on the moon landings, or by helicopters every day.

Because there was no air on the moon and it didn't have a cleared area and a flat landing pad

[nadreck]

Interesting replies above, thanks.

But...and you just knew there would be one....I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer). Getting a rocket to land exactly in the right place in a near vertical descent, from miles up, in random wind conditions is difficult. Getting the vertical component to zero at ground zero is also very difficult when you have an engine that needs to restarted within a 10ths of a second of the right time, with difficult to measure stage weight and a slow engine response. That's two very difficult things to do that must coincide exactly.

If SpaceX succeed, and I think they will, that is an extraordinary feat.  Note that Musk has given the next flight a 60% chance of landing OK. So they are still not sure.

My point about the ability to hover is that it gives more time to get those two components right. Even for a computer, time is important.

Note about autorotation landings for helicopters. Those are used for emergency landing when a normal landing is not possible, therefore not relevant as a counter example. They are also difficult to do and not as accurate as a normal landing.

Again, I want to emphasize that the whole idea that a computer controlled landing would benefit from a hover phase only exists because of a bias of the process being similar to how a human would do it.

One thing I noticed in many years of work in IT was that, even within the IT field there was a bias that led to expectations that anything that could be explained succinctly in english could easily be programmed into a computer, and that it was amazingly impressive when something that took hours to explain in english only took minutes for a programmer to do.

I am not saying that the programming for a fast in, > 1.5 T/W ratio descent and landing, is easy programming, but I am saying it is easier programming than building in a hover which still has to do everything the first one did, and then deal with balancing the craft under far more extreme conditions than the "fast in" did.

The landing surface is known accurately enough that a hover and spot picking is not needed, the process to come in and get to the surface quickly is known and works with all the variables operating, the rocket was not 'running on the rails' to a point just above the landing site then re-evaluating how to get down the last 'step', it continuously was adjusting rate of descent, attitude and course within the envelope of the control authority on grid fins, engine gimballing, and possibly cold gas thrusters still. The computer knows exactly the lags in response to its commands to the differing control authorities, a human would never be able to do what the computer does easily in this respect, but the human could probably pick and orient to a landing on a surface it had no knowledge of until 50 meters away quicker and more accurately than the computer (at this time).

[JamesH]

I'm also confused as to why a 'hoverslam' landing is 'simpler' than a  slower approach with a possible (but not essential) hover to line up accurately with the landing pad. If it were simple, why wasn't it used on the moon landings, or by helicopters every day.

Because there was no air on the moon and it didn't have a cleared area and a flat landing pad

I realised the second 2 of these about 10 seconds after I posted...but not sure about the air thing. Clearly that means no grid fins, but it also means no wind/atmosphere to throw you off course. So you should be able to accurately calculate a descent profile from a long way up (presuming a known location and flat landing pad which the moon landings didn't have, but presumably would have if done now). Only thing you might need to worry about is local changes in the gravitational field....I wonder if SpaceX have to take that in to account (not relevant at sea I suspect,  no large masses close enough)

[Jim]

I realised the second 2 of these about 10 seconds after I posted...but not sure about the air thing. Clearly that means no grid fins, but it also means no wind/atmosphere to throw you off course. So you should be able to accurately calculate a descent profile from a long way up (presuming a known location and flat landing pad which the moon landings didn't have, but presumably would have if done now). Only thing you might need to worry about is local changes in the gravitational field....I wonder if SpaceX have to take that in to account (not relevant at sea I suspect,  no large masses close enough)

The air thing means that drag provides some deacceleration, reducing prop needs.
Having no crew onboard means that quick stop at the bottom has no human factors to deal with
Having no crew onboard means you can have a different risk posture and not worrying about risk gates and backup/backout/abort scenarios.

[JamesH]

I realised the second 2 of these about 10 seconds after I posted...but not sure about the air thing. Clearly that means no grid fins, but it also means no wind/atmosphere to throw you off course. So you should be able to accurately calculate a descent profile from a long way up (presuming a known location and flat landing pad which the moon landings didn't have, but presumably would have if done now). Only thing you might need to worry about is local changes in the gravitational field....I wonder if SpaceX have to take that in to account (not relevant at sea I suspect,  no large masses close enough)

The air thing means that drag provides some deacceleration, reducing prop needs.
Having no crew onboard means that quick stop at the bottom has no human factors to deal with
Having no crew onboard means you can have a different risk posture and not worrying about risk gates and backup/backout/abort scenarios.

Thanks!

[llanitedave]

I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer).

I'm a software engineer too, and I think it's going to be no problem for the software to do the hoverslam.  It's the kind of thing that's easy for software.  Once you've correctly modeled the effects of control inputs, assuming you have reasonably accurate sensor data, it's a simple set of calculations to figure out the right control inputs.

OK, which one of you uses Python, and which one of you uses C++?

[ChrisWilson68]

I'm still not seeing the 'hoverslam' is a simpler thing. I can certainly sere it's better for payload, but I think people are giving too much credit to the software running these things (I'm a software engineer).

I'm a software engineer too, and I think it's going to be no problem for the software to do the hoverslam.  It's the kind of thing that's easy for software.  Once you've correctly modeled the effects of control inputs, assuming you have reasonably accurate sensor data, it's a simple set of calculations to figure out the right control inputs.

OK, which one of you uses Python, and which one of you uses C++?

Well, this is probably off-topic and will get deleted, but for what it's worth, I mostly use a general-purpose programming language of my own design.  For work, I used that language to write a compiler for another special-purpose programming language I helped design.  That compiler generates C++.

I used to work in a compiler research group at Stanford.  I have a special interest in programming languages.