Author Topic: Should Crew Dragon have ability to use SuperDracos for landing emergency?  (Read 56785 times)

Offline punder

  • Full Member
  • ****
  • Posts: 1234
  • Liked: 1821
  • Likes Given: 1426
just a question: why would someone want to cut the chutes when emergency thrusters activate?

Assume, parachutes are deployed but entangled and didnt open. Capsule drops at 10m/s. Thrusters activate at 30m and slow descent to 5 m/s until water impact. No need to cut any chute wires before splashdown. We aren't talking precision landing here, just a reduction of sinkrate ( or freefall worst case)

There would not need to be any coordination between the systems. Parachute trigger by altitude, sinkrate, and maybe a timer for backup. They get detached by a splashdown detector ( probably with a delay to avoid triggering it by air turbulence )

Thrusters would also be triggered by altimeter + sink rate monitoring and only limit sink rate to a survivable level for the last few meters.

If some parachutes are still working, or partially working, perfect. Less work for the thrusters.

Ha, I never thought of that (alert the media).

Should add that I think the SD hail-Mary option is essential. It could be isolated from the rest of the control system, activated manually by the crew (big mechanical switches) or by the ground (thru a very secure encrypted channel) in case of crew incapacitation. But I can see the argument against.

An analogy is the ballistic parachute carried by some certificated and many light sport and homebuilt aircraft. Deploying the parachute in any case other than life-and-death last resort is really, really bad. So you can't activate the thing from the EFIS or by flipping a switch. You have to pull a big handle REALLY HARD (like, 40 lb of pull) to fire the rocket. And there are a lot of pilots who think the whole idea is wrongheaded.

Partially ninja'd by abaddon!
« Last Edit: 03/05/2019 07:22 pm by punder »

Offline ulm_atms

  • Rocket Junky
  • Full Member
  • ****
  • Posts: 915
  • To boldly go where no government has gone before.
  • Liked: 1535
  • Likes Given: 710
I don't even think it would need to be that complicated to trigger..basically what CorvusCorvax said.

1.  SD arm at 500m(GPS since no radar) if vertical speed is currently not survivable.
2.  When GPS says ~100m from sea level, AND speed still shows too fast to survive landing = activate SD to get vertical speed into survivable speed range before splashdown.

With this, it's only armed if the chutes have failed because the vertical speed should be survivable at 500m if they are working correctly.  I don't see an iffy realm here that may cause more issues or problems.

I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above.  There is also concern about making it more complicated....but everything is already there anyways minus a few lines of code.

Offline alang

  • Full Member
  • ****
  • Posts: 403
  • Liked: 213
  • Likes Given: 7
Thrusters would also be triggered by altimeter + sink rate monitoring and only limit sink rate to a survivable level for the last few meters.
...and manual activation.  Make absolutely sure it doesn't go off automatically in a borderline zone where it might increase risk relative to current risk.

Seems reasonable, but obviously this would require hardware to be added, procedures, training, etc.

If it's all automatic... that seems like you could be increasing risk in some scenarios, seems iffy.  It should be done right or not at all, I think.

Problem with software is that it is mostly hidden.
I've read that some few things are mathematically proven but I don't know if that is really true. Is a full authority digital engine controller (FADEC) mathematically proven?
Does NASA do quality assurance on the code?
Is it possible to upload patches?
My personal opinion is that luck will inevitably its part. What is worse, public condemnation if a propulsive landing attempt by mistake kills people or public condemnation because no attempt was made? The cynic in me suggests the latter will drive perceptions because people perversely value intentions (bizarrely believing that intentions are accessible) much more than they value competent action.

Offline Lars-J

  • Senior Member
  • *****
  • Posts: 6807
  • California
  • Liked: 8462
  • Likes Given: 5371
I don't even think it would need to be that complicated to trigger..basically what CorvusCorvax said.

1.  SD arm at 500m(GPS since no radar) if vertical speed is currently not survivable.
2.  When GPS says ~100m from sea level, AND speed still shows too fast to survive landing = activate SD to get vertical speed into survivable speed range before splashdown.

With this, it's only armed if the chutes have failed because the vertical speed should be survivable at 500m if they are working correctly.  I don't see an iffy realm here that may cause more issues or problems.

I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above.  There is also concern about making it more complicated....but everything is already there anyways minus a few lines of code.

If you can't see how it could go off at the wrong time, then you lack imagination. I'm a software engineer, and the systems I work with are rather complex, but this is complexity of a different aspect. And you are dealing with life or death here... Not just a 404 resource not found error if something goes wrong. Writing fool proof code for it would be a lot harder than it seems. Even if you assumed that all sensor data was correct. (which you cannot assume)

Your comment is the same as telling a hardware engineer that for a rocket to go to orbit you only need fuel, oxidizer, tank structure and a rocket engine. I don't see how it could fail.  :)

Offline alang

  • Full Member
  • ****
  • Posts: 403
  • Liked: 213
  • Likes Given: 7
I've heard developers ask support staff to provide reasons why code will fail rather than accepting that code will fail.
The idea that code will fail is met with blank incomprehension and hostility.
Not so much lack of imagination as lack of experience.
« Last Edit: 03/06/2019 04:18 am by Lar »

Offline ulm_atms

  • Rocket Junky
  • Full Member
  • ****
  • Posts: 915
  • To boldly go where no government has gone before.
  • Liked: 1535
  • Likes Given: 710
I don't even think it would need to be that complicated to trigger..basically what CorvusCorvax said.

1.  SD arm at 500m(GPS since no radar) if vertical speed is currently not survivable.
2.  When GPS says ~100m from sea level, AND speed still shows too fast to survive landing = activate SD to get vertical speed into survivable speed range before splashdown.

With this, it's only armed if the chutes have failed because the vertical speed should be survivable at 500m if they are working correctly.  I don't see an iffy realm here that may cause more issues or problems.

I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above.  There is also concern about making it more complicated....but everything is already there anyways minus a few lines of code.

If you can't see how it could go off at the wrong time, then you lack imagination. I'm a software engineer, and the systems I work with are rather complex, but this is complexity of a different aspect. And you are dealing with life or death here... Not just a 404 resource not found error if something goes wrong. Writing fool proof code for it would be a lot harder than it seems. Even if you assumed that all sensor data was correct. (which you cannot assume)

Your comment is the same as telling a hardware engineer that for a rocket to go to orbit you only need fuel, oxidizer, tank structure and a rocket engine. I don't see how it could fail.  :)

That is straw man argument.  And your snarky reply is not needed.

Of course ANYTHING can go wrong if you think hard enough and twist things enough.  A lot can end in "They are dead, doesn't matter"  Imagination does not a rational discussion make.

I was hoping for a discussion about what things you all might see come up with the above added logic to the landing sequence.  I spent many years programing data loggers with 100+ inputs with additional logic if certain inputs were there.  It wasn't life of death...but the code testing was extreme because to fix the code if an error was found was a royal pain.  Code also does fail in weird ways (had a logger that kept flipping a bit without warning[kept going back and forth so crc checks were good 99% of the time]...that was a pain as this specific logger did not have ecc..it got...um...retired quickly.)

I do assume that the sensors are wrong.....that's why they have redundant (triple in some cases) specifically in case of a faulty sensor.  I do however think the chances of all the GPS readings being so wrong(from all GPS receivers) as to not cause other problems on top of the slight chance that all the chutes fail is close to nill...not nill....close.  Murphy is always around the corner and no programming can get away from Murphy.

So I am going to ask again.  What other problems could those two steps added into the landing logic add that you all could see?  D2 would already be in a bad shape before it got to those lines of logic at that point as it would not have working chutes...

OFF-TOPIC

I am well aware that people know A LOT more about this subject and many other subjects of space flight/rocketry then a lot of us on this forum.  What I do not understand however, is the snarkyness on this forum to people that are just trying to discuss things.  Your last statement is a great example.  Examples of what you see failing, being done wrong, etc... is much more informative then what you wrote.  Your last line was just calling me stupid without using the word.

BACK ON-TOPIC

Offline Lars-J

  • Senior Member
  • *****
  • Posts: 6807
  • California
  • Liked: 8462
  • Likes Given: 5371
I'm sorry you feel insulted, but my gut reaction was that anyone who wrote "I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above" would not have software experience. I was wrong, but I still don't understand how you could write that.

You may think of my response as "snark", but I would classify your statement as dismissive oversimplification. You don't see how things can go wrong, but I see many ways.

But we are clearly not going to see eye to eye on this, so let's just agree to disagree.
« Last Edit: 03/06/2019 12:18 am by Lars-J »

Offline LouScheffer

  • Senior Member
  • *****
  • Posts: 3358
  • Liked: 6045
  • Likes Given: 822
I'm sorry you feel insulted, but my gut reaction was that anyone who wrote "I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above" would not have have software experience. I was wrong, but I still don't understand how you could write that.

You may think of my response as "snark", but I would classify your statement as dismissive oversimplification. You don't see how things can go wrong, but I see many ways.

But we are clearly not going to see eye to eye on this, so let's just agree to disagree.
The Russians lost a mission (Phobos 1) in exactly this way.  There was a routine that would cause disaster if called at the wrong time (it disabled attitude control).  It was needed during testing, and supposed to be removed before flight, since if somehow it *did* get called the mission would be lost.  But they ran out of time to reprogram the EPROMs containing the software (it was a planetary launch window) and decided to launch "as is".  The reasoning was that extra code couldn't possibly hurt if it was never called, right?   Then there was a typo in a subsequent upload, the routine *did* get called, and the mission was lost.   

Offline Chris Bergin

Reported to mod as a crap thread. I concur.

Seasoned members are setting a very bad example to new members when they post things like "you lack imagination" and "snarky response" and I honestly should just delete those posts as breach of forum rules, but I'm leaving them on just to cite the reason this thread was locked, which it will be if it doesn't improve.

I've said it a 100 times before, I will not allow this forum to go the same way as the other since-failed-because-of-weak-moderation forums out of fear of upsetting a few seasoned (and even L2) members. Think about your posts. Thousands of people read them (including this one that makes me come across as a miserable sod! ;D)
Support NSF via L2 -- Help improve NSF -- Site Rules/Feedback/Updates
**Not a L2 member? Whitelist this forum in your adblocker to support the site and ensure full functionality.**

Offline punder

  • Full Member
  • ****
  • Posts: 1234
  • Liked: 1821
  • Likes Given: 1426
I'm sorry you feel insulted, but my gut reaction was that anyone who wrote "I know there is concern about it going off at the wrong time but I can't see any way for that to happen with the above" would not have have software experience. I was wrong, but I still don't understand how you could write that.

You may think of my response as "snark", but I would classify your statement as dismissive oversimplification. You don't see how things can go wrong, but I see many ways.

But we are clearly not going to see eye to eye on this, so let's just agree to disagree.
The Russians lost a mission (Phobos 1) in exactly this way.  There was a routine that would cause disaster if called at the wrong time (it disabled attitude control).  It was needed during testing, and supposed to be removed before flight, since if somehow it *did* get called the mission would be lost.  But they ran out of time to reprogram the EPROMs containing the software (it was a planetary launch window) and decided to launch "as is".  The reasoning was that extra code couldn't possibly hurt if it was never called, right?   Then there was a typo in a subsequent upload, the routine *did* get called, and the mission was lost.

Good example. And practically every week there is a new story of how some supposedly hack-proof system got hacked. Other examples are unintended issues with self-driving vehicles, and airline crews being outwitted by the flight control system--sometimes with tragic results. I don't know anything about code, but I know control software is often so complex there's no way to know every possible way it can go wrong.

ulm_atms, don't sweat it too much. We've all got our "big red buttons" on this forum, and occasionally one gets pushed! Hilarity ensues!!   ;)

But don't listen to me... listen to Chris B!
« Last Edit: 03/06/2019 12:30 am by punder »

Offline Spindog

  • Full Member
  • *
  • Posts: 166
  • US
  • Liked: 220
  • Likes Given: 2
As someone who's also done a lot of coding, I think it would clearly introduce a bit of additional risk. How much would probably depend a lot on the overall structure of the control programs though I'd think it could be mitigated with certain sensor conditions and possibly manual control.

Overall it appears that we just don't know if this capability has already been programmed or not. Maybe we'll find out. In any case, in the incredibly unlikely event of a chute failure, I would surely hope that someone doesn't have to tell the crew that there's no way to activate the rockets to slow their fall or a survivable level.

Offline Spindog

  • Full Member
  • *
  • Posts: 166
  • US
  • Liked: 220
  • Likes Given: 2
And the more I think about it, the implementation really could require the ability to jettison the main chutes for the reason that the dragon hangs at an angle (unless that has been changed). If the trailing chutes cause the capsule too much drag to remain vertical while firing the super dracos that would be a complication. Or at least the SD's might have to force reorientation of the dragon one they created enough slack in the chute cords. But the question of whether there is an automated chute jettison system remains and could be another failure mode if so.

Offline lonestriker

  • Full Member
  • ****
  • Posts: 417
  • Houston We've Had A Problem
  • Liked: 820
  • Likes Given: 5155
I don't think there's much extra risk to "solve" here.  SpaceX already has a way to arm the Super Draco launch abort system after the astronauts board; so there must be an analogous safe mode that inhibits firing prior to arming.  The FTS system on F9 S1 can also be armed and safed through various portions of launch and return.  They are comfortable enough having regular Dracos as well as Super Dracos on a vehicle parked at the ISS, which frankly presents a much more real, tangible risk.

They will just build into their standard procedures when and where to safe and arm the SD thrusters.  Worst case, they don't re-arm them until there's a failure of the chutes during descent, otherwise they're inert.

Offline Negan

  • Full Member
  • ****
  • Posts: 717
  • Southwest
  • Liked: 207
  • Likes Given: 522
I don't think there's much extra risk to "solve" here.  SpaceX already has a way to arm the Super Draco launch abort system after the astronauts board; so there must be an analogous safe mode that inhibits firing prior to arming.  The FTS system on F9 S1 can also be armed and safed through various portions of launch and return.  They are comfortable enough having regular Dracos as well as Super Dracos on a vehicle parked at the ISS, which frankly presents a much more real, tangible risk.

They will just build into their standard procedures when and where to safe and arm the SD thrusters.  Worst case, they don't re-arm them until there's a failure of the chutes during descent, otherwise they're inert.

Maybe an umbilical plays a role in arming.

Offline su27k

  • Senior Member
  • *****
  • Posts: 6414
  • Liked: 9097
  • Likes Given: 885
Yeah, I don't see the software trigger as a big problem, they already have manual buttons that can cause disaster if triggered at the wrong time, for example cut main. It's pretty clear they have a good way to inhibit these when needed, this new emergency SuperDraco landing sequence trigger would be no different. A bit of work, but no showstopper.

The showstopper is they haven't tested SD landing sequence at all.

Offline gonucelar

  • Member
  • Posts: 20
  • Germany
  • Liked: 19
  • Likes Given: 1
As someone who's also done a lot of coding, I think it would clearly introduce a bit of additional risk.

The only question here is, is it possible to make the control code so foolproof that it could only be activated if a landing with a parachute becomes impossible.

In fact there is a good recent example of a rarely used control code saving the day. During the launch of a Cygnus spacecraft atop an Atlas V rocket, the first stage malfunctioned and the Centaur second stage had to compensate. This is obviously very different and more complex than pre-calculated burns used by the Russians and by the Ariane V. Yet it resulted in the spacecraft being delivered into a correct orbit despite the malfunction.

Offline Lars-J

  • Senior Member
  • *****
  • Posts: 6807
  • California
  • Liked: 8462
  • Likes Given: 5371
As someone who's also done a lot of coding, I think it would clearly introduce a bit of additional risk.

The only question here is, is it possible to make the control code so foolproof that it could only be activated if a landing with a parachute becomes impossible.

In fact there is a good recent example of a rarely used control code saving the day. During the launch of a Cygnus spacecraft atop an Atlas V rocket, the first stage malfunctioned and the Centaur second stage had to compensate. This is obviously very different and more complex than pre-calculated burns used by the Russians and by the Ariane V. Yet it resulted in the spacecraft being delivered into a correct orbit despite the malfunction.

That was not rarely used code that saved that day. That was Centaurs impressive adaptive software that compensated for a performance shortfall - from the beginning. (i.e. how can I most efficiently get from A to B with the available propellant) That - and the extra propellant margin - saved the day.

It was not a last-ditch code branch that someone put in there in case of a rainy day. It ran the code it always uses.

Offline spacenut

  • Senior Member
  • *****
  • Posts: 5180
  • East Alabama
  • Liked: 2587
  • Likes Given: 2895
How about a manual over ride to fire the Super Dracos if the parachutes do no open.  If pilot or commander can't see the parachutes, maybe he should have a window or camera to see.  He can see his altitude and see the parachutes and pull a lever or press a button to have them fire for soft landing.  Neil Armstrong took over manually when they landed on the moon and moved the LEM over a crater for a more level landing so they could take off later.  This could save their lives in case of a parachute entanglement.  I think this is a valid question and shouldn't be poo pooed. 

I just want to know if someone has thought of this, since Dracos were designed originally for soft landing on land of the Dragon capsule.  Soft landing on water doesn't matter.  Soft landing is what matters whether Dracos or parachutes.   Having Dracos as back up is a valid idea and should be explored.  Software programing can be done and tested.   

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 39245
  • Minnesota
  • Liked: 25171
  • Likes Given: 12102
Supposedly, Elon said they were going to have a manual release for the parachutes, but that was ages ago.
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Offline woods170

  • IRAS fan
  • Senior Member
  • *****
  • Posts: 12080
  • IRAS fan
  • The Netherlands
  • Liked: 18034
  • Likes Given: 12036
Supposedly, Elon said they were going to have a manual release for the parachutes, but that was ages ago.

The current instrument panel of Crew Dragon, specifically the pyros section, has a button to manually fire the pyros to deploy the drogue- and main parachutes.
« Last Edit: 03/06/2019 09:24 am by woods170 »

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1