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

[JamesH]

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

I don't believe the tests in Texas would have had much influence here. Until they start testing decent at the rates experienced from a real launch, from pretty high up, then the tests to now  are fairly tangential.

[fthomassy]

A sticky throttle valve should not affect this overall behavior.

Why you would think that?  Did you see the thrust vectoring?  That behavior could be directly related.
Edit: Hedging with "could be"

[Remes]

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

Only an example, no real value.

The attached picture shows a grasshopper landing. Vertical line is the travelled distance of one leg in 73 frames. Horizontal line is the stage diameter with 3,6m. This gives me a velocity of about 7.5m/s. But grasshopper is not falcon 9 first stage. Less engines, etc.

[cscott]

Seems reasonable to me that some minor station-keeping maneuvering while low to the ground might have caused an unexpectedly large attitude deviation (which then wasn't correctable in time) if there was some throttle delay at an inopportune time.  That is, the problem isn't that they were far off-target and then needed to make a large correction, the problem is that their normal small correction unexpectedly pushed the stage over, and then they couldn't recover in time.

And when a CEO says "easy to fix" you know the actual engineers on the ground are in for a tough two months of work.  "Looks easy to a CEO" is not the same as "easy".  It just means "well-understood".

I'm also of the opinion that the stiction was probably caused by some feature unique to the reentry profile: four engine cycles with periods of vacuum, some pretty aggressive thermal cycling, and probably unusual vibration during no-thrust periods as well.  Perhaps some ice formed on part of the valve body.  Or perhaps the vacuum conditions meant that ice *didn't* form, and the ice usually insulated some part of the valve. Those are the sorts of things that are hard to predict from ground testing.

Of course it's also possible it's an oversight, since stiction is harmless at any point over than 100' above the barge.  Stiction might have been noticed, bounded, checked for ill effects, and then dismissed previously.

I will say that the sluggish liftoff is almost certainly *not* related.  Falcon has always been slow to lift off, as are all liquid-fueled rockets in general.  That's normal.

[rst]

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.

Well, to some extent.  The Grasshopper tests did involve tilts for horizontal divert maneuvers, but at least the ones I saw all involved pretty slow attitude changes.  The CRS-6 stage came in with tilt changing a whole lot faster than that, which would make control system lag a lot more of a problem -- and oscillations in tilt are one kind of problem which is likely to develop in this sort of situation.

[JasonAW3]

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.

I'm just suprised that Quadcopters and other drone types haven't been used more for stormchasing and hurricane monitoring.  While signal degradation can occure due to electrical interference in storms like that, as sufficently broadband and multiplexed two way signal should assure both data retreival as well as positive command and control of said craft.  Ther would, of course, have to be a good deal of local autonimy for Quadcopters in storms like these, so it can vary rotor speeds and maneuvering to maximize platform stability to gather accurate and usable data and video.

The same can be applied in this case, and may be applicable to the landing of teh stage itself, so long as the onboard systems are getting sufficent information on airspeeds and directions, platform direction and elevations, etc.  Even in a light seastate, there is still some movement and shifting of the target platform that could have been a factor in the lateral velocity issue.

[Jim]

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.

and would provide useless information

[LouScheffer]

A sticky throttle valve should not affect this overall behavior.

Why you would think that?  Did you see the thrust vectoring?  That behavior could be directly related.
Edit: Hedging with "could be"

Because even with a sticky throttle, you have plenty of time and control authority to adjust the course to hit the center of the barge, and to null angular rates.  That whole process took about 3 seconds in the video, though it was not quite completed in time.  But 30 seconds is way more time than you need to do this, at any throttle setting.  And once on course, the wind should not be enough to throw you off.  Say Falcon is 30m high, 3.66 m in diameter, wind 10 m/s (more than reported), Cd = 1, then the side force is 11,000 N.  The engine, even throttled down, has a force of 500,000 N or so, so a 1 or 2 degree deflection of the engine (much smaller than seen on the video) should be more than enough to compensate for wind and keep it on course, again at any throttle setting.

So what I can't see is a sticky throttle causing the need for a last minute course correction.  A straight down descent smashing into the barge too hard, or the rocket coming to a stop too high and starting to climb, these could be caused by a sticky throttle.  But the wild, last-second maneuvers must have been caused by some other problem.

[macpacheco]

I don't think SpaceX will increase the barge bandwidth until they have their own constellation.
They could download the video slower afterwards remotely. Even a 256 or 512kbps uplink is enough to get a 1080p very short video in the order of 10 minutes (like a 1 minute video).
Having online streaming isn't for SpaceX proper, but rather for marketing. SpaceX can post the video an hour later without extra costs.

[hrissan]

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

Biprop valve... Could some kerosene be frozen by the LOX changing the friction? Or may be just contamination or manufacturing defect.

The rocket oscilation pattern looks classic. Here is probably how it develops:

Computer gimbals engine left (tvc does it immediately) and throttles up a bit to compensate for cosinus losses, but the valve does not move because of increased static friction, after some delay the computer senses that thrust is not enough, so it commands to throttle up more, this repeats several times until control force overcomes friction, the valve suddenly moves increasing thrust a lot, with the engine still gimballed, which moves the bottom of the stage too far right.

The cycle continues.

[ThereIWas3]

I'm just suprised that Quadcopters and other drone types haven't been used more for stormchasing and hurricane monitoring.

Quadcopters are pretty useless in any kind of wind.  They would just get blown away like leaves.  Unless you are talking about a quadcopter about the size of, well, a full size helicopter.  And even those stay away from hurricanes.

[DatUser14]

might the landing have looked something like 13:43 or 14:10 in this video?

[Senex]

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

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.

Lou's right.

Flying in to Grande Prairie, Alberta back in 1980, in a 737, I was back in the cabin reading as we broke through the low clouds to land.  I looked out to the left to see the runway not under us, but beside us.  I thought "no big deal," the pilot will just go around.  Instead, he banked hard left and then right, trying to line up on the the runway.  I didn't breathe the whole time — it's while trying to save a landing that has already gone bad that very bad things happen.  In the end he, fortunately, accepted the inevitable and aborted the landing. 

There is an adage in flying that a good landing is the result of a good approach — you are where you should be, at the right altitude, at the right speed.  The Falcon's landing had already gone bad pretty much by the start of what we see in the Vine.  Only extraordinary measures might have saved it.  And in this case, they didn't.

[Xentry]

First of all let me congratulate the astonishing job SpaceX have done with both their sequence of successful Falcon 9 and Dragon missions, as well as express my greatest respect for all the effort spent so far on trying to get an F9 back to Earth.

Having said this, and from all the information I've been able to get, I am intrigued by a few things... Namely:

1. From the last two Vine videos shown, the horizontal corrections close to landing are pretty dramatic, while the vertical motion seems to be pretty much under control. Looks like the problems they still have are definitely related to the latter. So are they a result of having an excessively large initial horizontal dispersion at the start of the final burn? Are they a result of the onboard computer not "seeing" the lateral wind until late in the game since they are descending crazily fast until the very end? Is the position control being too demanding on the actuators (are they too slow?)? Is the whole Guidance and Control system close to the limitations of sensors, algorithm, actuators and onboard computer?

2. How demanding must the position control actually be, and what would happen if they simply stopped trying to hit a specific X-Y-Z position + X-Y-Z velocity state, and just went for a zero height and velocity vector instead, no matter the X-Y position, once they're sure to land within a few 100 feet of the target? Wouldn't such a solution be easier to achieve, as well as more applicable to the case at CCAFS where they will have much larger pads to land on?

3. SpaceX is now very very close to landing an F9, but might have to try a few more times before getting it right, which might take several months more. Since most of the technical hurdles to recover their rocket have been overcome, and the next part of the job - which surely involves thoroughly inspecting each part of a recovered vehicle to know what needs to be refurnished/redesigned to allow full reusability - may take quite some time to to complete, is there a case for making a special effort right now to somehow grab the vehicle once it gets to the barge "no matter what", even knowing this would be a transitory measure?

I guess these are mostly rhetorical questions, but still... as an aerospace engineer involved in Guidance and Control systems for planetary EDL missions, would sure love to know more about them...

[rcoppola]

IMO:

Looking at the video, if it was stiction of some kind, (noting that the tweet has since been deleted), just around the 2 second mark is where it would appear to have caused the overcompensation at the end of the return profile. If you look at the stable return path as it initially enters into the frame and then imagine that 1 second valve stiction issue did not happen, you can see that it would have nailed it. At least, that's what I see in the minds eye. It would have been one of those initially angled hover-slams we have now seen many times but instead went too far over, drastically compensated, causing serious lateral motion with no more room (ie. time/height, etc.) to correct and slid right off.

[fthomassy]

A sticky throttle valve should not affect this overall behavior.

Why you would think that?  Did you see the thrust vectoring?  That behavior could be directly related.
Edit: Hedging with "could be"

Because even with a sticky throttle, you have plenty of time and control authority to adjust the course to hit the center of the barge, and to null angular rates.   

... sniped the remainder ...
Not if the sticky issue disrupts your control feedback.

[Jcc]

@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 am wondering how Carmack made this determination. Was he given the data by SpaceX engineers, or is it based on his own experience at Armadillo with a totally different rocket?

I can see why Musk respects Carmack, but I can't see how you can say it was a stuck valve by just looking at a few images and then the Vine clip. So, it is a SWAG, or else he is being given data that was not publicly released.

[Jim]

I am wondering how Carmack made this determination. Was he given the data by SpaceX engineers, or is it based on his own experience at Armadillo with a totally different rocket?

I can see why Musk respects Carmack, but I can't see how you can say it was a stuck valve by just looking at a few images and then the Vine clip. So, it is a SWAG, or else he is being given data that was not publicly released.

The tweet is from Musk to Carmack

[Jcc]

I am wondering how Carmack made this determination. Was he given the data by SpaceX engineers, or is it based on his own experience at Armadillo with a totally different rocket?

I can see why Musk respects Carmack, but I can't see how you can say it was a stuck valve by just looking at a few images and then the Vine clip. So, it is a SWAG, or else he is being given data that was not publicly released.

The tweet is from Musk to Carmack

D'oh!

[llanitedave]

More complicated than that. You'd need to compare telemetry/tracking with sims.

Depends on where/when the deviation occurred. Remember that the stage bends - can act like a whip if you apply too much force at the wrong time. So even considerable increase isn't an instant answer.

Once you find where the issue is (by matching a sim to actual), you rerun the sims with increased thrust til it begins to work, then you exhaustively simulate variations to prove you've adequately bounded the situation. Tedious.

And that's the interesting question about this.

SX, like all major players, design their LV's and spacecraft in CAD systems. In principle a design should be available for input to dynamics simulation models almost from the day it's frozen. Modern computer time is cheap so they would have been able to lots of sims of this process and their models should have been high fidelity.

So what was missed this time?

I've just looked at the cleaned up footage and wow does that puppy waggle.

Either I'm recalling only stills from previous landing movies or this was really flapping about, like a failed launch from the 1950's 

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. 

Baysian statistics only applies when you are not iteratively applying new data and analysis to each increment.  Not the case here.