The Command Channel: "SLEEP"
The key element of the scheme proposed here is a conventional relatively high bandwidth broadcast channel which is employed to transmit messages from the user's workstation to the robots. Appropriate error detection coding is applied to the messages, with forward error correction also desired since the arbitrarily large number of robots precludes the general use of negative acknowledgements (NAKs) as well as of positive ACKs. Security measures such as encryption are implemented as appropriate to the application, and, while critically important in many applications [GAGE84], are not considered further here. How this command channel is implemented in hardware (and how "high" a bandwidth it provides) will be extremely application dependent, although RF and optic schemes certainly come quickly to mind, and also is not considered further. It is certainly possible to envision alternate schemes using non-broadcast channels and message relaying, but these would involve considerations of routing and complicated system state, and might permit a failure in one node to prevent (or at least delay) the user from communicating with a desired target node.
The first question is how to address a message to a specific individual robot or group of robots, as the number of robots grows arbitrarily large. Since the robots are identical and interchangeable (at least within each of a relatively small number of castes), the primary mode of addressing for the system could be termed "dynamic situated group addressing" -- the equivalent of saying "anyone within 50 meters of the wall who has more than 50% fuel level and at least one grenade, you're now in Group Alfa", and then addressing future messages directly to "Group Alfa." Essentially, each robot determines whether a given command is intended for him by evaluating a predicate expression based on the values of his own state variables.
This rule-like paradigm -- "IF <predicate> is true, THEN store and execute " -- has been further evolved and simplified by observing that, if we adopt a LISP representation for , we might just as well also use it for <command>, and in that case the IF-THEN rule functionality can be explicitly captured in a LISP COND function, and the whole message becomes a single LISP expression whose evaluation is all the processing that is required. And as long as our node is going to have to be able to evaluate LISP expressions received as messages, why not incorporate a writeable program store (rule base) of LISP expressions to use for debugging and even for high level mission management? The resulting scheme is nicknamed "SLEEP", for "Simplified LISP-like Expression Evaluation Paradigm", and is described in some detail below, following a presentation of additional capabilities of interest.
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.