3.1 What’s Different About Robot Programming?
The robots manufactured by Real World Interface, Inc., are self-contained, self-propelled mobile units equipped with sensors for making observations about the environment in which they operate, and mechanisms for moving around in, and affecting, that environment. For example, an RWI, Inc. robot can roll over to a workbench, stop just short of it, pick up an object, turn in another direction, roll to another workbench, and put the object down. An RWI, Inc. robot can be "trained" to roam the corridors of a building without colliding with any of the preoccupied, equation-muttering, coffee-mug-and-lab-report-toting scientists wandering about, or to pick up the trash left in a conference room after a particularly contentious design review.
"Training" a robot to perform such tasks -- that is, training it to accurately observe and reliably interact with its environment -- seems, at first, just a "trivial matter of programming." But the "embedded software" that drives a robot must operate in noisy, messy, unpredictable, rapidly-changing environments, rather than being safely ensconced within the abstract and relatively static cocoon enjoyed by more conventional programs. The woes of a robot programmer’s life include inexact observations, imprecise movements and undetected errors. Of course, all good roboticists take pride in their safety precautions, prudent lab management policies and in the special care they take to prevent such robotic calamities as tipping over, falling downstairs and soda in the servos.
Let’s take a basic, everyday software task -- copying a buffer in memory to disk -- and compare how a conventional program’s approach and performance might differ from a robot’s. The conventional program need only ascertain how many bytes are in the buffer, ensure that there is enough disk space available for them, and write out the bytes in sequence. In thepredictable world of conventional software, this task is the very archetype of "trivial."
What would happen, though, if the program’s knowledge of the size of the buffer depended on the level of accuracy available to a robot’s distance-detecting sensors? The robot’s estimate of the distance to an object, while often correct, might also be off by a factor of two or more. Suddenly, the task of copying the buffer becomes a bit trickier. And while the conventional software can be virtually certain that its operating system will write out those bytes faithfully and unerringly, the robot must trust to the relative vagaries of its mechanisms, which might gently place an object back on the workbench, but might also bash it down roughly because of a mechanical malfunction or a bug (the entomological variety) in the works.
Finally, when the conventional software detects an error, it (ideally, anyway) either recovers gracefully or sends a polite notice about the exact nature of the error. The robot, on the other hand, might simply stand there, dazed, or enter some undefined, and possibly undefinable, state -- without so much as a mechanical nod to anyone.
So, the robot programmer cannot simply follow the time-tested algorithm: "Observe, act and --if no errors are reported -- exit confidently and pursue the next task in line." No, the robot programmer must take special care to try to increase the likelihood that the action requested does, in fact, occur. A more iterative and heuristic algorithm increases the odds: "Observe, act, observe again to discern the results of acting, act again to correct inaccuracies in the previous action, observe again..." and so on. Such an iterative, heuristic approach is built into the BeeSoft software. The sample program presented later in this chapter explores a simple robot control scenario and illustrates this design approach.
