4 ms·

I don't know if I agree. Aside from Challenger (I know -- a pretty big aside), what catastrophic launch failures were there with the Mercury, Gemini and Apollo

by reddog 10y ago

I don't know if I agree. Aside from Challenger (I know -- a pretty big aside), what catastrophic launch failures were there with the Mercury, Gemini and Apollo program rockets? Or the Delta 2. And doesn't the old-fashion-can't-even-land-on-a barge Atlas 5 have a perfect launch and mission success record of 62 of 62? It seems like building and launching a rocket that doesn't explode every 14th time is possible but its not cheap. The US has been doing it since the 60's. SpaceX may turn out to be OK for delivering Tang to the ISS, but let's let something else carry the Webb into orbit.

OrwellianChild 10y ago
The whole of rocketry has been fraught: https://en.wikipedia.org/wiki/List_of_spaceflight-related_accidents_and_incidents https://en.wikipedia.org/wiki/List_of_spaceflight-related_ac...
WalterBright 10y ago
The Mercury rockets had a lot of catastrophic failures before the first manned launch.
- reddog 10y ago
  Fair enough. According to Wikipedia of the 26 Mercury program missions there were 6 pre 1962 Mercury program launch failures before the 6 successful manned missions. 5 of the 6 failures were test flights without payload.
dredmorbius 10y ago
Apollo had 17 missions and at least four failures or near failures that come to mind: * The Apollo 1 launch-pad fire, during a training session, using a 100% pressurised oxygen atomosphere. Three dead. Grissom, White, and Chaffee. I can list them from memory. * Apollo 11 suffered a lunar lander computer crash in the final seconds before landing, was programmed to land on what would have been unsurvivable terrain, and had fewer than 30 seconds of fuel left when it finally touched down. * Apollo 12 was struck by lightning as it left the launch pad, knocking out much of the electrical system, which had to be reset. Fortunately they built things robustly. * Apollo 13 had an oxygen tank explode as it was en route to the moon. The mission was aborted, though orbital mechanics meant that the astronauts still had to orbit the Moon, then return to Earth. Any of 11, 12, or 13 could have ended with fatalities. One scenario for the command module pilot (Michael Collins in Apollo 11) was, if needs be, to leave his two crew members on the lunar surface and to return to Earth alone.
- engi_nerd 10y ago
  Eh, Apollo 11's difficulties were not a computer crash, but the computer throwing up repeated alarms saying "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped." AKA the 1202 program alarm. Which happened because the rendezvous radar was left in the AUTO mode for descent, when it was only meant to be used for ascent. https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html
  - garaetjjte 10y ago
    It wasn't "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped.", but "You are asking me to do to much, so I'm going to reboot". It also overcompensated throttle lag due to old documentation. http://www.doneyles.com/LM/Tales.html http://www.doneyles.com/LM/Tales.html
    - cwillu 10y ago
      Your reference confirms the parent's interpretation as well as yours: > During the braking phase, up to the time the landing radar locked onto the surface, the duty-cycle margin was over 15%. After the radar acquired, the extra computations involved in converting the body-referenced radar data to the navigation coordinate system lowered the margin to perhaps 13%. When a monitor display such as Verb 16 Noun 68 was added, the margin shrank again, to 10% or less. Buzz Aldrin was perceptive when he said after the second 1202 alarm, "It appears to come up when we have a 1668 up"[16]. > With a 10% margin and a 13% drain, the LGC simply did not have enough CPU time to perform all the functions that were required. Thanks to the flexibility of the Executive design — and quite unlike what would have happened with a boxcar structure — there was no collapse. [...] > Having a relatively low priority because of its size, SERVICER got last crack at the available computation time. With a negative time margin it was SERVICER that had not yet reached its conclusion when the next READACCS, running punctually, scheduled SERVICER again. Because it had not reached its end, the earlier SERVICER had not released its core set and VAC area — so the next time READACCS called FINDVAC to schedule SERVICER the Executive assigned a new core set and VAC area. That SERVICER also did not finish. After a short span of such operation the Executive exhausted its supply of core sets and/or VAC areas. When the next request was made the Executive, unable to comply, called BAILOUT with a 1201 or 1202 alarm code. [...] > The interesting effect of this train of events, during P63, was that the problem fixed itself. The software restart reconstructed only the most recent incarnation of the SERVICER job, and flushed the uncompleted SERVICER "stubs" that had accumulated. In addition, it terminated functions that had not been restart protected because they were not deemed critical — including the DELTAH monitor Verb 16 Noun 68. This is why, following the two alarms in P63, the display returned from Noun 68 to Noun 63. [...] > During P64 the situation was different. Added to the regular guidance equations was new processing that provided the capability to redesignate the landing site. With this addition, the essential software by itself left a duty-cycle margin of less than 10%. The alarms kept coming. There were three 1201 and 1202 alarms within 40 seconds. Each time, the software restart flushed the Executive queue but could not shed load. > At MET 102:43:08, forestalling the next alarm, Armstrong switched the autopilot from AUTO to ATT HOLD mode, easing the computational burden, and then entered semi-manual mode P66, where the burden was still lighter. After 2 minutes and 20 seconds spent maneuvering in P66 without alarms, the LM landed.

by reddog 10y ago

OrwellianChild 10y ago

The whole of rocketry has been fraught: https://en.wikipedia.org/wiki/List_of_spaceflight-related_accidents_and_incidents https://en.wikipedia.org/wiki/List_of_spaceflight-related_ac...

WalterBright 10y ago

The Mercury rockets had a lot of catastrophic failures before the first manned launch.

reddog 10y ago
Fair enough. According to Wikipedia of the 26 Mercury program missions there were 6 pre 1962 Mercury program launch failures before the 6 successful manned missions. 5 of the 6 failures were test flights without payload.

dredmorbius 10y ago

Apollo had 17 missions and at least four failures or near failures that come to mind: * The Apollo 1 launch-pad fire, during a training session, using a 100% pressurised oxygen atomosphere. Three dead. Grissom, White, and Chaffee. I can list them from memory. * Apollo 11 suffered a lunar lander computer crash in the final seconds before landing, was programmed to land on what would have been unsurvivable terrain, and had fewer than 30 seconds of fuel left when it finally touched down. * Apollo 12 was struck by lightning as it left the launch pad, knocking out much of the electrical system, which had to be reset. Fortunately they built things robustly. * Apollo 13 had an oxygen tank explode as it was en route to the moon. The mission was aborted, though orbital mechanics meant that the astronauts still had to orbit the Moon, then return to Earth. Any of 11, 12, or 13 could have ended with fatalities. One scenario for the command module pilot (Michael Collins in Apollo 11) was, if needs be, to leave his two crew members on the lunar surface and to return to Earth alone.

engi_nerd 10y ago
Eh, Apollo 11's difficulties were not a computer crash, but the computer throwing up repeated alarms saying "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped." AKA the 1202 program alarm. Which happened because the rendezvous radar was left in the AUTO mode for descent, when it was only meant to be used for ascent. https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html
- garaetjjte 10y ago
  It wasn't "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped.", but "You are asking me to do to much, so I'm going to reboot". It also overcompensated throttle lag due to old documentation. http://www.doneyles.com/LM/Tales.html http://www.doneyles.com/LM/Tales.html
  - cwillu 10y ago
    Your reference confirms the parent's interpretation as well as yours: > During the braking phase, up to the time the landing radar locked onto the surface, the duty-cycle margin was over 15%. After the radar acquired, the extra computations involved in converting the body-referenced radar data to the navigation coordinate system lowered the margin to perhaps 13%. When a monitor display such as Verb 16 Noun 68 was added, the margin shrank again, to 10% or less. Buzz Aldrin was perceptive when he said after the second 1202 alarm, "It appears to come up when we have a 1668 up"[16]. > With a 10% margin and a 13% drain, the LGC simply did not have enough CPU time to perform all the functions that were required. Thanks to the flexibility of the Executive design — and quite unlike what would have happened with a boxcar structure — there was no collapse. [...] > Having a relatively low priority because of its size, SERVICER got last crack at the available computation time. With a negative time margin it was SERVICER that had not yet reached its conclusion when the next READACCS, running punctually, scheduled SERVICER again. Because it had not reached its end, the earlier SERVICER had not released its core set and VAC area — so the next time READACCS called FINDVAC to schedule SERVICER the Executive assigned a new core set and VAC area. That SERVICER also did not finish. After a short span of such operation the Executive exhausted its supply of core sets and/or VAC areas. When the next request was made the Executive, unable to comply, called BAILOUT with a 1201 or 1202 alarm code. [...] > The interesting effect of this train of events, during P63, was that the problem fixed itself. The software restart reconstructed only the most recent incarnation of the SERVICER job, and flushed the uncompleted SERVICER "stubs" that had accumulated. In addition, it terminated functions that had not been restart protected because they were not deemed critical — including the DELTAH monitor Verb 16 Noun 68. This is why, following the two alarms in P63, the display returned from Noun 68 to Noun 63. [...] > During P64 the situation was different. Added to the regular guidance equations was new processing that provided the capability to redesignate the landing site. With this addition, the essential software by itself left a duty-cycle margin of less than 10%. The alarms kept coming. There were three 1201 and 1202 alarms within 40 seconds. Each time, the software restart flushed the Executive queue but could not shed load. > At MET 102:43:08, forestalling the next alarm, Armstrong switched the autopilot from AUTO to ATT HOLD mode, easing the computational burden, and then entered semi-manual mode P66, where the burden was still lighter. After 2 minutes and 20 seconds spent maneuvering in P66 without alarms, the LM landed.