SpaceX Falcon 9 v1.1 - SpX-6/CRS-6 DRAGON - Discussion Thread

[gommtu]

Just a reminder, no one predicted success, including Elon. They fully expected to encounter issues like this.

Forum commentators often seem more interested in validating their own facile armchair analysis than taking the company at its word.

[junk.munk82]

had some fun with the spacex feed:

[LouScheffer]

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

Source Tweet

This makes perfect sense.  In normal (ascent) operation, the valve makes few changes and those have large values (0-100% at startup, maybe down to 60% to limit acceleration at the end, then shutoff.   Plus maybe a dip at Max-Q, but I don't think SpaceX does that).  In these applications stiction is less likely since you are commanding a large change. So the valves have been nowhere near as extensively tested in the regime of small, fast, and frequent changes.

I really appreciate this transparent failure analysis.  I suspect the same happens during the traditional failure analysis, too - often they have an excellent idea, very early on, of what caused the problem.  I appreciate that you still need to complete the analysis, to look for other problems and to see if this is the only plausible explanation, but it's good to see intermediate results.  It gives a feel for the (likely) corrective measures much earlier.

[ugordan]

So the valves have been nowhere near as extensively tested in the regime of small, fast, and frequent changes.

It could have been extensively tested in McGregor, on an engine test stand.

[JamesH]

So the valves have been nowhere near as extensively tested in the regime of small, fast, and frequent changes.

It could have been extensively tested in McGregor, on an engine test stand.

It probably was. Was this a failure in flight, or something that was always there? I suspect the former.

[cuddihy]

Its not uncommon to see 30km/h wind shear from 1000ft to sea level. Given how fast the stage descents, the issue might be how quickly the stage can sense the wind. We routinely see 50km/h wind shear in my home town (southerly 10 kts @ 1000ft, northeast 20kts @ 50ft).
A means to upload wind estimates for sea level, 500ft, 1000ft, 1500ft to the stage right before launch might be very helpful, if the rocket could incorporate wind estimates into its lateral profile.
The rocket seemed to be compensating very aggressively towards dead center, perhaps its taking a wee bit too long to fully sense the wind.
Windy conditions are common both at sea and at the coast. This would be an enhancement that might pay off in land and sea scenarios (although sea typically have stronger winds).
Learn from aviation, every decent airport transmit fresh wind data to landing craft (ATIS, tower frequency, wind socks visually read).
But it could be that this is just a natural fine tuning as a consequence of prioritizing landing hard as close as possible to bulleye vs landing softly at the edge of the barge, and now that they accomplished it, they can balance the two goals.
Coming down a little slower would help if possible, but with T/W > 1 they might already be at the edge of how early they can slowdown.
Wind shear/gusts probably a much bigger problem than total wind strength @ sea level.

For fixed wind aircraft the issue is not wind shear but cross wind, ie, wind perpendicular to the direction of landing. This is so important for low-speed landing aircraft at sea, on an aircraft carrier for instance, that the ship actually determines its heading based on where the wind needs to flow across the deck at the correct angle & velocity. The officer of the deck for a carrier during flight ops is literally giving rudder orders while staring at an anemometer and wind direction indicator. The wind can be significantly different between the bow and the landing ramp, and it can change pretty fast, so it might actually be counterproductive to send wind data from deck level to the aircraft when it may be totally useless information until the last second or two--which is too late for even an automated system to adjust.
While carriers do have systems that transmit landing data to aircraft for better precision landing, it's pretty much positional information for the aircraft to get on the right glide slope. I think a returning F9 stage would be in a similar position -- the wind data you'd send up is not terribly useful until the point where it's almost too late. Better to tune the system response including throttle response until it's quick enough to stick the landing based on information it has onboard the rocket.

[speedevil]

While carriers do have systems that transmit landing data to aircraft for better precision landing, it's pretty much positional information for the aircraft to get on the right glide slope. I think a returning F9 stage would be in a similar position -- the wind data you'd send up is not terribly useful until the point where it's almost too late. Better to tune the system response including throttle response until it's quick enough to stick the landing based on information it has onboard the rocket.

A hundred quadcopters In a cone 200m or so in diameter, and 1km or so tall would allow most wind to be predicted 'live'.
These could likely even be resold for a profit.

[Remes]

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

Source Tweet

[...]I really appreciate this transparent failure analysis.

The tweet got deleted.

Anyway. I think the "normal" plan was to land with a rocket without any rotational movements (very much like the Grasshopper). But in the vine video the rocket has a clockwise rotation even at the beginning. Also it seems to me, that the tvc is pointing the plume to the right. So it was counteracting a previous rotational movement. Likely the rocket oscillated the whole way down.

Nevertheless it is quite impressive that the system found a solution to touch down vertically. Not good enough to survive, but given that there was some technical issue, still impressive.

In contrast to some comments: Hovering would have helped. Hovering helps to decouple different states. It could have allowed to zero out all rotational movements. It would allow to correct final deviations a meter or two above the surface and then land. It also gives more margin in general. We have a system, where the engine starts at e.g. 40m/s (downwards) and has to decelerate to e.g. 2m/s. Somewhere (e.g. 4m/s) is the limit of the system (landing legs able to compensate impact). The system must never come close to 0m/s as there is no way out (with a acceleration upwards the only thing to do is to switch of the engine). So effectively the final velocity setpoint is never 0 but something between 0 and the crash velocity. Taking away margin.

There are really a lot of constraints imposed on the system by not beeing able to hover. So many things have to work perfectly towards the final moments.

[Jim]

Testing on actual flights is the best way to go. There was considerable cross wind, aside from sticky valve weather variation is an issue that will need to be addressed.

This landing attempt was close enough to good that if they modify the surface with some kind of numerous rapidly deployed grappling mechanisms to secure legs and pull rocket into deck securely they could have less precise landings become successes.

I envision a landing pad at sea or on land with numerous such mechanisms to secure the base of the rocket as its landing. Otherwise the rocket is too tall, and the legs with to small a diameter to assure landing in a majority of landing weather conditions, even with the valve issue solved.

I hope SpaceX starts working at securing the rocket more rapidly immediately to ensure both an initial successes and a higher rate of subsequent successes.

That is just unnecessary complexity and not going to happen.

[Jim]

It would be nice if the Falcon9 had switchable power profiles for just the center engine.  Maybe switch over to a different fuel plumbing circuit prior to landing that would produce less power and a better possibility of hovering.

not feasible with existing engines or any engines.

[Razer]

We have a system, where the engine starts at e.g. 40m/s (downwards) and has to decelerate to e.g. 2m/s. Somewhere (e.g. 4m/s) is the limit of the system (landing legs able to compensate impact). The system must never come close to 0m/s as there is no way out (with a acceleration upwards the only thing to do is to switch of the engine). So effectively the final velocity setpoint is never 0 but something between 0 and the crash velocity. Taking away margin.

4m /s  it's just a value that you can imagine or it is a real value ?

[john smith 19]

There are really a lot of constraints imposed on the system by not beeing able to hover. So many things have to work perfectly towards the final moments.

True.

And all due to a valve failing to open when commanded to?

It seems the current Merlin 1d can't do deep enough throttling to cover (which surprised me).

Perhaps a Merlin 1e will be needed?

[Mader Levap]

I beleive SX will get there but it's been interesting to see how something that is conceptually simple, and which should be pretty well simulated has taken 4 landings and still not resulted in a complete stage ready for reuse or analysis. 
Baysian statistics would have to penalize your chances of #5 being successful. 

They are getting closer each time.

According to your logic (the more falied tries, the less chance that you will have success), no modern civilization could exist. Or my job (programming), for that matter.

That logic would be something resembling "correct" only if no fixes and/or changes was done between tries.

[aceshigh]

what amazes me, is that the part that was NOT tested (re-igniting the engine, decelerating from orbital speed to a few meters per second, atmospheric re-entry, finding a 100 meter barge in the middle of the ocean, going from orbit to that spot), all that IS WORKING.


it´s only the final precision stuff, small lateral motions, small changes in velocity (on the order of a few meters per second), etc, that are the problem right now. Which is something they had tested with Grasshopper and Falcon 9 itself in Texas.

layman logic would say that, having tested the landings in Texas, the difficult part was the untested part: finding the barge, restarting the engine, decelerating from orbit to a few meters per second and positioning the rocket over the barge. Once that was done, the theory is that it would be almost the same as they did in Texas...

[kevinof]

we don't know for sure it was a valve problem. There was a tweet about it which has since been deleted. Whether the tweet was accurate but was sent out when it shouldn't have been,or whether the tweet was incorrect we will only find out in time.

There are really a lot of constraints imposed on the system by not beeing able to hover. So many things have to work perfectly towards the final moments.

True.

And all due to a valve failing to open when commanded to?

It seems the current Merlin 1d can't do deep enough throttling to cover (which surprised me).

Perhaps a Merlin 1e will be needed?

[MostlyHarmless]

There's been a lot of discussion describing the valve stiction as a "failure" or a sticky valve.  Stiction is not the same as "sticking." 

"Stiction" or static friction is a feature of any system with moving parts.  Put a book on a level board, then slowly tilt the board.  At low angles, the book stays in place due to what's called static friction.  Once the tilt is enough to provide enough force to overcome the stiction, the book will slide down the ramp.

At some point before this, however, the book may still be stationary -- but if you give it a slight push, it will then accelerate down the ramp.  The slight push you gave it was enough to overcome the static friction holding the book in place -- once moving, it will continue to move.

Stiction will cause a delay in a system response.  You might expect the book to slide down the ramp when you tilt it past 20 degrees slope.  If the amount of stiction is underestimated, it might not slide until you get past 40 degrees.  Thus, you have a response delay that will be underestimated.  Same with the moving parts in a valve.    The same could happen if there was a mechanical problem that caused increased stiction, but we don't know that, yet.  Based on the tweet and the confidence expressed, I tend to think it was the former, since that would be a much easier fix (what could be a simple change of software parameters describing the response delay) than to determine an underlying cause of a unexpected valve stiction. 

[Jim]

finding the barge,

It doesn't "find" the barge.  It flies to a specific location on the ocean.  The barge just happens to be there.  That is why the barge has all the thrusters, to make sure it is at the same location.

[cscott]

I'm still open to bet on this... 5 years from now, if a SpaceX barge is in service, it will be able to broadcast live video. Want to take that bet?

I'll take that bet.  The curvature of the earth isn't going to change, and if the barge is still in service landings will be taking place *further* from ground stations, not closer.  So you're saying that in five years high-bandwidth video from the middle of the ocean will be stupid cheap.  Presumably because of SpaceX's new constellation?

It will happen eventually, but not within five years.

We might eventually get access to the same very slow frame rate video which SpaceX is watching in the control room, but I'm assuming that's not what you're taking about.

[LouScheffer]

Looking at the video (https://vine.co/v/euEpIVegiIx) I'm struck by the dramatic attitude changes. [...]

This seems weird to me as well.  You need attitude changes to do translation, but I'd think the algorithm would do the attitude changes first, while high up, until the rocket is directly over the barge with no angular velocity (just like the maneuver at the end, but higher up).  Then the remainder of the landing is straight down, maybe pointing the nose into the wind to stay on course.  At the last minute, rotate back to vertical.  A sticky throttle valve should not affect this overall behavior.

Instead, it looked like it realized, too low, that it was not in the right spot.   It tried to translate back, but this required large attitude changes, and could not be completed in time.  Now why was it in the wrong spot?  Maybe the wind had a bigger effect than anticipated? Maybe they null the rates at higher altitude, including the wind, but the surface winds are different?  At any rate it's hard to see this problem being caused by a sticky throttle, so I think there is at least one more control/algorithm problem.

[JamesH]

I'm still open to bet on this... 5 years from now, if a SpaceX barge is in service, it will be able to broadcast live video. Want to take that bet?

I'll take that bet.  The curvature of the earth isn't going to change, and if the barge is still in service landings will be taking place *further* from ground stations, not closer.  So you're saying that in five years high-bandwidth video from the middle of the ocean will be stupid cheap.  Presumably because of SpaceX's new constellation?

It will happen eventually, but not within five years.

We might eventually get access to the same very slow frame rate video which SpaceX is watching in the control room, but I'm assuming that's not what you're taking about.

Agreed. A satellite link for 10Mbits/s for half decent HD video would be required (H265 would give decent quality at 1080p at that bitrate). I don't know the numbers, but I assume that at the moment that is an expensive proposition, and not likely to change without a new constellation.