Page 164 - Anatomy of a Robot

05_200256_CH05/Bergren 4/10/03 12:00 PM Page 149
DESIGN STEPS: HLD 149
We could use intelligent batteries that have the capability to communicate with a
computer. These batteries have special connectors that carry serialized signals to
a computer interface. We can program the computer to interrogate the batteries
and report on their status, but an easier way exists.
If we are content with the accuracy it affords us, and if we are not worried about
the consequences of getting bad information now and then, we can simply simu-
late the batteries inside the software. We only need to know how long the batter-
ies have been drained by the robot and how long they have been charging. If the
simulation errs on the side of keeping the batteries charged, then the computer will
be able to perform the function entirely in software. What advantages accrue to
the design team? First of all, we will only need standard rechargeable batteries as
sold in the store. We will not need special batteries that can communicate. We
won’t need a battery interface on the computer. The robot will cost less as a result.

Many other functions can be moved from hardware into software. Just be aware that
what the computer and the programmers can do is limited. Times will occur when the
inclusion of hardware will obviate the need for painful and expensive programming.
Reexamine the robot design during the HLD review process. Have the team meet and
discuss the welfare of their new offspring. Bring in outside advisors for the review meet-
ing who may be able to spot things others cannot. Several questions should be
addressed, including
Is it simple enough and reliable? If team members are uneasy about sections of
the design, that’s a place to start the discussion.
Take a close look at all the parts that might have high failure rates or might be
environmentally sensitive. Reduce the need for those parts if at all possible.
Reduce the need for risky operations or mechanics. The best mechanical designs
tend to be extremely simple.
Look for places failures could occur. It does not take an expert to sense where a
design may have problems.
Take a look at the requirements for automation. What algorithms will be used?
Is the software simple enough? Are the programmers running wild? (Oh yes, they
will do that given too much sugar!)
Can the software cause failures all by itself? Software reliability is a major tech-
nical arena with conferences, toolsets, specialists, and so on.
Are there sufficient design margins? Do the actuators, batteries, and computer cir-
cuits have more than enough horsepower to achieve their goals? It’s wise to over-
specify by a significant margin when specifying these items. Most projects expand