Spacecraft Crashes Into Satellite
Juha-Matti Laurio writes "A robotic NASA spacecraft designed to rendezvous with an orbiting satellite instead crashed into its target. Unbeknownst to engineers at the time, DART's main sensor mistakenly believed it was flying away from the satellite when it was actually moving 5 feet per second toward it, investigators found."
From Challenger:
"Engineers at Morton Thiokol (manufacturer of the solid rocket boosters) knew that the temperatures were outside of the design range of the O-rings. They strongly objected to the launch, but were overruled by senior Thiokol management."
From Columbia:
"In a risk-management scenario similar to the Challenger disaster, NASA management failed to recognize the relevance of engineering concerns for safety. Two examples of this were failure to honor engineer requests for imaging to inspect possible damage, and failure to respond to engineer requests about status of astronaut inspection of the left wing."
From DART:
"Investigators also raised issues with the mission's management style, saying that lack of training and experience caused the DART design team to shun expert advice. They also found that internal checks and balances were inadequate in uncovering the mission's shortcomings."
As long as scientists and engineers are cogs in an organizational structure in which management tells them what to do, they will often produce crap, no matter how many PhDs there are in their midst. This is the case even when those managers were once brilliant technical engineers and scientists, because perceptions and priorities change when you switch into a management role.
This little episode was just another in a long line of screwups, and it won't be the last under current organizational models. Doing technical things can't be done properly unless insightful scientists and engineers are free of constraints on their insight, allowed to bypass the directional controls that management so loves, uninhibited from pointing our core problems in fear of their careers, and totally unshackled from the demands of time management.
Yes, I know that most managers would call this "anarchy", but therein lies the problem: by eliminating that alleged anarchy, you are also sacrificing the best that people can offer, just to make your life easier. Well, perhaps it's stating the blindingly obvious, but making management's life easy is not central to exploring the stars.
NASA's problem is the same one that permeates all technical industries, but in NASA's case the mishaps are just very public. I don't expect anything to change, but there is no doubting what the general problem is.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
This all happened on April 15 2005. A better write-up here: http://www.space.com/news/060516_dart_mishap_updat e.html. And here's the Wikipedia entry: http://en.wikipedia.org/wiki/DART_(spacecraft)
The satellite it crashed into was defunct. From Wikipedia: "The goal was to develop and demonstrate an automated navigation and rendezvous capability in a NASA spacecraft. Currently, only the Russian Space Agency and JAXA have autonomous space craft navigation.".
Interesting snippet: "NASA has said the official 70-page report will not be publicly released because it contains sensitive material protected by International Traffic in Arms Regulations (ITAR)".
This was planned as a "high-risk*, low-budget" mission and I'm sure they learned a lot. (* I suppose high-risk in terms of likelihood of meeting up with the target, not of collateral damage.)