Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Spacecraft Crashes Into Satellite 343

Posted by samzenpus from the coming-or-going dept.
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."
This discussion has been archived. No new comments can be posted.

Spacecraft Crashes Into Satellite More

Spacecraft Crashes Into Satellite

Comments Filter:

  • Ah. (Score:5, Funny)

    by toQDuj ( 806112 ) on Thursday May 18, 2006 @05:02AM (#15355903) Homepage Journal
    So that's where the minus sign should have gone, I knew I dropped it somewhere!

    and an Obligatory Pratchett Quote:

    Hex's pen was scratching across the paper.
    Ponder glanced at the figures.
    ` ..., these figures can't be right!`
    Ridcully grinned again. `You mean either the whole world has gone wrong or your machine is wrong?`
    `Yes!`
    `Then I'd imagine the answer is pretty easy, wouldn't you?` said Ridcully.
    `Yes, it certainly is. Hex gets thoroughly tested every day` said Ponder Stibbons
    `Good point, that man,` Said Ridcully.

    B.

  • Question answered! (Score:5, Funny)

    by LackThereof ( 916566 ) on Thursday May 18, 2006 @05:03AM (#15355905)

    The $110 million DART mission was meant to test whether robots can perform some of the tasks astronauts currently must do.

    Well, we answered that question. Mission accomplished!

  • That's no crash... (Score:5, Funny)

    by calexontheroad66 ( 975611 ) on Thursday May 18, 2006 @05:03AM (#15355910)
    it's a successfull hit, now let's build that missile defense system.

  • DART (Score:3, Funny)

    by Shifty Jim ( 862102 ) on Thursday May 18, 2006 @05:03AM (#15355911) Homepage
    Well... Maybe they shouldn't have painted a giant bullseye on the side of the satellite.

    DART: 50 points
    NASA: -110 million dollars
    • If they wanted it to dock gently with the satellite, then they should have named it DOCKER instead of DART. That name had to flavor the entire development process.

  • Let me be the first to say.... (Score:3, Funny)

    by haeger ( 85819 ) on Thursday May 18, 2006 @05:04AM (#15355916)
    BWAHAHAHAHAHAHAHA!!!!

    No, but seriously, this is sad. It takes us farther away from what I'd like to see in a car, namely a self-steering one. I'd prefer one that detects an oncoming truck as oncoming and tries to get out of the way.

    .haeger

    • Re:Let me be the first to say.... (Score:2, Funny)

      by Anonymous Coward
      what I'd like to see in a car, namely a self-steering one
      They're called Taxis. Seriously, i'll be here all week.
    • It takes us farther away from what I'd like to see in a car, namely a self-steering one. I'd prefer one that detects an oncoming truck as oncoming and tries to get out of the way.

      Not at all. I can think of a few people I'd buy one for.

  • Oddly familiar (Score:5, Interesting)

    by Brushen ( 938011 ) on Thursday May 18, 2006 @05:04AM (#15355918)
    Where have I heard that before?

    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."

    • Re:Oddly familiar (Score:5, Insightful)

      by FTL ( 112112 ) <slashdot@neil.frase[ ]ame ['r.n' in gap]> on Thursday May 18, 2006 @05:17AM (#15355984) Homepage
      If an engineer makes a mistake, it's the job of the manager to have in place a system whereby the mistake is caught. Engineering failures which reach the light of day are also managment failures. Management failures are management failures. If something happens, no matter how it happened, it's always going to be a managment failure.

      So yes, you are right. It's always the manager's fault. By definition.

      • Re:Oddly familiar (Score:3, Insightful)

        by It'sYerMam ( 762418 )
        But what is the bigger cock-up: Deliberately ignoring the advice of your engineers, or not knowing that they themselves have cocked up? Surely the former - in the latter case, they have an excuse for not knowing.
      • Engineering failures which reach the light of day are also managment failures.

        I think I know what you meant, but the way you wrote that could be interpreted as, "Engineering failures which reach the light of day are also managment failures in the cover up". A better way to put it would be, "Engineering failures which aren't discovered and corrected are also managment failures.

        The reason that it is important to point out this difference is because we've already seen management cover up or sweep under the car
      • Tell that to Ken Lay
      • There's a fine difference between "Managment was incompetent" and "Management was actively screwing things up". For example, Challenger and Colombia are clear-cut examples of the latter. DART, based on the grand-parent's description, seems like it was the former. Yes, they were incompetent, but they weren't knowingly bypassing safety checks - they just didn't know they were there in the first place.

    • Re:Oddly familiar (Score:3, Insightful)

      by massivefoot ( 922746 )
      Management -never- seem to know what the hell they're doing. Companies seem to make the constant mistake of believing that you can manage something you know nothing about. Take the following example. I know a guy who used to work in computing and electrical engineering, in around the 60s, 70s, so pretty primitive stuff. Apparently at the time it was common to approximate integrals electronically by building up a charge on a capacitor over some time, representing the range of the integral, with the curre
      • I would hope that most of the layers of management at NASA had taken calculus in college.

        I think that the mistakes that typically get made (and not corrected) at NASA are due to upper management and political pressure, both internal and external. To people at that level, political realities seem to take precedence over physical reality.

        NASA engineers aren't stupid. They're the best of the best.
      • That's Anglo-Saxon capitalism for you. The theory - at least if you can dignify it with the word - is that a manager just manages widgets (yes, that's you). By the time information gets to their level, it's abstract enough not to require domain expertise. New Scientist did an article years ago saying that engineers were more successful at running companies in their domain.
    • It really bothers me to hear this, as an engineer. I hate listening to the media about stuff like this, because they have absolutely no knowledge of engineering methods, and they don't seem care.

      Anyway, on a big scary program, here's how these sorts of problems are spotted :

      1. Mid or low-level engineers spot potential problems
      2. They then tell engineering leadership that they are worried about a particular problem.
      3. Engineering leadership and/or management then (either informally or through a process called

  • First application (Score:5, Funny)

    by RM6f9 ( 825298 ) <rwmurker@yahoo.com> on Thursday May 18, 2006 @05:04AM (#15355926) Homepage Journal
    Not hampered by engineering degree, can tell difference between "toward" and "away from" - will work for same 6 figure salary previous position holder was receiving...

  • ABC News is never the best choice (Score:5, Informative)

    by caryw ( 131578 ) <.carywiedemann. .at. .gmail.com.> on Thursday May 18, 2006 @05:08AM (#15355938) Homepage
    Offical NASA writeup available here: http://patriot.net/~cary/slashdot/dart_mishap.html [patriot.net]

    Made from original PDF available here: http://www.nasa.gov/pdf/148072main_DART_mishap_ove rview.pdf [nasa.gov]

    (I hate PDF's for simple text things like this)

    --
    NoFluffNews.com - Currently in development but seeking journalists and editors [nofluffnews.com]

  • Kennedy Space Center DART? (Score:5, Funny)

    by dotslashdot ( 694478 ) on Thursday May 18, 2006 @05:13AM (#15355963)
    In a subsequent news conference, DART claimed it did not remember hitting on the target after being spaced out on AMBIEN, a method it used to help it sleep(500s) before its launch from Kennedy Space Center. DART claimed that it got several bytes to eat before drinking a cup of Java and collecting its garbage. Upon introspection DART agreed that, despite its name, hitting on the target showed little Class despite the size of its Package.

  • In a related story... (Score:5, Funny)

    by dummyname12 ( 886454 ) on Thursday May 18, 2006 @05:14AM (#15355971)
    ...NASA has finally set aside a portion of its budget for the hiring of a trombone player to lighten the mood after each disasterous miscalculation with a well-timed "waaah WAAAAAAAAH."
    • At least someone playing the trombone should be familiar with the concepts "towards" and "away from"
    • ...NASA has finally set aside a portion of its budget for the hiring of a trombone player to lighten the mood after each disasterous miscalculation with a well-timed "waaah WAAAAAAAAH."

      Close, they just need to open source their code. As in this case:

      --- nav.c 2005-04-20 04:20:00.000000000 -0400
      +++ nav_new.c 2006-05-18 03:00:11.000000000 -0400
      @@ -403,7 +403,7 @@

      -if (!moving_towards_satellite) {
      +if (moving_towards_satellite) {
      move_away();
      }

      Simple logic error
  • I support NASA, but they have had a run of stupid mistakes lately. For example the whole meters to feet conversion problem. Yes everyone makes mistakes, I know, but NASA is supposed to be the best and the brightest. You would think that when dealing with such expensive equiptment they woulod check and re-check, and even methemtically prove the correctness of their programs. Sloppy programming from me or you on some spreadsheet app is bad, but not unexpected, but I have higher standards for NASA.

  • Could this be due to? (Score:4, Interesting)

    by Don_dumb ( 927108 ) on Thursday May 18, 2006 @05:16AM (#15355979)
    Budget and time constraints?
    I know it is fashionable to highlight the usual NASA-related budget cuts but a quote from TFA
    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"
    This to me sounds like an underfunded team rushing to meet deadlines. Or were they just simply unlucky/inept?
    • Give this [patriot.net] a read. It doesn't say much about budget constraints, but it does point to a lack of testing on last minute changes due to the pressure to meet the launch date. Also, I think that reading between the lines a bit would indicate that there was a definite ept shortage on the team.

  • Where's that ruler? (Score:5, Funny)

    by Whiteox ( 919863 ) on Thursday May 18, 2006 @05:19AM (#15355990) Journal
    Are you sure? Is that 5 feet per second or 5 metres per second?
  • Queue the obligatory unit conversion jokes.

    Being an ignorant Imperialist on this subject, I have to ask: are SI units in the opposite direction? I mean, when you convert from feet to meters, does it switch directions?

    Or does, like, SI seconds = negative Imperial seconds?
    • 10 feet =~ 3 meters
      No signs changing or anything. Unless you happen to work at the magical kingdom of NASA ofcourse.
    • From the MIB report [patriot.net]:

      In summary, the persistent, inaccurate, navigational information that caused DART's premature retirement resulted from a combination of: 1) an initial, unacceptable, calculated difference between DART's estimated and measured position that triggered a software reset; 2) the introduction of an uncorrected, erroneous velocity measurement into the calculation scheme; 3) a navigational software design that was overly-sensitive to erroneous data; and 4) the use of incorrect gain control in th

  • DART Seeks its Target
    NASA launches a DART to target an orbiting bull's-eye.

    Given the objective, I don't see the problem here. Way to go, guys!
  • That after having pushed the orbiting satellite at 5 feet per second,
    investigators found [somethingawful.com] that the robotic shover space probe is heading toward earth to protect your grandmother from the Terrible Secret of Space [wikipedia.org].
    Last message recieved from the robotic space probe was :
    " Please go stand by the stairs, so I can protect you... [kilna.com] "

  • mistaken beliefs of velocity (Score:3, Funny)

    by MisterLawyer ( 770687 ) <mikelawyer AT gmail DOT com> on Thursday May 18, 2006 @05:33AM (#15356051)
    "...mistakenly believed it was flying away from the satellite when it was actually moving 5 feet per second toward it, investigators found."

    Same thing happened to me and the garage door when I was 14 years old backing my dad's Buick out of the driveway.

    He didn't let me drive it again until I was 18.

  • NASA: Get rid of design by management (Score:5, Interesting)

    by Morgaine ( 4316 ) on Thursday May 18, 2006 @05:34AM (#15356059)
    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.
    • With no structure, they would never convince congress to give them any money. It's good when unstructured research happens, but structured, result-oriented research is always going to be ablt to get more funding.

      NASA is clearly poorly managed, but it seems to me that the solution is good management, not no management at all. Of course, I have no idea how to actually implement good management.
    • 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.

      Right, because management by committee and fistfight works so much better. We're not talking about one-man research projects, here. We're talking about things that cost hundreds of
    • I disagree categorically with the perception that leaving technical people unfettered by management or time pressure will result in better designs, products or concepts. After RTFA, one notes that one reason provided for the failure is that the teams disregarded expert input - a characteristic that I have witnessed time and again within groups of bright technical people. Call it an adjunct of NIH - not invented here.

      Another example is the cowboy coder, writing without specifications or testing. For some
  • Oh - it's meant to be less than zero.


  • We've got a history established where people taught -> new math -> students who taught -> new math -> students -> ... -> current engineers and we're seeing plenty of problems with meters|feet, up|down, left|right, top|bottom (whilst we're at it, let's just interchange all of the quark properties) with some very expensive toy$. This likely includes plenty of [relatively] smaller pricetag$ (yet still bad enough - on a scale of "defense contractor bad"). Ye, NA$A still wants us to throw m
  • "A robotic NASA spacecraft designed to rendezvous with an orbiting satellite instead crashed into its target."

    NASA was able to extract the satellite that was deeply embedded into the ship's hull using the M.A.N.O.S. manipulator system. The extraction appeared successful until the M.A.N.O.S. manipulators let the satellite go free. In a Bugs Bunny'esque fashion, the satellite hovered for a moment before it suddenly plummeted into the Earth's atmosphere. NASA wouldn't reveal any details about which satelli

  • Top Down Design? (Score:5, Insightful)

    by Ohreally_factor ( 593551 ) on Thursday May 18, 2006 @05:44AM (#15356090) Journal
    One wonders if this failure is due to a design philosophy similar to the top down design [fotuva.org] that has doomed the shuttle.

    From the Feynman report:

    The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), and tests are begun in experimental rigs to determine those. With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood. There is a very good chance that the modifications to the engine to get around the final difficulties are not very hard to make, for most of the serious problems have already been discovered and dealt with in the earlier, less expensive, stages of the process.

    The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes. For example, cracks have been found in the turbine blades of the high pressure oxygen turbopump. Are they caused by flaws in the material, the effect of the oxygen atmosphere on the properties of the material, the thermal stresses of startup or shutdown, the vibration and stresses of steady running, or mainly at some resonance at certain speeds, etc.? How long can we run from crack initiation to crack failure, and how does this depend on power level? Using the completed engine as a test bed to resolve such questions is extremely expensive. One does not wish to lose an entire engine in order to find out where and how failure occurs. Yet, an accurate knowledge of this information is essential to acquire a confidence in the engine reliability in use. Without detailed understanding, confidence can not be attained.

    A further disadvantage of the top-down method is that, if an understanding of a fault is obtained, a simple fix, such as a new shape for the turbine housing, may be impossible to implement without a redesign of the entire engine.
    • Isn't Feynman a physicist and not an engineer? His argument seems to have a lot of handwaving and no actual direct connections between his claims and how they will achieve results. Top-down or bottom-up design are both over-simplifications and will both result in difficulties. Top-down really boils down to looking at the whole of a system, and bottom-up really means looking at its parts. As the nature of human perception and thus reality is dualistic, both the whole and its parts must be considered in d
  • ... that the project name for the orbiting satellite was Balanced Orbit Autonomous Rondezvous Drone.

  • More info... (Score:5, Interesting)

    by jginspace ( 678908 ) <.jginspace. .at. .yahoo.com.> on Thursday May 18, 2006 @05:54AM (#15356127) Homepage Journal

    This all happened on April 15 2005. A better write-up here: http://www.space.com/news/060516_dart_mishap_updat e.html [space.com]. And here's the Wikipedia entry: http://en.wikipedia.org/wiki/DART_(spacecraft) [wikipedia.org]

    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.)

  • Citing security concerns [space.com], the full 70 page accident report was not released. But even the censored 10-page summary [space.com] is pretty damning. Complete public report is here:
    http://www.spaceref.com/news/viewsr.html?pid=20605 [spaceref.com]

    Some gems:

    ...examination of raw test data and performance of independent tests of some flight components by the government insight team were defined by NASA project management to be "out-of-scope."
    ...
    In DART's case, the lack of adequate risk management contributed to a zero- fault tole

  • "The inaccurate perception of its distance and speed ... prevented DART from taking effective action to avoid a collision," the summary said.

    Next time, DUCK!!!1!

  • Shines so much I'm blinded... (Score:3, Interesting)

    by scdeimos ( 632778 ) on Thursday May 18, 2006 @06:43AM (#15356241)
    My favourite quote is from NASA's NASA "Darts" Into Space [nasa.gov] [RealMedia video, sorry] video on the DART mission home page:
    DART is NASA's shining example of technology that will move the Agency towards safer, more reliable and affordable access to space.
    It could well have done that, if only it had worked.
  • Glad to see the Hekawi tribe has entered the space age.

  • Well, it is rocket science (Score:3, Interesting)

    by smchris ( 464899 ) on Thursday May 18, 2006 @07:17AM (#15356329)
    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.

  • The report was just released, how long ago did the crash occur? Also, think we could use this technique to get the ISS back into a higher orbit?
  • Ack, i can only say that my experience with robotics tells me that it's hopeless to trust just one sensor, when dealing with a robot.
    I far too well remember spending countless of hours before realizing, that when i got too close, or too far away, the sensor would start reporting its result wrongly; it couldn't tell the difference between 2 cm, 30 cm, and 4 m. creating a function to help it realize what it had done, based on previous measurements helped, but was still a bad solution. getting extra sensors, t

  • A day late and a dollar short (Score:3, Insightful)

    by smooth wombat ( 796938 ) on Thursday May 18, 2006 @07:54AM (#15356453) Journal
    As usual, just a bit behind the times. [slashdot.org]

    And yes, I had the box checked so it would be considered for posting.

    It's a curse being ahead of the curve.


  • More like nudged.

    5 (feet per second) = 3.4 miles per hour
  • From http://patriot.net/~cary/slashdot/dart_mishap.html [patriot.net]:

    In DART's case, the MIB determined that the first cause for its premature retirement occurred when the estimated and measured positions differed to such a degree that the software executed a computational "reset." By design, this reset caused DART to discard its estimated position and speed and restart those estimates using measurements from the primary GPS receiver.

    Careful examination of the software code revealed that upon reset, the velocity m

  • Anybody else notice that it was only moving 3.4mph (5.5km/h).
    That doesn't sound very fast to me.
    I'll admit I don't know how space craft are built,
    but I wouldn't think that would do terrible damage.
    Or am I missing something?

    • Re:Solidly Built? (Score:3, Insightful)

      by davidc ( 91400 )
      Damage depends on the speed *and mass* of the robot, doesn't it?

      Try driving your car into a fire hydrant at 3.4 mph and see what that does to the bumper...

  • Another Classic Spacecraft Operations Screw-up (Score:3, Interesting)

    by starfire-1 ( 159960 ) on Thursday May 18, 2006 @08:49AM (#15356641)
    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!
  • Pity the story didn't come out yesterday:

    http://www.dilbert.com/comics/dilbert/archive/dilb ert-20060517.html [dilbert.com]

  • Bullseye! (Score:3, Insightful)

    by dtfinch ( 661405 ) * on Thursday May 18, 2006 @10:09AM (#15357100) Journal
    It has lived up to its name, DART.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close