Robotics home pageYou are the lead engineer developing a many-robot system intended to address a real-world application -- for example, to find and destroy buried antipersonnel landmines in fairly benign terrain. The plan is to add sensors and processing to inexpensive "toy car" mobility bases so that they will move as a churning flock whose center wanders in a quasi-diffusing random motion from its deployment point. The system concept calls for a robot to stop when it finds a mine and then (in its production version) blow up both itself and the mine at a predetermined time, or sooner if it is disturbed. The system is intended for deployment behind enemy lines in advance of an attack, and therefore is designed to require absolutely no communication. The system is designed to be completely scalable -- the more elements are deployed, the larger the flock size and the larger the area covered by the diffusion. The project's (very reasonable) development strategy called for breadboarding up a dozen or two individual robots, experimentally determining sensor characteristics and performance, and designing a set of reactive behaviors. Following validation of the behavior algorithms with extensive simulation, and some real product engineering, several hundred elements have been manufactured for an initial capabilities demonstration.
It's demo day, and you, as project lead engineer, are standing with your program manager and sponsor at the edge of the demo field when the box of critters is dumped from the back of a HMMWV. They come streaming out, and start to form the desired flock. As everyone starts congratulating each other, your sponsor suddenly motions towards a small but growing clump of robots off to one side and says "Hey! What's that little group doing over there?" As you listen to your project manager promising your sponsor that you will obviously be able to quickly fix this very small glitch in the system, you realize that not only do you not have a way to reprogram the units in the field, but also that you wouldn't know how to reprogram them if you did, since you don't have a clue as to what is causing the aberrant behavior, which did NOT appear in simulation, or in your preliminary tests at a field that appeared to be virtually identical to the demo site. Furthermore, you don't know how you are going to find out what is going wrong so that you can fix it.
While this scenario in its details has admittedly been deliberately constructed as a worst case, the problems it poses are all too real. An autonomous mobile robot is a complex machine which is called upon to perform navigational and other tasks framed by its human developers, but without being able to call upon human perceptual capabilities. The process of debugging such a machine is often extremely frustrating, because the precise features of the environment that the robot's inexpensive sensor suite responds to may not be those that the developer intended, so that a scheme that works well in one environment may fail miserably in another environment which appears imperceptibly different to the human developer [EVER94]. The developer's problem is exacerbated by the fact that the robot's externally observable behaviors may offer few clues to the dynamics (sensor inputs and processing states) producing them. What looks to the observer like a nice straight-line robot path may "feel" to the robot like a rapid oscillation between small left and right turns at a tens-of-Hertz rate (it is a control loop, of course). Since the notion of an "operator's interface" for a robot that is supposed to be completely autonomous sounds like an oxymoron, such a capability is often implemented only as a rudimentary afterthought -- but it is precisely what is needed for efficient debugging.
When we move from a single robot to a system consisting of many robots, the problem is multiplied manyfold. The cost of each element must be minimized to keep the system competitive, which means that we can absolutely expect to encounter the sorts of problems that result from limited sensor capabilities. Desired ensemble behaviors may be intended to "emerge" from the simpler behaviors of the individual elements, adding an additional layer of complexity. The system concept of operations may involve little or no communications when deployed, either between elements or between the user (the person who deploys the system) and the elements. Finally, the system may be intended to be used in a single shot "throwaway" mode, so that the target hardware is neither reprogrammable nor rechargable.
Up to Many Robot Systems
Please address all questions and comments to: robo-web@spawar.navy.mil
Last update: 1 December 1998.