NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/robotics/2888

Internet Message Format | 1993-01-12 | 3.2 KB

Path: sparky!uunet!mcsun!uknet!edcastle!aifh!williams
From: [e-mail] (Bill Smart)
Newsgroups: comp.robotics
Subject: Re: Reliability of Multiple Robot Systems
Message-ID: <[e-mail]>
Date: 12 Jan 93 22:24:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Bill Smart)
Organization: Dept AI, Edinburgh University, Scotland
Lines: 47

In article <[e-mail]> [e-mail] (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....

>[e-mail] (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

[e-mail]