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

[whvholst]

Given that the difficulty of landing the F9.1 first stage is that a single Merlin still has a T/W ratio larger than one, even when throttled down to its minimum throttling, how stupid/silly would it be to mount four pairs of SuperDracos on the interstage? A single SuperDraco has a vacuum thrust of 7.4 kN while a 40% throttled Merlin D has a vacuum thrust of about four times that. Which means that four pairs of SuperDracos are comparable to a 80% throttled Merlin D and can together throttled much lower.

Given the amount of tinkering that still appears to be going on with the interstage (grid fins and related hydraulics), how far-fetched is this idea?

[Mongo62]

I would guess that the mass penalty would be prohibitive.

You save the mass of the landing kerolox propellant, but have to add the mass of the hypergolic SuperDraco propellant, which due to lower ISP and cosine losses, might be around 50% greater than the mass of the replaced kerolox.

Plus you have to add the mass of the SuperDracos themselves, the mounting hardware, the tanks for the hypergolic propellant and the connecting valves and piping.

[JasonAW3]

Too bad a Kerolox version of the SuperDraco don't exist.  While there would be a mass penalty, it may be easier to land a legged pendulm rather than a broomstick on a fingertip.

[neoforce]

Given that the difficulty of landing the F9.1 first stage is that a single Merlin still has a T/W ratio larger than one, even when throttled down to its minimum throttling,

It is difficult.  But it is so simple, and the smallest weight penalty.

This is a test program, but with high probability of successful recovery.  Don't jump to conclusion that it can't be done based on the first test.

[Coastal Ron]

Given that the difficulty of landing the F9.1 first stage is that a single Merlin still has a T/W ratio larger than one, even when throttled down to its minimum throttling, how stupid/silly would it be to mount four pairs of SuperDracos on the interstage?

The Falcon 9 1st stage doesn't need to hover, it only needs to time the arrest of it's descent to coincide with the stage meeting the ground.  The challenging part is getting that timing down to when you stop the engine the stage is already on the ground, and not starting to go back up again.

SpaceX has been practicing this with the Grasshopper test vehicle, and has been doing pretty good.  What they are trying to do now is figure out how to do it on a moving platform that could be raising or lowering in elevation fairly rapidly.  But I think it's something that can be solved with software instead of adding more mass to the stage.

Given the amount of tinkering that still appears to be going on with the interstage (grid fins and related hydraulics), how far-fetched is this idea?

The grid fins address the twisting of the stage, and likely add some ability to move the top end of the stage around without having to use the engines on the lower end.  Adding Draco engines likely would not do that, so the stage would still need grid fins regardless what engines you used to arrest the descent velocity of the stage.

You have to trust SpaceX with what they are doing.  They know what they are capable of, and they know what the important factors are.  No doubt they have spent a lot of time debating what the trade-offs are, and what we see today is the result of a lot of experimentation.  And there is more experimentation to come.

[llanitedave]

I would guess that the mass penalty would be prohibitive.

You save the mass of the landing kerolox propellant, but have to add the mass of the hypergolic SuperDraco propellant, which due to lower ISP and cosine losses, might be around 50% greater than the mass of the replaced kerolox.

Plus you have to add the mass of the SuperDracos themselves, the mounting hardware, the tanks for the hypergolic propellant and the connecting valves and piping.

Not to mention the changes to the center of gravity that would entail, with possible added stability and control issues.

[NovaSilisko]

Too bad a Kerolox version of the SuperDraco don't exist.  While there would be a mass penalty, it may be easier to land a legged pendulm rather than a broomstick on a fingertip.

https://en.wikipedia.org/wiki/Pendulum_rocket_fallacy

[Robotbeat]

Given that the difficulty of landing the F9.1 first stage is that a single Merlin still has a T/W ratio larger than one, even when throttled down to its minimum throttling, how stupid/silly would it be to mount four pairs of SuperDracos on the interstage? A single SuperDraco has a vacuum thrust of 7.4 kN while a 40% throttled Merlin D has a vacuum thrust of about four times that. Which means that four pairs of SuperDracos are comparable to a 80% throttled Merlin D and can together throttled much lower.

Given the amount of tinkering that still appears to be going on with the interstage (grid fins and related hydraulics), how far-fetched is this idea?

They aren't having (undue) difficulty; they will achieve success. Fins are way less complicated operationally than a bunch of superdracos would be (unless you need them anyway, like for Dragon).

It's myopic fixation on problems that have already been solved or will be very shortly. Just like when people were all worried about valves all of a sudden after a scrub (on Delta IV then on Falcon 9, though a completely different issue), the problem is already fixed and will soon be forgotten.

EDIT: (On the other hand, your idea has some merit on some future upper stage recovery, where you have difficulty getting the single engine to have anywhere near low enough thrust to land propulsively.)

[Burninate]

I would like to see the SuperDracos available in this capacity specifically to aid in solving all ~12 degrees of freedom that need to be correct for a soft touchdown, amidst a moving reference frame. 3D position, 3D orientation, 3D velocity, 3D rotational velocity all need to be near-zero relative to the landing zone at impact, and long after the grid fins cease to be effective.  Fighting any significant wind from terminal velocity to ship velocity with the main engines essentially requires that some of these variables diverge from zero.  More wind, more problems.  SuperDracos provide extra thrust in the right directions at very high frequency.  This is *far* more useful than merely slowing down the hoverslam descent to lower G-ratings, 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.

Two problems with this, though:
1) While CoM does not have a huge effect during the flight of a pure rocket, contrary to intuition...  it does have a large effect on stability for the duration that the landing legs touch the deck.

2) Nitrogen tetroxide and monomethyl hydrazine.  If the landing requires these in quantity, the landing zone is a HAZMAT zone, and approval for such landings is even harder.  Green hypergolic propellants would be very strongly preferred.

[Jim]

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.
3.  Allocating more first stage propellant for the return is a better trade than adding a completely separate system.
4.  A Draco system complicates reuse by adding more complexity.

And it is not 12 degree as you stated:  roll orientation is not constrained and you forgot acceleration

[Burninate]

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.
3.  Allocating more first stage propellant for the return is a better trade than adding a completely separate system.
4.  A Draco system complicates reuse by adding more complexity.

And it is not 12 degree as you stated:  roll orientation is not constrained and you forgot acceleration

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

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.

Allocating more first-stage propellant does not help with the aerodynamic / thrust controls problem of landing at the pad in a strong wind;  It's not a matter of fuel being scarce, but there not being enough degrees of freedom, and also not enough quantity in the horizontal direction, of thrust.

A Draco system does indeed complicate reuse by adding complexity.

Roll orientation is indeed unconstrained.  Acceleration is not constrained - 'Hoverslam' has substantial acceleration right up to touchdown, and a dynamic solution that requires high acceleration or angular acceleration to very briefly zero out all the things that need to be zeroed out, is just fine.

[Jim]

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.

3.  Allocating more first-stage propellant does not help with the aerodynamic / thrust controls problem of landing at the pad in a strong wind;  It's not a matter of fuel being scarce, but there not being enough degrees of freedom, and also not enough quantity in the horizontal direction, of thrust.

1.  Same winds would also prevent launch

2.  not true see #1

3. wrong.  There are plenty of degrees of freedom.  Extra propellant allows for more time of main engine burn to counter the wind, including in the  horizontal direction

[drzerg]

Thay could make just central engine capable of doing 20%. No need to make all of 9. Or replace one Merlin D with one or two Kestrel. Or add them from each side of the bottom section. Dry weight   52 kilograms, (31 kN). May be additional small turbo pump will be needed.

[Jim]

Thay could make just central engine capable of doing 20%. No need do make all of 9. Or replace one Merlin D with one or two Kestrel. Or add them from each side of the bottom section. Dry weight   52 kilograms, (31 kN). May be additional small turbo pump will be needed.

Replacing an engine is a non starter, especially with Kestrels.  A turbo pump can't just be added.  It has to been integrated into the engine.  A Kestrel is pressure fed.  Adding a turbo pump means it is a completely new engine. 
Adding them to the side is also a non starter, there is no room and would require a major redesign of the thrust section.

[JamesH]

Any mileage in developing a modification of the Merlin that is lower thrust to stick in the centre of the octaweb, giving more ability during the landing process? There seems to be some excess performance of the 9 engines currently, could they take a small hit on one to give them better manoeuvrability?

[llanitedave]

Geez, people, you're driving me crazy here!  Is everyone Rube Goldberg in disguise?

They have a system, it's going to work.  Let them tweak it.

[oiorionsbelt]

Geez, people, you're driving me crazy here!  Is everyone Rube Goldberg in disguise?

They have a system, it's going to work.  Let them tweak it.

Absolutely, they have come up with an elegant solution and everyone seems to want to turn it into a kludge.

[llanitedave]

"Look, if we built this    

[JamesH]

Geez, people, you're driving me crazy here!  Is everyone Rube Goldberg in disguise?

They have a system, it's going to work.  Let them tweak it.

They have a system, it's *probably* going to work. Fixed that for you. Unless you have a crystal ball and already know.

But the question is... is there an advantage of being able to hover the stage (F9 and BFR) to give more time to land accurately? More relevant to BFR since the Rapture is going to be a powerful bit of kit with I suspect a higher T2W ratio than the Merlin.

* I personally think the 'hoverslam' will work. I'm just wondering about hovering advantages.

[cambrianera]

High gee landing has higher efficiency (less gravity losses).
What is needed is:
More experience.
Easier landing place.
(IMHO) A sturdier landing gear.

[speedevil]

But the question is... is there an advantage of being able to hover the stage (F9 and BFR) to give more time to land accurately? More relevant to BFR since the Rapture is going to be a powerful bit of kit with I suspect a higher T2W ratio than the Merlin.

* I personally think the 'hoverslam' will work. I'm just wondering about hovering advantages.

If you're hovering, and have wind-loads, they will tend to push the stage over.
If the wind is from the left, they will tend to tilt the top of the rocket left.
If you keep the thrust through the centre of mass, then you drift left.
You need to then gimbal hard right to kick the stage over so it tilts right, followed by gimballing hard left as it comes to vertical.
During which time you can be hit with another gust from another direction.

I suspect the optimal trajectory is something like ~28s at 40% thrust, and 2s at 90%.

You want to really minimise the amount of hang-time, to avoid getting into back-and-forth battles with potentially gusty winds that you may never be able to win.

Helicopters can do this because they have at the least minutes of time available to land.

[mme]

Geez, people, you're driving me crazy here!  Is everyone Rube Goldberg in disguise?

They have a system, it's going to work.  Let them tweak it.

They have a system, it's *probably* going to work. Fixed that for you. Unless you have a crystal ball and already know.

But the question is... is there an advantage of being able to hover the stage (F9 and BFR) to give more time to land accurately? More relevant to BFR since the Rapture is going to be a powerful bit of kit with I suspect a higher T2W ratio than the Merlin.

* I personally think the 'hoverslam' will work. I'm just wondering about hovering advantages.

No, there is virtually no advantage to hovering.  It wastes fuel, adds weight, adds complexity (and therefore failure modes),  it exposes the rocket to more risk not less.  During the ASDS landing attempt winds were 30 kmh.  How is "hovering" a 14 story building in a 30 kmh wind "safer?"  There is no reason the F9 won't be able to achieve sub-meter accuracy.  Therefore, hovering is a solution looking for a problem.

[nadreck]

First of all, let me say that the comments by speedevil and cambrianera are most of the answer here. But to explain why people keep wanting to analogize to balancing broomsticks or landing things like helicopters, those are all things people can directly or vicariously identify with the difficulties of manually controlling, however slowing, hovering and gently settling on to a surface are methods used because people can't process quickly and methodically like a computer. However, a straight in, fast but accurately controlled landing is much easier for a computer than hovering and stabilizing above the landing surface.

[speedevil]

However, a straight in, fast but accurately controlled landing is much easier for a computer than hovering and stabilizing above the landing surface.

Depending on if you have adequate control authority and target vector flexibility to ignore the gusts.

In principle though even for extreme gusts - 'brute force'' solutions - a thousand tiny quadcopters in rings 50m apart giving 5s warning of winds to allow some feed-forward would help _enormously_.

[hrissan]

Geez, people, you're driving me crazy here!  Is everyone Rube Goldberg in disguise?

They have a system, it's going to work.  Let them tweak it.

They have a system, it's *probably* going to work. Fixed that for you. Unless you have a crystal ball and already know.

But the question is... is there an advantage of being able to hover the stage (F9 and BFR) to give more time to land accurately? More relevant to BFR since the Rapture is going to be a powerful bit of kit with I suspect a higher T2W ratio than the Merlin.

* I personally think the 'hoverslam' will work. I'm just wondering about hovering advantages.

To all posters: do not fix what is not broken...

Take a human walking for example: did you ever stumble upon something? How about third leg for you? May be better crawl instead of walking? Or hire 2 angels to support you whenever you walk? Shorten your legs so you fall from less altitude? Etc...

[nadreck]

However, a straight in, fast but accurately controlled landing is much easier for a computer than hovering and stabilizing above the landing surface.

Depending on if you have adequate control authority and target vector flexibility to ignore the gusts.

In principle though even for extreme gusts - 'brute force'' solutions - a thousand tiny quadcopters in rings 50m apart giving 5s warning of winds to allow some feed-forward would help _enormously_.

But, what I am trying to point out, is that under automated control the slower you go, the harder it is to ignore the  gusts, the less control authority your aerodynamic surfaces have, the more ping ponging you will get with your gimballed engine, etc. with manual control you have no option but to go slow because a human can't do the fast/accurate decelerate to zero at zero in real time. So for a human to control the landing you need far more control authority to make a successful 'soft' landing of any type, for a machine, if only the last 2 seconds of the landing has effectively zero aerodynamic control authority as opposed to a human controlled one where there is maybe 10 or more seconds of that, then the automated landing needs 1/5th or less the control authority because there is 4/5th less possible deviation from when you had aerodynamic control authority.

[speedevil]

But, what I am trying to point out, is that under automated control the slower you go, the harder it is to ignore the  gusts, the less control authority your aerodynamic surfaces have, the more ping ponging you will get with your gimballed engine, etc. with manual control you have no option but to go slow because a human can't do the fast/accurate decelerate to zero at zero in real time. So for a human to control the landing you need far more control authority to make a successful 'soft' landing of any type, for a machine, if only the last 2 seconds of the landing has effectively zero aerodynamic control authority as opposed to a human controlled one where there is maybe 10 or more seconds of that, then the automated landing needs 1/5th or less the control authority because there is 4/5th less possible deviation from when you had aerodynamic control authority.

I quite agree.
If, and only if the vehicle can't hover for a long time, and does not have the control authority to reliably fly through gusts at maximum safe deceleration speed.
If it can hover roughly around the pad waiting for a calm moment - that's quite another thing.
Also unlikely for near-term rockets for both of these to be true.

[Burninate]

But, what I am trying to point out, is that under automated control the slower you go, the harder it is to ignore the  gusts, the less control authority your aerodynamic surfaces have, the more ping ponging you will get with your gimballed engine, etc. with manual control you have no option but to go slow because a human can't do the fast/accurate decelerate to zero at zero in real time. So for a human to control the landing you need far more control authority to make a successful 'soft' landing of any type, for a machine, if only the last 2 seconds of the landing has effectively zero aerodynamic control authority as opposed to a human controlled one where there is maybe 10 or more seconds of that, then the automated landing needs 1/5th or less the control authority because there is 4/5th less possible deviation from when you had aerodynamic control authority.

I quite agree.
If, and only if the vehicle can't hover for a long time, and does not have the control authority to reliably fly through gusts at maximum safe deceleration speed.
If it can hover roughly around the pad waiting for a calm moment - that's quite another thing.
Also unlikely for near-term rockets for both of these to be true.

I don't see it that way.  The decision to hover or not would require foresight of gusts, and the sea is just inherently not very gusty;  Wind is steady and relatively undisturbed by turbulence.  The problem is it doesn't have the control authority to land in *steady state winds* above some level.  Hovering doesn't help.  More fuel doesn't help.  The grid fins don't help.  The barge will be positioned several hundred to several thousand (FH center core) kilometers downrange, far enough that launchsite weather conditions are no guarantee of landing site weather conditions;  And we're probably talking about not very many knots of wind in the first place.

I don't *know* the maximum wind criteria - maybe it won't affect this barge at all (as wind-driven swells might make the barge unusable before windspeed does), but once this is proven the next landing pad can be more seaworthy.

The issue is that the demands of stable flight in a moving airmass with fixed position *using only thrust from the business end of the rocket*, conflict with the demands of touching all four feet to the ground at nearly the same time without significant rotation rate or horizontal velocity.  You can squash any of the variables to zero, but doing so raises at least one of the other variables.

[Robotbeat]

VTVL hovering rockets (F9R isn't going to be hovering, but whatever) can withstand pretty good side winds. Here's "rocket tug of war" from Armadillo Aerospace (or Masten?):


Jon Goff probably has some more war stories.

[Burninate]

VTVL hovering rockets (F9R isn't going to be hovering, but whatever) can withstand pretty good side winds. Here's "rocket tug of war" from Armadillo Aerospace (or Masten?):


Jon Goff probably has some more war stories.

Yes, rockets can be made very effective at holding position *in the air*, but as soon as they touch down, the inherent structural stability and any dynamic momentum in the structure come into play, as well as any pressure from the wind;  The F9R first stage is a giant 18 ton hollow metal tube, with the top ~45 meters off the ground, standing on legs only ~18 meters wide.  A tiny little rocket like the one pictured, with wide, strong legs and a compact, fuel-filled tank, and a short, squat mass distribution, isn't directly comparable.

Maybe if the F9R's legs were actuated to be a dynamic structure which cushions impacts rather than a rigid fixed shape?

[Lars-J]

VTVL hovering rockets (F9R isn't going to be hovering, but whatever) can withstand pretty good side winds. Here's "rocket tug of war" from Armadillo Aerospace (or Masten?):

Jon Goff probably has some more war stories.

Yes, but the main point of the argument (I think) is that hovering doesn't benefit you at all. Just set down directly. The longer you hover, the worse your throttling response will be (craft getting lighter and lighter), and you increase the time that something can go wrong. Waiting for calmer winds is not a good idea, it is just as likely that a stronger gust could come.

It is safest to land as quickly as possible, don't waste time.

[Robotbeat]

VTVL hovering rockets (F9R isn't going to be hovering, but whatever) can withstand pretty good side winds. Here's "rocket tug of war" from Armadillo Aerospace (or Masten?):

Jon Goff probably has some more war stories.

Yes, but the main point of the argument (I think) is that hovering doesn't benefit you at all. Just set down directly. The longer you hover, the worse your throttling response will be (craft getting lighter and lighter), and you increase the time that something can go wrong. Waiting for calmer winds is not a good idea, it is just as likely that a stronger gust could come.

It is safest to land as quickly as possible, don't waste time.

Agreed entirely. Just land the sucker. As I said, F9R isn't going to be hovering.

[Microphobe]

https://en.wikipedia.org/wiki/Pendulum_rocket_fallacy

Thanks for that, great explanation of a counter-intuitive concept.

Another reason not to mount engines, or parachutes or arresting hooks or whatever, to the top of the stage might be that it's built to withstand compressive forces (e.g. max-Q) but not necessarily tensile forces. I'm no engineer but I'd imagine that subjecting the stage to cycles of compressive, then tensile forces each launch would not be great for its lifespan unless significant re-engineering was done.

It's fun to speculate but I'm confident the F9 will get there very soon with only minor tweaks.

However if SpaceX are in the market for crazy suggestions from this forum, how about adding a large unmanned wooden rabbit?

"Look, if we built this    

...later to develop into a crewed wooden badger once the wrinkles in the landing are smoothed out. Elon?

[eriblo]

Another reason not to mount engines, or parachutes or arresting hooks or whatever, to the top of the stage might be that it's built to withstand compressive forces (e.g. max-Q) but not necessarily tensile forces. I'm no engineer but I'd imagine that subjecting the stage to cycles of compressive, then tensile forces each launch would not be great for its lifespan unless significant re-engineering was done.

Another counter-intuitive concept: The stage is actually built more for tensile loads than compressive. Remember that it's pressurized in flight, if the internal pressure is 3 atm then the force on the forward bulkhead is ~300 tonnes. Some stages even use balloon tanks that can't support their own empty compressive loads against gravity

[JamesH]

Yes, but the main point of the argument (I think) is that hovering doesn't benefit you at all. Just set down directly. The longer you hover, the worse your throttling response will be (craft getting lighter and lighter), and you increase the time that something can go wrong. Waiting for calmer winds is not a good idea, it is just as likely that a stronger gust could come.

It is safest to land as quickly as possible, don't waste time.

I think I agree, but without the ability to hover you have precisely one chance to get it right - the accuracy of descent needs to be perfect, the engine needs to ignite at exactly the right time, the throttle response need to be perfect, the wind prediction need to be almost perfect (this should be feasible with the barge telling the rocket what the current deck wind conditions are). Hopefully it works every time. But without a low thrust engine, there are no second chances.

Point being, is it worth sacrificing a bit of performance (by having a lower thrust centre engine - no other changes) to enable a second chance? I suspect not.

Edit/CR: fixed quote tags

[cambrianera]

without the ability to hover you have precisely one chance to get it right

Once your system is perfected (control algorithm enhancement, existing systems tweaking, addition of some auxiliary stuff like grid fins, landing gear with higher margins) you don't need a second chance.
Or better, your second chance for that single case every thousand is a new stage.

[ChrisWilson68]

Yes, but the main point of the argument (I think) is that hovering doesn't benefit you at all. Just set down directly. The longer you hover, the worse your throttling response will be (craft getting lighter and lighter), and you increase the time that something can go wrong. Waiting for calmer winds is not a good idea, it is just as likely that a stronger gust could come.

It is safest to land as quickly as possible, don't waste time.

I think I agree, but without the ability to hover you have precisely one chance to get it right - the accuracy of descent needs to be perfect, the engine needs to ignite at exactly the right time, the throttle response need to be perfect, the wind prediction need to be almost perfect (this should be feasible with the barge telling the rocket what the current deck wind conditions are). Hopefully it works every time. But without a low thrust engine, there are no second chances.

Point being, is it worth sacrificing a bit of performance (by having a lower thrust centre engine - no other changes) to enable a second chance? I suspect not.

No, none of those things has to be perfect.  They have time to continue making corrections during the landing burn.  They just have to be close enough initially that the needed corrections are within the range of throttle, gimbal, etc. that they have available.

Has everyone forgotten that they've done two successful water landings?  They already know how to get the stage to slow down the right amount at the right time with the landing burn.  The only question that was open was weather they could do positional accuracy.  Apparently they can.

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

[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!

[ugordan]

Musk said 50% more hydraulic fluid is all they need to nail the landing.

He never said that, certainly not as confidently as you make it sound.

"With the next flight we have 50% more hydraulic fluid margin. Something else could go wrong, certainly, but at least with respect to that, it should cover. So there's a real decent chance, within three weeks, of landing it."

[ChrisWilson68]

Musk said 50% more hydraulic fluid is all they need to nail the landing.

He never said that, certainly not as confidently as you make it sound.

"With the next flight we have 50% more hydraulic fluid margin. Something else could go wrong, certainly, but at least with respect to that, it should cover. So there's a real decent chance, within three weeks, of landing it."

He also said "Upcoming flight already has 50% more hydraulic fluid, so should have plenty of margin for landing attempt next month.", which was his original statement on the issue, on Twitter, and which didn't contain the qualifications.

Obviously something else could go wrong.  I figured on this forum readers are sophisticated enough it wasn't necessary to say.

Something could go wrong with all the other, much more elaborate, alternative solutions being proposed here.  There's no reason to think any of them is any better than Musk's solution.

[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.

[QuantumG]

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.

This explains so much.

[PreferToLurk]

This might get deleted, but I think it might help illustrate a basic point that many of the more layman visitors to this forum seem to misunderstand frequently.  Hovering seems like it would help because we are taught/trained from the first time our Mothers told us not to run in the house that slow = careful. This makes the fast hoverslam seem like an unnecessary risk that is only being taken because of the limitations of the merlin engine.  This is simply not true.  The power, accuracy, and speed of computer control algorithms is highly unintuitive.

So, without any more lecturing or rambling, I give you Quadrocopter Pole Acrobatics!:

www.youtube.com/embed/pp89tTDxXuI

Forum regulars may remember this clip being posted in one of the original grasshopper threads. 

[douglas100]

Yes, I'd forgotten how amazing it was. I think you've made your point!

[JamesH]

Indeed very impressive. I think my point about the hoverslam now veers more towards the unknowns rather than the computer control then. Quad copters in a room are extremely controllable - you can position them exactly (and they are hovering... and can vary t:w positively and negatively), there is no outside influences (apart from interactions between the craft).

A hoverslam has a more 'unknowns' - wind, engine start and throttle performance, speed and location determination etc.

However, having seen the new pictures, they are clearly almost solved problems!

[ChrisWilson68]

Indeed very impressive. I think my point about the hoverslam now veers more towards the unknowns rather than the computer control then. Quad copters in a room are extremely controllable - you can position them exactly (and they are hovering... and can vary t:w positively and negatively), there is no outside influences (apart from interactions between the craft).

A hoverslam has a more 'unknowns' - wind, engine start and throttle performance, speed and location determination etc.

However, having seen the new pictures, they are clearly almost solved problems!

I think you're missing an important part of how control systems work.

They don't have to understand your "unknowns".  They don't have to expect them, they don't have to model them.  All they have to do is notice that something is causing them to start to deviate from their intended path and apply control inputs to compensate.

As long as the control algorithm is built to work for the properties of the control inputs, it can be very robust and handle all sorts of unexpected outside forces with the same very simple algorithm.

[JamesH]

Indeed very impressive. I think my point about the hoverslam now veers more towards the unknowns rather than the computer control then. Quad copters in a room are extremely controllable - you can position them exactly (and they are hovering... and can vary t:w positively and negatively), there is no outside influences (apart from interactions between the craft).

A hoverslam has a more 'unknowns' - wind, engine start and throttle performance, speed and location determination etc.

However, having seen the new pictures, they are clearly almost solved problems!

I think you're missing an important part of how control systems work.

They don't have to understand your "unknowns".  They don't have to expect them, they don't have to model them.  All they have to do is notice that something is causing them to start to deviate from their intended path and apply control inputs to compensate.

As long as the control algorithm is built to work for the properties of the control inputs, it can be very robust and handle all sorts of unexpected outside forces with the same very simple algorithm.

Yes, I understand all that. I suppose what I'm most specifically thinking about is wind sheer at low levels. You have a lot less time to compensate for issues at that level. Also, the intentionally late ignition of the engine also means less time to compensate for problems that occur at that point. That's what was really making me wonder whether hoverslam or hovering is the better option.  Of course if the barge is sending telemetry to the rocket with the current wind conditions it can take that in to account some distance away, and out at sea the wind does stay fairly consistent. And making a very reliable engine goes some way to ensuring hoverslams are reliable.

[Jim]

Of course if the barge is sending telemetry to the rocket with the current wind conditions

it isn't

[Dudely]

The computers on the F9 are designed to respond two orders of magnitude faster than they need to.

The problem is not as difficult as it sounds. Before you encounter a large force you will encounter a smaller force. Compensating for the small force quickly enough avoids it from ever building up into a large force you cannot control.

I'm at work so I'm not going to do the math, but I don't think there is a wind speed on Earth that can force a stage to divert significantly in the amount of time it takes for the engine/fins to react to the sensor. (Don't quote me, but I think I read they got it down to about 4ms by using a custom Linux kernel)

[kevinof]

As far as we know the barge isn't sending any telemetry to the stage so all the stage can do is aim for a spot. It's like an autopilot/chart plotter on a boat - you tell the boat to aim for X but wind and tides cause drift and the boat keeps adjusting as it aims for the spot. The boat has no idea what's causing the drift but it keep correcting until it's on the lay line.

Indeed very impressive. I think my point about the hoverslam now veers more towards the unknowns rather than the computer control then. Quad copters in a room are extremely controllable - you can position them exactly (and they are hovering... and can vary t:w positively and negatively), there is no outside influences (apart from interactions between the craft).

A hoverslam has a more 'unknowns' - wind, engine start and throttle performance, speed and location determination etc.

However, having seen the new pictures, they are clearly almost solved problems!

I think you're missing an important part of how control systems work.

They don't have to understand your "unknowns".  They don't have to expect them, they don't have to model them.  All they have to do is notice that something is causing them to start to deviate from their intended path and apply control inputs to compensate.

As long as the control algorithm is built to work for the properties of the control inputs, it can be very robust and handle all sorts of unexpected outside forces with the same very simple algorithm.

Yes, I understand all that. I suppose what I'm most specifically thinking about is wind sheer at low levels. You have a lot less time to compensate for issues at that level. Also, the intentionally late ignition of the engine also means less time to compensate for problems that occur at that point. That's what was really making me wonder whether hoverslam or hovering is the better option.  Of course if the barge is sending telemetry to the rocket with the current wind conditions it can take that in to account some distance away, and out at sea the wind does stay fairly consistent. And making a very reliable engine goes some way to ensuring hoverslams are reliable.

[JamesH]

Of course if the barge is sending telemetry to the rocket with the current wind conditions

it isn't

Would doing that make it easier to land accurately, or as others have said, are local wind conditions fairly irrelevant to the landing, i.e. can be compensated for in the last few seconds of descent whatever may be going on?

[Jim]

Would doing that make it easier to land accurately, or as others have said, are local wind conditions fairly irrelevant to the landing, i.e. can be compensated for in the last few seconds of descent whatever may be going on?

No, because now you have to add an additional receiver on the vehicle and it would be like integrating another sensor.  There are issues with validating the information sent and received.   GPS and landing radars can have redundancy and vote out bad information and don't require additional outside information.  Also, current winds conditions are only at one level, it doesn't the whole story of the air column on the way down. 

Aircraft don't incorporate actual wind conditions during the landing.   The pilot/autopilot reacts to the movement of the aircraft away from the desire path and provided corrections.

[JamesH]

Would doing that make it easier to land accurately, or as others have said, are local wind conditions fairly irrelevant to the landing, i.e. can be compensated for in the last few seconds of descent whatever may be going on?

No, because now you have to add an additional receiver on the vehicle and it would be like integrating another sensor.  There are issues with validating the information sent and received.   GPS and landing radars can have redundancy and vote out bad information and don't require additional outside information.  Also, current winds conditions are only at one level, it doesn't the whole story of the air column on the way down. 

Aircraft don't incorporate actual wind conditions during the landing.   The pilot/autopilot reacts to the movement of the aircraft away from the desire path and provided corrections.

Thanks.

[llanitedave]

The problem is not as difficult as it sounds.

I think it's a fascinating reflection on the progress of technological advancement that we can even make that statement today.

[Hotblack Desiato]

is wind really such a problem?

if it is necessary, the barge could be equipped with wind measuring systems and send the data up to the landing stage.

if there is are more accurate data from within the flight path required, maybe quadcopters could even help (not sure, if the idea is good, or if it just sounds good to me, as it is 3:30 am here, and I'm quite tired): send some quadcopters out, at 50, 100, 200 etc. m height, and a bit offset. the quadcopters have gps, and have the command to stay in position until they get called back to the barge. as they have to steer in order to counter the effects of wind, they can calculate the windspeed, and send it to the barge, which relays it to the stage. if it happens that one of those quadcopters is right in the middle of the trajectory of the stage, the exhaust-stream of the rocket would burn it away. and losing a quadcopter is a minor issue.

(and having the idea posted turns it into prior art  )

[mme]

is wind really such a problem?
...

No, it's not.  This entire thread is an attempt to solve a problem that doesn't exist.  The F9 landing is basically a smart bomb targeting a specific set of GPS coordinates.  It's just a smart bomb that starts out higher and faster than normal and that hoverslams instead of exploding (assuming it's on target.)

For the very first attempt they discovered they need more hydraulic fluid to have precise control to the target.  The next attempt will hit the barge more directly.  Maybe even "land."  Autopilots deal with wind all the time without any external information beyond how the aircraft is actually flying.

[JamesH]

is wind really such a problem?
...

No, it's not.  This entire thread is an attempt to solve a problem that doesn't exist.  The F9 landing is basically a smart bomb targeting a specific set of GPS coordinates.  It's just a smart bomb that starts out higher and faster than normal and that hoverslams instead of exploding (assuming it's on target.)

For the very first attempt they discovered they need more hydraulic fluid to have precise control to the target.  The next attempt will hit the barge more directly.  Maybe even "land."  Autopilots deal with wind all the time without any external information beyond how the aircraft is actually flying.

Odd how you can say its a problem that doesn't exist, when no-one has EVER landed and recovered a first stage successfully. Close, but no cigar, to quote a phrase.Once a stage has been landed multiple times successfully, then you say its a solved problem, but not yet.

Hoverslam != explode on impact.

[Jim]

if it is necessary, the barge could be equipped with wind measuring systems and send the data up to the landing stage.

No, read the earlier posts.  That is unnecessary and not really viable.

[mme]

is wind really such a problem?
...

No, it's not.  This entire thread is an attempt to solve a problem that doesn't exist.  The F9 landing is basically a smart bomb targeting a specific set of GPS coordinates.  It's just a smart bomb that starts out higher and faster than normal and that hoverslams instead of exploding (assuming it's on target.)

For the very first attempt they discovered they need more hydraulic fluid to have precise control to the target.  The next attempt will hit the barge more directly.  Maybe even "land."  Autopilots deal with wind all the time without any external information beyond how the aircraft is actually flying.

Odd how you can say its a problem that doesn't exist, when no-one has EVER landed and recovered a first stage successfully. Close, but no cigar, to quote a phrase.Once a stage has been landed multiple times successfully, then you say its a solved problem, but not yet.

Hoverslam != explode on impact.

The stage exploded because it hit the side of the barge while doing a hard divert.  It was doing a hard divert because it could not maintain an on target trajectory.  It could not maintain an on target trajectory because it did not control over it's primary aerodynamic control surfaces for the last minute of "flight."  It didn't have control of the grid fins because it ran out of hydraulic fluid.

Wind was not the problem.  Complex systems to anticipate the wind are not the solution.  The solution is to have control authority for the entire landing process.

The hoverslam itself is not some intractable problem and the term hoverslam is overly dramatic compared to the reality.  All the stage needs is good information regarding the distance to the ground and it's current deceleration.

I do not mean to imply that the targeting and landing control systems are trivial, just that with enough simulation, testing and experimentation I am confident they can be done and that they can be done reliably.

I feel like I've repeated myself too much so I'll do my best to refrain unless I have something new to add the the conversation.

[MarsInMyLifetime]

My view on the wind concern: Once RTLS becomes routine, first stages will be returning through the same air column they transited just 8 minutes earlier. Whenever a remote barge landing is required, we can be certain they'll be aware of those remote weather constraints as well, and launch only when conditions are within rules at both locations. For a rapidly falling stage, wind effects will be relatively minor and somewhat random anyway (evidenced by the twisting ascent trails we see, where the net drift is essentially null even though there may be shear or corkscrew motions in the air column). Skydivers and returning capsules are good analogs of how minor an issue wind will be for a descent that is basically a freefall most of the way.


And I think more than one smart engineer at Spacex has been working on dispersion mitigation.

[LouScheffer]

For a rapidly falling stage, wind effects will be relatively minor and somewhat random anyway (evidenced by the twisting ascent trails we see, where the net drift is essentially null even though there may be shear or corkscrew motions in the air column). Skydivers and returning capsules are good analogs of how minor an issue wind will be for a descent that is basically a freefall most of the way.

And I think more than one smart engineer at Spacex has been working on dispersion mitigation.

The military makes a kit called JDAM that attaches GPS controlled fins to an otherwise conventional bomb.   It's explicitly designed to work in adverse weather, with no input other than GPS (no lidar, fleets of quadcopters, pre-loaded wind tables, etc.)  It's spec'ed at 13 meters accuracy.

Using this 15-20 year old technology, an F9 with working grid fins (but nothing else) could be expected to hit the ship in almost any wind conditions, with no input other than GPS.  Fancy wind compensation schemes are not needed.

http://web.archive.org/web/20030624083412/http://www.af.mil/factsheets/factsheet.asp?fsID=108

[Burninate]

is wind really such a problem?
...

No, it's not.  This entire thread is an attempt to solve a problem that doesn't exist.  The F9 landing is basically a smart bomb targeting a specific set of GPS coordinates.  It's just a smart bomb that starts out higher and faster than normal and that hoverslams instead of exploding (assuming it's on target.)

For the very first attempt they discovered they need more hydraulic fluid to have precise control to the target.  The next attempt will hit the barge more directly.  Maybe even "land."  Autopilots deal with wind all the time without any external information beyond how the aircraft is actually flying.

Odd how you can say its a problem that doesn't exist, when no-one has EVER landed and recovered a first stage successfully. Close, but no cigar, to quote a phrase.Once a stage has been landed multiple times successfully, then you say its a solved problem, but not yet.

Hoverslam != explode on impact.

The stage exploded because it hit the side of the barge while doing a hard divert.  It was doing a hard divert because it could not maintain an on target trajectory.  It could not maintain an on target trajectory because it did not control over it's primary aerodynamic control surfaces for the last minute of "flight."  It didn't have control of the grid fins because it ran out of hydraulic fluid.

Wind was not the problem.  Complex systems to anticipate the wind are not the solution.  The solution is to have control authority for the entire landing process.

The hoverslam itself is not some intractable problem and the term hoverslam is overly dramatic compared to the reality.  All the stage needs is good information regarding the distance to the ground and it's current deceleration.

I do not mean to imply that the targeting and landing control systems are trivial, just that with enough simulation, testing and experimentation I am confident they can be done and that they can be done reliably.

I feel like I've repeated myself too much so I'll do my best to refrain unless I have something new to add the the conversation.

I feel like my point has been lost in the noise, and maybe I didn't do a great job explaining myself, and people elaborated on misconceptions.

I am positing that a wind limit exists (not that I know what it is, just that it exists) beyond which the stage will not be able to land, because of the mismatch between the constant velocity of the air, and the fixed position and zero velocity of the landing pad.  This limit exists for a specific reason: The only way the rocket has of holding position against a wind, is by tilting itself.
1) Vertical descent, fighting wind, tilted profile: If the rocket is substantially tilted when the first landing leg touches the ground during a vertical descent, the force of the dropping rocket will cause it to torque around and maybe topple over.
2) Diagonal descent, static with wind, straight profile: If the rocket tries to track with the wind, coming in diagonally (requiring foreknowledge of wind), but with the tube itself perfectly vertical - that's a neat trick that introduces another problem: Now your rocket is travelling sideways, which when the all four landing legs touch the ground at the same time, induces a torque and maybe topples it.
3) Vertical descent, fighting wind up until last moment, dynamic profile: If the rocket tries to land as with 1) and then rapidly pitches to get all four legs on the ground at the same time for just the moment of impact - Then your rocket is now a rotating body, with angular momentum, and it might topple of its own volition.
4) Diagonal descent, static with wind, until last moment, dynamic profile: If the rocket tries to land as with 2) and then rapidly accelerates sideways to null horizontal velocity - well, the only way to accelerate sideways (induce a horizontal acceleration of center of mass) simultaneously induces a rotation... which might topple it.

Complicating all this is the CoM vs CoP issue in flight, and the fact that large shuttlecocking effects would be observed in wind.

Above some limit of wind, the fact that the only actuator you have simultaneously induces a horizontal acceleration, and induces a rotational acceleration, at the same time, prevents you from landing.  I don't know what that limit is, but it exists in principle.  It's a problem with bringing a high profile rigid object into rendezvous with a surface that has a different velocity than the wind, while still fighting gravity & vertical momentum, on only a rear actuated thruster.

A set of SuperDracos, while a bit overkill for the task, gives very resilient control of orientation if positioned at the top of the rocket, until all four legs are on the ground and velocity & momentum have been zeroed out.  There's still the issue of whether a gale might blow a *standing* landed stage over, but I imagine this limit is well above the limit at which you encounter problems at the landing interface event.

Again: All of this assumes a constant, predictable, prevailing wind, and has nothing to do with turbulent gusts; It has no bearing on hovering, and hovering has no bearing on it.

[Burninate]

There are likely dynamics-based solutions here, but they require extremely fine-grained (temporally and spatially) control of the throttle, and several seconds building up substantial horizontal velocity into the wind, at low vertical velocity, so that the horizontal velocity zeroes out at just the right second without shuttlecocking... but that doesn't factor in...

It's complicated.  More degrees of freedom of control, and specifically much more control authority in pitch and yaw, makes things much, much less fragile in those last few seconds.

[Jim]

I am positing that a wind limit exists (not that I know what it is, just that it exists) beyond which the stage will not be able to land,

And the difference between launch and landing wind limits are small, meaning that is not worth the additional mass, complexity and operational constraints (prelaunch and post recovery) posed by hypergolic superdracos.

[PreferToLurk]

I am positing that a wind limit exists (not that I know what it is, just that it exists) beyond which the stage will not be able to land...

I would posit that while you do NOT know what the wind limit is, that SpaceX DOES know what that limit is.  And yet, they continue attempt landings without superdracos attached to the interstage. 

Superdraco Pros:

1: solves for a hypothetical landing wind limit which we have no way to properly calculate without detailed engineering data which SpaceX will not/cannot divulge.

Superdraco Cons:

1: Weight
2: Complexity (more failure modes)
3: Cost
4: Serious thrust overkill unless you want to attempt a landing in a hurricane.
5: Might not be needed except in exceptionally strong winds: winds that would very likely (or possibly definitely, because we just don't know what the limit is) also prevent the rocket from launching in the first place.
6: SpaceX does not have any of these unknowns and has decided that the current configuration is good enough.

[JamesH]

They have made precisely one attempt to land where wind may be an issue.

Not that I think extra engines at the top are of any benefit at all. I'm more of a would it be worth being able to hover type of person.

[cscott]

It would not be worth it trying to hover.

And seriously, folks, you guys are trying to solve the problem that's been solved for 22 years, since the DC-X did a vertical landing in 1993.  Many have repeated the feat since, and has been demonstrated, the basic technology has now been thoroughly commoditized and you can buy off-the-shelf drones demonstrating all the necessary control algorithms and sensors.

There are two things which make RLVs hard which have never been done before:

1) Hypersonic reentry.  This is very hard, but we don't get pretty video and when successful isn't much to look at.  It's only when unsuccessful that you see the stage tumble/break apart/etc.  This is the hard part that CASSIOPE accomplished, and it's the part which makes the upcoming DSCOVR landing much harder than the CRS-5 attempt.  But nobody is talking about this.  Why?

2) Cost-effective reuse.  This is what F9dev2 will be investigating, but it's treated as a fait accompli somehow in this forum, with people claiming that all the New Mexico testing is worthless now.  It's not.  High-frequency operations and reuse is hard, and there is a lot of work yet to be done.

Please let's stop talking about the hoverslam.

[zodiacchris]

Amen, I can't believe we are still talking about this! 

[JamesH]

It would not be worth it trying to hover.

And seriously, folks, you guys are trying to solve the problem that's been solved for 22 years, since the DC-X did a vertical landing in 1993.  Many have repeated the feat since, and has been demonstrated, the basic technology has now been thoroughly commoditized and you can buy off-the-shelf drones demonstrating all the necessary control algorithms and sensors.

There are two things which make RLVs hard which have never been done before:

1) Hypersonic reentry.  This is very hard, but we don't get pretty video and when successful isn't much to look at.  It's only when unsuccessful that you see the stage tumble/break apart/etc.  This is the hard part that CASSIOPE accomplished, and it's the part which makes the upcoming DSCOVR landing much harder than the CRS-5 attempt.  But nobody is talking about this.  Why?

2) Cost-effective reuse.  This is what F9dev2 will be investigating, but it's treated as a fait accompli somehow in this forum, with people claiming that all the New Mexico testing is worthless now.  It's not.  High-frequency operations and reuse is hard, and there is a lot of work yet to be done.

Please let's stop talking about the hoverslam.

No, because nothing you say in the post means a hoverslam is guaranteed to be successful which is what you are saying (I actually think it will be, but I have no evidence to support that and no-one has supplied any)

A huge first stage rocket, with a T:W > 1 is not a three axis controllable electric propeller driven drone, that's a strawman. It's also not a DC-X (which could hover...). This 'hoverslam' (and I dislike the term but there seems no other option) has never been tested successfully. You can quote as many other technologies as you like, or extrapolate from what we have seen, but it has NEVER been tested successfully.

I'm all for optimism (I think they may well get it within the next couple of flights), but try and keep it pragmatic optimism.

I agree with your points 1 and 2, that's optimism gone too far.

[cscott]

A hoverslam is no different from all the other extremely complex control problems that computers accomplish effortlessly, every single day.  Forget C++ and python---go find a *MATLAB* programmer and ask them about it.

 (Oh, and the grasshopper/F9dev1 already demonstrated hoverslam at least once. Go search the forums for the analysis.)

Note that I'm not saying that executing a hoverslam is *easy*---it's still an engineering challenge to build a reliable machine which can execute your control program with extremely tight mass margins and after having survived hypersonic reentry, and do so in a way which is rapidly reusable, etc --- but see: those are the parts of the task which are *not a hoverslam*.

[JamesH]

Saying that a hoverslam is somehow different from all the other extremely complex control problems that computers accomplish effortlessly, every single day, reveals nothing but a profound misunderstanding of the task.  Forget C++ and python---go find a *MATLAB* programmer and ask her about it.

 (Oh, and the grasshopper program already demonstrated hoverslam at least once. Go search the forums for the analysis.)

Note that I'm not saying that executing a hoverslam is *easy*---it's still an engineering challenge to build a reliable machine which can execute your control program with extremely tight mass margins and after having survived hypersonic reentry, and do so in a way which is rapidly reusable, etc --- but see: those are the parts of the task which are *not a hoverslam*.

Cool. I wasn't aware that the Grasshopper turned its engines off, dropped until it reached two hundred mile an hour whist travelling at an angle, then reignited its engines, deployed it legs and landed successfully.

Mainly because it didn't. As far am I know, that is the sort of sequence required to hoverslam and land. Grasshopper had rigid legs, and I don't think ever turned it's engine off in flight.

I not disagreeing that a lot of complex stuff has already been achieved,  that is clear by the results so far. What I don't understand is why people think it's a completely solved problem when it's never been successfully demonstrated. Put it like this, if it's a solved problem you would be more that happy to bet considerable sums on money on working next time. Would you willing to bet considerable sums of money on the next flight being successful?

Please explain why you are so sure this is a solved problem when even Musk only gives it a 60% chance of landing next time.

(I used to work with the wife, a mathematician, of one of the matlab developers, so I am aware of it. Not sure what referencing it has to do with the discussion though)

[sublimemarsupial]

Saying that a hoverslam is somehow different from all the other extremely complex control problems that computers accomplish effortlessly, every single day, reveals nothing but a profound misunderstanding of the task.  Forget C++ and python---go find a *MATLAB* programmer and ask her about it.

 (Oh, and the grasshopper program already demonstrated hoverslam at least once. Go search the forums for the analysis.)

Note that I'm not saying that executing a hoverslam is *easy*---it's still an engineering challenge to build a reliable machine which can execute your control program with extremely tight mass margins and after having survived hypersonic reentry, and do so in a way which is rapidly reusable, etc --- but see: those are the parts of the task which are *not a hoverslam*.

Cool. I wasn't aware that the Grasshopper turned its engines off, dropped until it reached two hundred mile an hour whist travelling at an angle, then reignited its engines, deployed it legs and landed successfully.

Mainly because it didn't. As far am I know, that is the sort of sequence required to hoverslam and land. Grasshopper had rigid legs, and I don't think ever turned it's engine off in flight.

Grasshopper didn't, but the first stages of both F9-9 and F9-10 successfully did the hoverslam on the ocean surface before being destroyed by the subsequent tip over and impact.

[cscott]

Musk gives it a low probability because *the hypersonic reentry will be hard*.

[Misha Vargas]

[....]
Grasshopper had rigid legs, and I don't think ever turned it's engine off in flight.
[...]

Grasshopper II (actually F9R Dev-1) had legs just like those seen on the orbital flights. You can see them working just fine in three videos on SpaceX's YouTube channel. Anyways legs aren't seemingly an issue at any point, looking at their successful deployment in multiple flights. And hoverslams are already proven, as cscott said. It's really nothing more than slowing down right up to touchdown.

[mme]

...
(I used to work with the wife, a mathematician, of one of the matlab developers, so I am aware of it. Not sure what referencing it has to do with the discussion though)

The fact that it's the primer tool in designing and modeling real time control systems with complex feedback mechanisms is highly relevant:

http://en.wikibooks.org/wiki/Control_Systems/MATLAB

http://www.mathworks.com/products/control/index.html

http://www.mathworks.com/help/control/examples.html

[mme]

Actual real-world facts

March 7, 2013 Grasshopper lands with a TW > 1 using closed loop thrust vector and throttle control.

September 29, 2013 CASIOPE survives hypersonic reentry, restarts engine for the landing burn and decelerates until engine shutdown do to spinning caused by aerodynamic forces.  SpaceX reinforces the internal baffles and beefs up the cold gas thrusters.  Every subsequent stage that attempts reentry survives all the way to the water.

April 18, 2014 CRS-3, first stage with legs.  Survives hypersonic reentry, restarts it's center engine, deploys legs and touches down gently.  Garbled video is restored by a massive effort of volunteers so you can watch it yourself.

July 14, 2014 OG2, second flight with legs.  Survives hypersonic reentry, restarts engine for the landing burn, deploys legs and touches down gently.  You can watch the video yourself.

January 10, 2015, third flight with legs and the first with grid fins. Deploys the grid fins, survives hypersonic reentry and controls flight with grid fins until it runs out of hydraulic fluid and they go "hard over", restarts the engine, deploys legs, decelerates and tries to compensate for missing the target with a hard divert.  Hits the barge from the side and explodes.

So the following problems are already solved and are irrelevant to the complexity and difficulty of the task of landing the stage moving forward:

Hypersonic reentry (at least for certain mission profiles.)
Deployment of the gird fins and use from hypersonic down to subsonic.
Multiple engine restarts, including the landing burn.
Deploying the landing legs.

All that's left is improving the targeting so no hard divert is required at the end and the final touchdown.  Most of us believe that having control of the gird fins for the final minute makes the problem of targeting the landing area solvable.

The stage is decelerating from terminal velocity during the landing burn.  The landing burn is over 20 seconds long.  That is an eternity for a control system using LIDAR feedback to touch down gently.  The final seconds of the landing the rocket is moving quite slowly, the control system has an excellent map of the Merlin's actual real world responsiveness during the current flight.  And Grasshopper has demonstrated landing with a TW > 1.  The problem is clearly solvable.

Conclusion

I don't know how many attempts or refinements it will take, but the problem of returning an F9 from a mission and landing it on a barge is solvable without adding the ability to hover.

[The Amazing Catstronaut]

Actual real-world facts

I don't know how many attempts or refinements it will take, but the problem of returning an F9 from a mission and landing it on a barge is solvable without adding the ability to hover.

...Just to add another detail here to the excellent point above; if you try to fix something that isn't damaged, you risk creating problems where no problem is present - it happens all the time in engineering, programming, psychology, you name it.

In this case, you add a significant amount of mass to the top of the stage. This, in turn, will affect various other factors; the amount of RC thrust required to flip the stage before boostback/generally manoeuvre the stage, the stability of the F9R bottom stage whilst returned onto the pad (You're adding mass to the top of a very thin, otherwise stable object), potential plumbing problems, payload cuts, reducing the effectiveness of the grid fins, quite possibly having to reprogram the guidance software...

It's going to work as-is.

Edit: Apologies if somebody has already mentioned all of these points; I didn't read the full thread before posting.

[JamesH]

I salute your optimism. In fact I agree with you.

Everything is solved.

We just need to wait until the solution can be implemented. Rocket science is easy, rocket engineering is hard. I'm not arguing against the software or the science behind the technique. That is clearly sound. I'm less optimistic that the engineering can ensure the landing are reliable. A lot needs to work just right, guidance, hydraulics, engine, environmental conditions and there are no second chances with the hoverslam approach.

WIth regard to one point above, the F9R-dev cannot have done a test flight with an engine TW >1 at all times. That basically the definition of going up, not down. It carried a fuel load to ensure the engine could be throttled back enough to give TW<1.The returning stage does not have that much fuel, so at no point has a TW<1 except when it's engine off, so that is an invalid argument (and the F9R-dev can hover, as we all know, so really, it's flights are not entirely relevant wrt this discussion)

[Lars-J]

I salute your optimism. In fact I agree with you.

Everything is solved.

We just need to wait until the solution can be implemented. Rocket science is easy, rocket engineering is hard. I'm not arguing against the software or the science behind the technique. That is clearly sound. I'm less optimistic that the engineering can ensure the landing are reliable. A lot needs to work just right, guidance, hydraulics, engine, environmental conditions and there are no second chances with the hoverslam approach.

And what second chances do you think you get with hovering capability? "Oh wait, I came down in the wrong spot, let me move over and try again?" Is that what you think is needed to make this reliable enough for your engineering stamp of approval?

How much spare propellant must F9R carry - and extra throttling range to the M1D must be added - before you deem it advisable to even start testing?

This is a TEST program. You make things reliable by testing them. Sometimes it works, sometimes it doesn't. But that's OK. SpaceX is not going to go under if they can't reuse the next landed first stage. And no one is being forced to sit on it as it lands. It is an UNMANNED test.

WIth regard to one point above, the F9R-dev cannot have done a test flight with an engine TW >1 at all times. That basically the definition of going up, not down. It carried a fuel load to ensure the engine could be throttled back enough to give TW<1.The returning stage does not have that much fuel, so at no point has a TW<1 except when it's engine off, so that is an invalid argument (and the F9R-dev can hover, as we all know, so really, it's flights are not entirely relevant wrt this discussion)

Are you intentionally being obtuse? When was it claimed the whole flight used a TW > 1?

[cambrianera]

A lot needs to work just right, guidance, hydraulics, engine, environmental conditions and there are no second chances with the hoverslam approach.

If the things you described don‘t work right, you are toasted also if you can hover.
And hovering with a rocket is utterly inefficient (remember, only racing requires more performance than rockets!)

[nadreck]

Is it worth my mentioning again that the mechanics of bringing a hovering F9 first stage down onto the deck of a barge (or to an eventual land based location) are far more demanding than the direct in, reduce to zero V_x + zero V_y + zero V_z @ zero altitude and zero x, y and z offset from the centre of the X on the barge.  Once you are hovering, you now are being exposed continuously to the local winds, when you were coming in you could adjust your engine angle by a much smaller amount to compensate for wind (10s before landing your velocity is 100m/s a 5m/s gust/shear requires 1/10th the correction that it would at 10m/s 1s before landing and 1/20th the correction that you would need hovering 5 meters above the deck (presuming that you descend from hover at .5 g to gain speed and then decelerate with 1.5g thrust the remainder of the time).  As well, your grid fins had some authority down to a handfull of seconds before touch down and the longer you hover the longer you have to put up with buffeting at the level where it is most gusty/sheary.

Either the controls are accurate enough to allow the computer to manage engine thrust, reduce to zero altitude zero V at the target at 1G deceleration straight on to the deck, or it is not good enough to manage to go from hovering anywhere and get to the deck and you need a human remotely piloting it to land it.  If the engine responds variably to gymballing and thrust level control inputs the piloting program must respond immediately to that adjusting the control signals, but it already had to vary all of these things continuously as the weight changed and air density changed to match its course profile.

[Burninate]

Is it worth my mentioning again that the mechanics of bringing a hovering F9 first stage down onto the deck of a barge (or to an eventual land based location) are far more demanding than the direct in, reduce to zero V_x + zero V_y + zero V_z @ zero altitude and zero x, y and z offset from the centre of the X on the barge.  Once you are hovering, you now are being exposed continuously to the local winds, when you were coming in you could adjust your engine angle by a much smaller amount to compensate for wind (10s before landing your velocity is 100m/s a 5m/s gust/shear requires 1/10th the correction that it would at 10m/s 1s before landing and 1/20th the correction that you would need hovering 5 meters above the deck (presuming that you descend from hover at .5 g to gain speed and then decelerate with 1.5g thrust the remainder of the time).  As well, your grid fins had some authority down to a handfull of seconds before touch down and the longer you hover the longer you have to put up with buffeting at the level where it is most gusty/sheary.

Either the controls are accurate enough to allow the computer to manage engine thrust, reduce to zero altitude zero V at the target at 1G deceleration straight on to the deck, or it is not good enough to manage to go from hovering anywhere and get to the deck and you need a human remotely piloting it to land it.  If the engine responds variably to gymballing and thrust level control inputs the piloting program must respond immediately to that adjusting the control signals, but it already had to vary all of these things continuously as the weight changed and air density changed to match its course profile.

Three separate problems.  The "Accurate Hypersonic reentry problem" is something that they seem to have *very quietly* solved.  This was a Big Deal behind the scenes, and may even prove the little-researched concept of supersonic retropopulsion.

If you solve that, you get to -

The "Hoverslam Problem" is landing at all, transitioning from terminal velocity to pad safely in still air, with a TWR minimum of much more than 1.  I don't think there's anything standing in the way of that, at this point.  It doesn't need SuperDracos.  To my mind this had a first tentative solution with the arrangement Grasshopper was running, and it will be refined as time goes on.  Hovering is unnecessary if guidance is good enough to hit a ~150ft target (which, again, was the Accurate Hypersonic Reentry Problem), and in the first barge test, guidance was good enough to hit the edge of the barge even without the supposedly critical grid fins, though not good enough to land.

If you solve that, you get to -

The "Windy Landing Problem" is something that is not a problem as long as the landing pad is not windy.  It has to do with what happens as, and just after, the first leg hits the ground.  This isn't a priority early on, solving the first two problems is.  It only becomes a mild problem as Falcon 9 starts to operate reusably all the time - a few hundred kilometers is enough for a slightly different weather system. and not all launch windows can be pushed back easily.  It then becomes a moderate problem for Falcon Heavy centercore reuse, which has to happen much farther downrange.

There are indications from Grasshopper that the Windy Landing Problem isn't so severe, but we do not have the data.  The Hoverslam Problem and the Windy Landing problem are very nearly unrelated - and solving the one does not solve the other.  This thread originally proposed SuperDracos for the Hoverslam Problem, and I think that it's been shown by Grasshopper that this is unnecessary.  The Windy Landing Problem... maybe - they could certainly improve capabilities in that respect, at some significant cost.  We'll have to see.

Enough said.

[cscott]

The "rocket tug of war" tests by armadillo and masten are fairly convincing wrt the windy landing problem.

[mme]

I salute your optimism. In fact I agree with you.

Everything is solved.

We just need to wait until the solution can be implemented. Rocket science is easy, rocket engineering is hard. I'm not arguing against the software or the science behind the technique. That is clearly sound. I'm less optimistic that the engineering can ensure the landing are reliable. A lot needs to work just right, guidance, hydraulics, engine, environmental conditions and there are no second chances with the hoverslam approach.

WIth regard to one point above, the F9R-dev cannot have done a test flight with an engine TW >1 at all times. That basically the definition of going up, not down. It carried a fuel load to ensure the engine could be throttled back enough to give TW<1.The returning stage does not have that much fuel, so at no point has a TW<1 except when it's engine off, so that is an invalid argument (and the F9R-dev can hover, as we all know, so really, it's flights are not entirely relevant wrt this discussion)

I explicitly listed the problems that were solved, what the remaining problems were and why I believe they are solvable.

Grasshopper and F9R-Dev land with the engines running TW > 1.  What happens before then is irrelevant because by the time a stage is anywhere close to the ground it is moving slowly.

Edit: Removed inappropriate and uncalled for expression of frustration.  Added underlined clarification.  I'll leave it be now.  PM me if you think anything else I've written is uncivil.

[JamesH]

I salute your optimism. In fact I agree with you.

Everything is solved.

We just need to wait until the solution can be implemented. Rocket science is easy, rocket engineering is hard. I'm not arguing against the software or the science behind the technique. That is clearly sound. I'm less optimistic that the engineering can ensure the landing are reliable. A lot needs to work just right, guidance, hydraulics, engine, environmental conditions and there are no second chances with the hoverslam approach.

WIth regard to one point above, the F9R-dev cannot have done a test flight with an engine TW >1 at all times. That basically the definition of going up, not down. It carried a fuel load to ensure the engine could be throttled back enough to give TW<1.The returning stage does not have that much fuel, so at no point has a TW<1 except when it's engine off, so that is an invalid argument (and the F9R-dev can hover, as we all know, so really, it's flights are not entirely relevant wrt this discussion)

I explicitly listed the problems that were solved, what the remaining problems were and why I believe they are solvable.  I don't appreciate the cherry picking nor the explicit misrepresentation of what I wrote.

Grasshopper and F9R-Dev land with the engines running TW > 1.  What happens before then is irrelevant.

Clearly you are committed to "hovering is better."    But guess what?  If guidance, hydraulics, or engines fail or if environmental conditions are outside the operational limits of a rocket that can hover - it still crashes.

No, I am not committed to hovering is better - please read the original posts and don't read ion to my posts what isn;t there. What I'm looking for is reasons why it might be better or worse than the hoverslam. Does it give a better chance of landing safely than hoverslam? If so, are the benefits of, on average, more safe landings, worth the additional cost? That's all. Hadn't realised asking questions would result in such angst. From the comments above, there is, finally, one, that has actually gone to the effort of explaining why rather than simply claiming the hoverslam is better and solved.  So thanks you to that commenter who actually spent the time on it, rather than simply claiming something that has never been demonstrated is the clearly final solution and cannot be improved.

And no, I am not being obtuse about the F9R-dev and TW>1, but thanks for the rudeness. Can I suggest that rather than casting aspersions, you actually read what I wrote, which I will now repeat. The testing of the F9R-dev was brought up as an example of part of the solution of landing the F9R 1st stage with reference to TW. My point was that the F9R-dev, for it entire flight, has the ability to have a TW < 1 and clearly uses it. This is simply not the case for the returning stage, and therefore is not a good example to give when talking about the hoverslam landing, which in my mind is a different problem, and there is no direct comparison. The entire F9R-dev landing except the final 1/2s or so is done at TW < 1, with the stage travelling very slowly. It's very useful as a test bed for a multitude of other reasons of course, and presumably the future testing will test hoverslam landings as they will have the ability to replicate launch landing conditions more accurately.

[Tass]

My point was that the F9R-dev, for it entire flight, has the ability to have a TW < 1 and clearly uses it.

It doesn't. Only in the beginning when the fuel load is larger.

[PreferToLurk]

Hoverslam evidence links:

Grasshopper final flight.  Terminal Thrust to weight estimated at 1.8 for the final 4 seconds of flight. Full analysis and discussion through link.

http://forum.nasaspaceflight.com/index.php?topic=32718.msg1116648#msg1116648

Still Searching for more. Will update post. 

Edit:  Hm..  Could have sworn Hrissan did an analysis of one of the F9R-Dev1 landings, but I cant find any.  Must have been someone else. I will keep looking.

Edit 2:  looks like detailed analysis did not happen for F9R-Dev1 flights, but from looking at the videos it does not immediately appear like they attempted another landing as aggressive as the last Grasshopper flight.

either way, Grasshopper coming in for a 1.8g landing is very impressive, and proves the case. IMHO

[JFARNS]

Seems to me that the Grasshopper & Dev-1 programs would have been designed to test the hover-slam among other things. Also I would think that the landing leg design would have taken into account two and even one legged touchdown. Leg weight vs strength, strut compression vs fuel tank puncture resistance at attach points.  Lots of trades. Super Dracos plus fuel plus plumbing = lots of weight.

Also as has been pointed out, computers move in "bullet time" so remember Theo there is no wind.

[Burninate]

I would like to see the SuperDracos available in this capacity specifically to aid in solving all ~12 degrees of freedom that need to be correct for a soft touchdown, amidst a moving reference frame. 3D position, 3D orientation, 3D velocity, 3D rotational velocity all need to be near-zero relative to the landing zone at impact, and long after the grid fins cease to be effective.  Fighting any significant wind from terminal velocity to ship velocity with the main engines essentially requires that some of these variables diverge from zero.  More wind, more problems.  SuperDracos provide extra thrust in the right directions at very high frequency.  This is *far* more useful than merely slowing down the hoverslam descent to lower G-ratings, 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.

Two problems with this, though:
1) While CoM does not have a huge effect during the flight of a pure rocket, contrary to intuition...  it does have a large effect on stability for the duration that the landing legs touch the deck.

2) Nitrogen tetroxide and monomethyl hydrazine.  If the landing requires these in quantity, the landing zone is a HAZMAT zone, and approval for such landings is even harder.  Green hypergolic propellants would be very strongly preferred.

But, what I am trying to point out, is that under automated control the slower you go, the harder it is to ignore the  gusts, the less control authority your aerodynamic surfaces have, the more ping ponging you will get with your gimballed engine, etc. with manual control you have no option but to go slow because a human can't do the fast/accurate decelerate to zero at zero in real time. So for a human to control the landing you need far more control authority to make a successful 'soft' landing of any type, for a machine, if only the last 2 seconds of the landing has effectively zero aerodynamic control authority as opposed to a human controlled one where there is maybe 10 or more seconds of that, then the automated landing needs 1/5th or less the control authority because there is 4/5th less possible deviation from when you had aerodynamic control authority.

I quite agree.
If, and only if the vehicle can't hover for a long time, and does not have the control authority to reliably fly through gusts at maximum safe deceleration speed.
If it can hover roughly around the pad waiting for a calm moment - that's quite another thing.
Also unlikely for near-term rockets for both of these to be true.

I don't see it that way.  The decision to hover or not would require foresight of gusts, and the sea is just inherently not very gusty;  Wind is steady and relatively undisturbed by turbulence.  The problem is it doesn't have the control authority to land in *steady state winds* above some level.  Hovering doesn't help.  More fuel doesn't help.  The grid fins don't help.  The barge will be positioned several hundred to several thousand (FH center core) kilometers downrange, far enough that launchsite weather conditions are no guarantee of landing site weather conditions;  And we're probably talking about not very many knots of wind in the first place.

I don't *know* the maximum wind criteria - maybe it won't affect this barge at all (as wind-driven swells might make the barge unusable before windspeed does), but once this is proven the next landing pad can be more seaworthy.

The issue is that the demands of stable flight in a moving airmass with fixed position *using only thrust from the business end of the rocket*, conflict with the demands of touching all four feet to the ground at nearly the same time without significant rotation rate or horizontal velocity.  You can squash any of the variables to zero, but doing so raises at least one of the other variables.

VTVL hovering rockets (F9R isn't going to be hovering, but whatever) can withstand pretty good side winds. Here's "rocket tug of war" from Armadillo Aerospace (or Masten?):


Jon Goff probably has some more war stories.

Yes, rockets can be made very effective at holding position *in the air*, but as soon as they touch down, the inherent structural stability and any dynamic momentum in the structure come into play, as well as any pressure from the wind;  The F9R first stage is a giant 18 ton hollow metal tube, with the top ~45 meters off the ground, standing on legs only ~18 meters wide.  A tiny little rocket like the one pictured, with wide, strong legs and a compact, fuel-filled tank, and a short, squat mass distribution, isn't directly comparable.

Maybe if the F9R's legs were actuated to be a dynamic structure which cushions impacts rather than a rigid fixed shape?

is wind really such a problem?
...

No, it's not.  This entire thread is an attempt to solve a problem that doesn't exist.  The F9 landing is basically a smart bomb targeting a specific set of GPS coordinates.  It's just a smart bomb that starts out higher and faster than normal and that hoverslams instead of exploding (assuming it's on target.)

For the very first attempt they discovered they need more hydraulic fluid to have precise control to the target.  The next attempt will hit the barge more directly.  Maybe even "land."  Autopilots deal with wind all the time without any external information beyond how the aircraft is actually flying.

Odd how you can say its a problem that doesn't exist, when no-one has EVER landed and recovered a first stage successfully. Close, but no cigar, to quote a phrase.Once a stage has been landed multiple times successfully, then you say its a solved problem, but not yet.

Hoverslam != explode on impact.

The stage exploded because it hit the side of the barge while doing a hard divert.  It was doing a hard divert because it could not maintain an on target trajectory.  It could not maintain an on target trajectory because it did not control over it's primary aerodynamic control surfaces for the last minute of "flight."  It didn't have control of the grid fins because it ran out of hydraulic fluid.

Wind was not the problem.  Complex systems to anticipate the wind are not the solution.  The solution is to have control authority for the entire landing process.

The hoverslam itself is not some intractable problem and the term hoverslam is overly dramatic compared to the reality.  All the stage needs is good information regarding the distance to the ground and it's current deceleration.

I do not mean to imply that the targeting and landing control systems are trivial, just that with enough simulation, testing and experimentation I am confident they can be done and that they can be done reliably.

I feel like I've repeated myself too much so I'll do my best to refrain unless I have something new to add the the conversation.

I feel like my point has been lost in the noise, and maybe I didn't do a great job explaining myself, and people elaborated on misconceptions.

I am positing that a wind limit exists (not that I know what it is, just that it exists) beyond which the stage will not be able to land, because of the mismatch between the constant velocity of the air, and the fixed position and zero velocity of the landing pad.  This limit exists for a specific reason: The only way the rocket has of holding position against a wind, is by tilting itself.
1) Vertical descent, fighting wind, tilted profile: If the rocket is substantially tilted when the first landing leg touches the ground during a vertical descent, the force of the dropping rocket will cause it to torque around and maybe topple over.
2) Diagonal descent, static with wind, straight profile: If the rocket tries to track with the wind, coming in diagonally (requiring foreknowledge of wind), but with the tube itself perfectly vertical - that's a neat trick that introduces another problem: Now your rocket is travelling sideways, which when the all four landing legs touch the ground at the same time, induces a torque and maybe topples it.
3) Vertical descent, fighting wind up until last moment, dynamic profile: If the rocket tries to land as with 1) and then rapidly pitches to get all four legs on the ground at the same time for just the moment of impact - Then your rocket is now a rotating body, with angular momentum, and it might topple of its own volition.
4) Diagonal descent, static with wind, until last moment, dynamic profile: If the rocket tries to land as with 2) and then rapidly accelerates sideways to null horizontal velocity - well, the only way to accelerate sideways (induce a horizontal acceleration of center of mass) simultaneously induces a rotation... which might topple it.

Complicating all this is the CoM vs CoP issue in flight, and the fact that large shuttlecocking effects would be observed in wind.

Above some limit of wind, the fact that the only actuator you have simultaneously induces a horizontal acceleration, and induces a rotational acceleration, at the same time, prevents you from landing.  I don't know what that limit is, but it exists in principle.  It's a problem with bringing a high profile rigid object into rendezvous with a surface that has a different velocity than the wind, while still fighting gravity & vertical momentum, on only a rear actuated thruster.

A set of SuperDracos, while a bit overkill for the task, gives very resilient control of orientation if positioned at the top of the rocket, until all four legs are on the ground and velocity & momentum have been zeroed out.  There's still the issue of whether a gale might blow a *standing* landed stage over, but I imagine this limit is well above the limit at which you encounter problems at the landing interface event.

Again: All of this assumes a constant, predictable, prevailing wind, and has nothing to do with turbulent gusts; It has no bearing on hovering, and hovering has no bearing on it.

There are likely dynamics-based solutions here, but they require extremely fine-grained (temporally and spatially) control of the throttle, and several seconds building up substantial horizontal velocity into the wind, at low vertical velocity, so that the horizontal velocity zeroes out at just the right second without shuttlecocking... but that doesn't factor in...

It's complicated.  More degrees of freedom of control, and specifically much more control authority in pitch and yaw, makes things much, much less fragile in those last few seconds.

Is it worth my mentioning again that the mechanics of bringing a hovering F9 first stage down onto the deck of a barge (or to an eventual land based location) are far more demanding than the direct in, reduce to zero V_x + zero V_y + zero V_z @ zero altitude and zero x, y and z offset from the centre of the X on the barge.  Once you are hovering, you now are being exposed continuously to the local winds, when you were coming in you could adjust your engine angle by a much smaller amount to compensate for wind (10s before landing your velocity is 100m/s a 5m/s gust/shear requires 1/10th the correction that it would at 10m/s 1s before landing and 1/20th the correction that you would need hovering 5 meters above the deck (presuming that you descend from hover at .5 g to gain speed and then decelerate with 1.5g thrust the remainder of the time).  As well, your grid fins had some authority down to a handfull of seconds before touch down and the longer you hover the longer you have to put up with buffeting at the level where it is most gusty/sheary.

Either the controls are accurate enough to allow the computer to manage engine thrust, reduce to zero altitude zero V at the target at 1G deceleration straight on to the deck, or it is not good enough to manage to go from hovering anywhere and get to the deck and you need a human remotely piloting it to land it.  If the engine responds variably to gymballing and thrust level control inputs the piloting program must respond immediately to that adjusting the control signals, but it already had to vary all of these things continuously as the weight changed and air density changed to match its course profile.

Three separate problems.  The "Accurate Hypersonic reentry problem" is something that they seem to have *very quietly* solved.  This was a Big Deal behind the scenes, and may even prove the little-researched concept of supersonic retropopulsion.

If you solve that, you get to -

The "Hoverslam Problem" is landing at all, transitioning from terminal velocity to pad safely in still air, with a TWR minimum of much more than 1.  I don't think there's anything standing in the way of that, at this point.  It doesn't need SuperDracos.  To my mind this had a first tentative solution with the arrangement Grasshopper was running, and it will be refined as time goes on.  Hovering is unnecessary if guidance is good enough to hit a ~150ft target (which, again, was the Accurate Hypersonic Reentry Problem), and in the first barge test, guidance was good enough to hit the edge of the barge even without the supposedly critical grid fins, though not good enough to land.

If you solve that, you get to -

The "Windy Landing Problem" is something that is not a problem as long as the landing pad is not windy.  It has to do with what happens as, and just after, the first leg hits the ground.  This isn't a priority early on, solving the first two problems is.  It only becomes a mild problem as Falcon 9 starts to operate reusably all the time - a few hundred kilometers is enough for a slightly different weather system. and not all launch windows can be pushed back easily.  It then becomes a moderate problem for Falcon Heavy centercore reuse, which has to happen much farther downrange.

There are indications from Grasshopper that the Windy Landing Problem isn't so severe, but we do not have the data.  The Hoverslam Problem and the Windy Landing problem are very nearly unrelated - and solving the one does not solve the other.  This thread originally proposed SuperDracos for the Hoverslam Problem, and I think that it's been shown by Grasshopper that this is unnecessary.  The Windy Landing Problem... maybe - they could certainly improve capabilities in that respect, at some significant cost.  We'll have to see.

Enough said.

So: I spent this thread a few months back contending that there is a durable, tricky controls problem with landing against winds or with any substantial lateral motion, and that rotational control authority is a distinctly lacking feature of the present design.  I thought that it was likely at some wind level to lead to tipping over after the forces induced by the first leg touching the ground, even though the rocket was in the right place, and with the right vertical velocity, to set down safely otherwise.  The position and velocity and rotation vectors, and their first derivatives, all have to be zeroed out at the right moment to a low enough tolerance, and this is very hard to do when actuating only one Merlin 1D, after the grid fins have ceased to be useful, because it's a highly coupled system and there's no static solution during descent.

The landing, video 1

Pics:




Video 2 to come in a few days when they've got the barge back

Elon Musk @elonmusk  ·  5h 5 hours ago
Looks like Falcon landed fine, but excess lateral velocity caused it to tip over post landing
Elon Musk @elonmusk  ·  4h 4 hours ago
@kwrzesien It is a lot like Lunar Lander, except with 6X higher gravity and a tiny landing area
Elon Musk @elonmusk  ·  3h 3 hours ago
@teknotus There are nitrogen thrusters at top of rocket. Either not enough thrust to stabilize or a leg was damaged. Data review needed.

Do you believe me now?


Those nitrogen thrusters can't produce all that much thrust.  Draco thrusters get their own name and only produce 400N - the same force as a 40kg weight a strong person might be capable of lifting up with one hand;  a list of example cold gas thrusters are substantially smaller.  These are not large forces compared to a rapidly falling 18 ton rocket, nor the wind forces on that rocket, nor the rotational moment induced by vectoring the thrust of a Merlin 1D.  Using SuperDracos in this manner would not be a painless trade-off at all, but it may end up being required if today's performance is not fixable in software.  High frequency, high-thrust control of attitude makes landing solutions much more resilient to suboptimal conditions.

[Jim]

Do you believe me now?

No, still too early to pat yourself on the back

[Burninate]

Imported from the other thread:

3) a) Discussion of wind here in this chat room of the internets is useless. Wind on that cylinder whether its a significant force or not is easy to model and has been thought through vastly more than our words and the wind from our mouths will accomplish.

I have an aerospace engineering degree - the wind-induced drag on a large cylinder is significant but not as significant as the vertically-assymmetrical drag on the entire stage once those legs deploy.

b) Observations of a flag which is seen to be flying briskly in a direction radially away from an active rocket engine are not reliable indications of a meterological wind.  A review of the Apollo 11 lunar surface flag during liftoff would under that logic lead one to believe that it happened on a windy day on the moon.  I watched that moon walk and I can attest that there was no appreciable wind on the surface until they lit that thing.

The reported wind conditions at the landing site were in the range of 14 kts. That's not gale-force but it IS significant to a dynamic control system. The moon has nothing to do with this discussion.

[Burninate]

Root cause may have been identified:

@elonmusk Congratulations! How many engines are lit for landing? Can you differentially throttle for more degrees of control?

@ID_AA_Carmack Thanks! 3 of 9 engines are lit initially, dropping to 1 near ground. Even w 1 lit, it can't hover, so always land at high g

‏@ID_AA_Carmack Looks like the issue was stiction in the biprop throttle valve, resulting in control system phase lag. Should be easy to fix.

[llanitedave]

I take "should be easy to fix" as meaning they won't have to install Superdracos in the interstage.

[Lar]

Do you believe me now?

No, still too early to pat yourself on the back

I believe that you identified why windy landing is a problem, yes. And I'd happily give you one free kudo (20 kudos redeemable for a cup of coffee with me:) ) for it. Well done.  Jim doesn't give out praise as easily as I do though.

Does that transition to "and the way to solve the windy landing problem is with SuperDracos"? Nope.