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.
Quote from: CorvusCorax on 03/05/2019 06:56 pmThrusters 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.
Thrusters would also be triggered by altimeter + sink rate monitoring and only limit sink rate to a survivable level for the last few meters.
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.
Quote from: ulm_atms on 03/05/2019 09:07 pmI 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.
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.
Quote from: Lars-J on 03/05/2019 11:09 pmI'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.
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.
As someone who's also done a lot of coding, I think it would clearly introduce a bit of additional risk.
Quote from: Spindog on 03/06/2019 12:44 amAs 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.
Supposedly, Elon said they were going to have a manual release for the parachutes, but that was ages ago.