🚀 go-pugleaf

In article <HAGERMAN.93Jan11230044@rx7.ece.cmu.edu> hagerman@ece.cmu.edu (John Hagerman) writes:
>[I don't speak for the Erebus project; the following are my opinions.]
>The Erebus project was not intended to explore reliability, so few
>conclusions about reliability should be drawn from it.  That Dante
>failed at a single point of failure should not be surprising, given
>that a fault-tolerant design was not a goal.  Goals must be limited in
>every experimental situation.  The main goal of the Erebus was to test
>robotic technologies in a real environment; reliability was not a big
>concern since people would be there, and so reliability did not need
>to be included as a major goal of the project.

It's fair enough to say that fault tolerant design was not a goal of the
design, but surely the system should be fault tolerant enough to
acomplish the design goals.  By saying "people would be there" is surely
a catch-all phrase - if system X did not work, then it's OK since people
would be there to replace it.  This could cover all possibilities - it's
OK that the legs didn't work, people were there to carry it....

>gat@forsight2.jpl.nasa.gov (Erann Gat) writes:
>>
>>That using multiple small robots increases realiability is not a "naive
>>assumption", it is a theoretically and empirically verifiable fact.  It
>>does not matter whether failure modes are independent.  Unless there is
>>100% correlation among failures in multiple units (which is never the case)
>>having more units will increase the overall system reliability.
>
>This is a simplistic statement, which would lead to a hot debate if
>made in comp.risks (where it would be phrased "Four engine airplanes
>are obviously safer than two engine airplanes, so why aren't there
>more of them?").  Two factors this statement ignores are complexity,
>and how to maximize reliability while minimizing cost.  Redundancy is
>a very important technique for creating reliable systems, but "mere
>redundancy" is *not* enough; it is a lot harder than that.  Food for
>thought: multiple robot systems already have the very hard problem of
>constructive interaction; might this complicate reliability even more?

Granted, constructive interaction is a problem right now.  The answer is
to have *no* interaction.  Send X completely independant robots down the
volcano, recoding from each.  It is unlikely that all of them would
encounter the same fault/environmental problem.  When you compare the
unit costs per robot to the over all design costs, I bet that making a
few robots once the design were finalised would make very little change
to the overall costs of the project.

Bill

wsmart@uk.ac.dund.mcs