Slashdot Mirror
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."
I know it is fashionable to highlight the usual NASA-related budget cuts but a quote from TFA This to me sounds like an underfunded team rushing to meet deadlines. Or were they just simply unlucky/inept?
If this were really happening, what would you think?
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
To summarize a satelite targeting robot called DART designed to intercept satelites, launched from Vandenberg Air Force base (un?)successfully knocket out the satelite it was targetting, and they wont release the investigative report because of international traffic in arms regulations. Hmm, sounds like a good result for the star wars weapons team.
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.)
But since it was a $110 million project anyway, couldn't the software have been tested in simulation first?
I understand the article says:
"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."
1. Is this just sloppy writing blaming a piece of hardware for a software problem?
2. If the sensor contained significant logic, would it have been that hard to test whether it correctly registered retreat and advancement?
3. Or an interface screwup between the main program and the sensor logic like confusing yards and meters? (And no test of the complete system?)
In any case it might well demonstrate the results when you shoot something up and see what happens without development adequate to the complexity.
Sort of true. The real issue is that the return on investment is: A) long-term and B) not easy to monopolize. Without the Apollo program, our computers might still be room-sized behemoths. Unfortunately, corporate America is not interested in any return on investment that is going to take more than a few quarters to be realized. And if the benefits of basic research also accrue to a companies' competitors, the company is unlikely to fund the research.
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
There are a lot of posts concerning NASA, management, the Military-Industrial complex. As someone who has watched the decay of spacecraft operations, I can confidently tell you that much of it has to do with contracting and paychecks.
Quick review: Spacecraft programs contain a number of stages, e.g. design, integration and test, launch, etc. The last stage is Operations. There used to be a day when all stages were properly funded and for Operations, this meant 24/7 console staffing, dynamic simulators, on-site engineers, spacecraft design manuals and lots of legitimate training.
But here's the problem. Prior to the mid 90s, NASA and other agencies used cost plus contracting, and the big contractors settled into a mode where the initial mission budget would be exhausted by about launch minus 1 or 2 years. This is when they would run back to the government organization and ask for more money and after some hand-wringing more money was allocated. Then all of a sudden - poof it's gone. Fixed cost contracting had arrived.
The problem, the big gorilla contractors only know one way to build a spacecraft and as no one likes to change, both contractors and NASA started coming up with inventive ways to defund Operation so they come in close to budget. Buzz-words like "automation" and "lights out operations" reduced console staffing to only the day shift. On-site engineers are never hired - instead "factory" design engineers are dug up IF there is a problem. Without on-site engineering, there's no need for good spacraft docs and simulators and no one to construct legitimate practice exercises. Combine this with upper management's desire to meet schedule, the already rounded corners are shaved even more.
Once formal Operations had evaporated, launch and early orbit was solely in the hands of design engineers, who are not Operations engineers. There's a different mindset between the two. There used to be a day when operation screw ups could be avoided and design flaws caught in advance through legitimate simulation, but that's gone now. Why? NO ONE PAYS FOR IT ANYMORE!
Sounds familiar alright. In The Naked Sun, one character suggests that a robot could be told to put something "harmless" into a drink, then another robot could be ordered to serve it to someone, unaware that it has been poisoned by the first, but I think there was a more complicated plot closer to what you're thinking.
Strange women lying in ponds distributing swords is no basis for a system of government.