Other Communications Channels

Display "LEDs"

In order to make effective use of internal state information acquired from a specific robot, this data must be correlated with external observations of the robot's behavior. This will often require identifying precisely which one of the many identical robots is the one doing the reporting. This capability is just one of many provided by a low bandwidth cueing and display mechanism incorporated into each robot -- for small ground vehicles in a laboratory environment it's convenient to think of this as a set of several different colored LEDs, although the implementation modality may be markedly different for other systems in other environments. The master can identify a single robot -- or any group of robots -- by instructing them to "wink" their yellow LEDs.

This same mechanism can be used to explicitly display state information to the user, or to share information with its neighboring elements. Via the broadcast command channel, the master assigns -- and can dynamically reassign -- a specific representational meaning to each LED or combination of LEDs; coded modulation of the LEDs is not used to send serial messages. The system developer can program a light to indicate a specific boolean combination or sequence of behavior states in order to help understand an unexpected group behavior by, for example, "capturing" an unanticipated transient state. In a deployed system, each element may inform its neighbors of its own behavior state in order to more effectively coordinate the behavior of the local group (Wang [WANG94] refers to this as "signboard" communication, and similar schemes have been explored in simulation by Arkin et al [ARK93] and Lucarini et al [LUCA93]). When a low cost "early warning" sentry robot detects an intruder, it can signal that fact to attract the attention of a more capable and expensive "assessment and response" robot (analogous to the action of antibodies and phages in the immune system).

During development, one light is used for error signalling. A hardware timer turns the red LED on if the robot's software fails to send its periodic timer reset. The software can also be programmed to turn the same LED on (continuously or flashing) if it fails to receive the "keep-alive" message periodically sent by the master, thus providing the highly desirable "please tell me if you don't receive this message" function, and allowing the culling of failed units. The LEDs are memory mapped, with the additional timing hardware for the error LED being transparent to the programmer (who can of course read the value of the variable to determine if the timer has in fact timed out and turned on the LED).

A key benefit of using a display mechanism such as colored lights which can be directly imaged with a camera is the potential for automatic aggregation and display of status and reporting information at the master. Instead of the master having to process an endless torrent of digital messages containing state information, maintaining a database containing each element's position and status, and repeatedly updating a display, the master can, if the geometry of the situation permits, simply program a rapid sequence of display light assignments and use simple image processing to derive the desired information. The human user of a sentry system deployed in and around around a storage yard could use a camera mounted on a mast or aerostat to visually see where the robots are and what they "think" is happening. On a smaller scale, the elements of a distributed instrumentation system could be glued to the side of a piece of equipment and a camera set up to provide a continuous display of thermal, acoustic, or other parameters. And microsopic sized sensing elements programmed to change their optical characteristics in response to their chemical and/or physical environment could be suspended in a container of liquid to provide "in-situ visualization" of temperature, pH, or salinity.

"Marking" Robots

A valuable complement to the display LED mechanism is a designation mechanism which allows the user to gain the attention of a specific unit by physically pointing to it -- the equivalent of "Hey you.... yes, you!". The user has a device that looks like a flashlight that emits both visible light (so the user can see where he is pointing it) and an IR beam that can be switched between two simple modulation modes named mark and unmark (e.g., a square wave at two different frequencies). The control station sends a command to a group of nodes to enter the marking state. While marking, hardware in a node sets its marked variable whenever it detects the mark beam, and clears marked when it detects unmark. By viewing an LED programmed to track the marked variable, the user can precisely designate the units he wants, then clear marking and address messages to the marked subset. A physical button that toggles the mark variable might be a useful feature on "toy car" class robots.

Activating and Suspending Robots

The task of activating a system comprised of a potentially unlimited number of robots is not trivial, especially since a deployed system will probably have to have significant "shelf life" -- think in terms of a carton of heavy packing peanuts stored in a locker somewhere. Underwater robots can be activated by exposure to seawater; in some other situations exposure to ambient light could be used. But the general solution calls for some (probably application-specific) stimulus that can be detected by a bit of hardware that consumes zero power while waiting. This stimulus can be used to turn on the node's core processor, which can then either process more complex corroborating stimuli, or proceed directly to initializing the entire robot and awaiting (if applicable) a command from the control station.

The task of node activation must also be accommodated in the system development process. Since the developer will often prefer to turn nodes on and off without having to perform physical rituals such as pouring water on them, the command structure should provide message types to support this. A node in sleeping state plays possum while waiting for a WAKE command. A frozen state permits the developer to halt the node's execution of its mission program to provide an opportunity to examine its internal state.

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.