Many-Robot System Communications Requirements

The general requirement for all the communications techniques we are attempting to define is that they should be applicable to systems comprising an arbitrary number of interacting elements. LAN buses capable of supporting a limited number of nodes and sequential polling techniques whose access time increases linearly with the number of elements are only two of many conventional communications techniques that can not be used in such a system.

Peer-to-peer Cooperation

Cooperative behaviors can often be realized without communications of any sort between the elements of the system [ARK92b], and, as the discussion below on Communication Channels, Protocols, and Cueing implies, simple cueing can be both effective and efficient when coordination of the overall system is to be based on some sort of information flow between peer elements. Message-based communications should be the exception in many-robot systems, just as it is in complex animal societies. In any event, communications per se should only be needed between elements that are nearest each other. This implies the use of signals of limited range -- on the order of a few times the distance between nearest neighbors. It would make sense to adapt the signal strength to maintain this contact while minimizing channel congestion.

Hierarchical Communications

For the foreseeable future, all many-robot systems will involve hierarchical communications.

Any artificial system must ultimately serve the desires of an external user, even a "swarm system" in which a large number of identical simple elements function purely as peers. As a system is deployed, it may be necessary for the user to pass mission parameters to the elements. Many systems will have to afford the user the means to update mission parameters during the mission, or to recall the system completely. Similarly, many missions will require the return of information from the system to the user or to other external entities.

More critically, while the deployment and operation of a given many-robot system may require no communication with the user at all, the process of developing it will require communications between the system and its developer in order to support the refinement of behaviors and/or algorithms. The many-element biological systems such as ants and bees which serve as models for our artificial systems have evolved through countless generations; it is certain that our own development efforts will require lots of tuning to achieve effective and efficient results. While simulation will play a major role in this system tuning, it will always be necessary to experimentally verify the validity of the simulation results, especially since simulations employing space and/or time granularity are especially vulnerable to computational artifacts [GAGE92a], [HUB9X]. Thus it is likely that the developer will still have to experimentally explore a many-dimensional behavior design space to ensure system effectiveness over as wide a range of application environments as possible. And it will simply not be possible to download a software update to one element at a time when there are potentially thousands of elements, especially during a behavior debugging process requiring many such software iterations. Similarly, while the ability for the developer to determine the internal state of specific system elements (i.e., what behaviors are actually operative) will be key to effective and efficient system tuning, behavior which appears visually to be "seamless" may in fact result from continuous rapid oscillation between different behaviors in a subsumption [BROO86] or schema-based [ARK92a] architecture. Intelligent program management dictates accepting the increased up-front cost of an effective communications scheme between development engineers and the system elements in order to reduce program technical risk, schedule risk, and overall cost.

Mission-specific Communications

In addition to the communications requirements of a generic many-robot system, some applications will require that additional communications capabilities be incorporated into the system, for example, communications relaying [MEGA78]. These additional communications functions may coexist independently, or their interaction may provide either opportunities (e.g., resources that can be shared) or additional challenges (e.g., RF interference, bandwidth allocation) to the systems developer.

Up to Many Robot Systems

Robotics home page

Please address all questions and comments to: robo-web@spawar.navy.mil
Last update: 1 December 1998.