4. Adding Supervisory Control
Consider the differences between riding a horse and driving an automobile. A horse will not run into a telephone pole at high speed. If you fall asleep in the saddle, a horse will continue to follow the path it is on. If you have two horses but only one rider, you simply have one horse follow the other. In general, horses are much smarter than automobiles. This arrangement provides a good example of partnership between man and and "machine": the horse takes care of the details of motion while the human provides overall guidance. In the previous sections we described the design of competent animal-like robots. However, for some applications these may be too far in the opposite direction from cars; more like wild horses that do what they feel like and are oblivious to outside commands. In this section we show how to tame the creature by adding supervisory control to a reactive multi-agent system and describe an actual robot ("Mister Ed") built along these lines.
Figure 8 - As shown in this overhead view, our mobile robot has 3 sensory modalities. The infrared proximity sensors are used for local navigation and obstacle avoidance, the sonars are used for following people, and the bumpers are used for collision detection.
As before, the control system of this robot consists of a collection of situation-action rules. The input to this rule system comes from a series of sensors mounted around the periphery of the robot. As shown in Figure 8, the robot has three different sensory modalities. At the front and rear of the robot there are bumpers switches (black bands) to detect any collisions that may occur. Each bumper is divided in half to allow lateralization of the contact. For local navigation there are 8 very long range proximity detectors arrayed around the robot (gray lines). These units ("IRs") emit infrared energy in a tight beam and look for any reflection above a certain intensity threshold. The sensors have been angled downwards to insure that any object sensed is actually between the robot and the floor intersection point. Finally, there are two Polaroid sonar sensors mounted at the front of the robot such that their radiation patterns overlap. The sonar echoes are classified into one of 4 distinct qualitative regions (dotted lines show divisions) to assist the robot in following objects.
A summary of the various behavior modules used by our system is given below. The driver's directions are incorporated into the control system by disguising them as the outputs of two normal rules (Joy-Trans and Joy-Turn). Thus, the driver can override some of the robot's innate tendencies yet there are other behaviors which can override him. As before, the complete set of rules are listed in order of ascending priority. For instance, the output (if any) of the Retreat rule completely overrides any output produced by the Trek rule. Notice that the behaviors which control the robot's translation are separated from those that control its rotation. This is because sometimes the relative priorities of related behaviors are different. For instance, if the robot hits an obstacle, Bounce insists on backing up no matter what the driver commands via Joy-Trans. Yet, since Joy-Turn takes precedent over Turn, the robot is willing to let the operator choose a particular direction of travel by deflecting the joystick.
Translation behaviors (in order):
| Approach | - Go forward if an object is detected beyond the optimal sonar range. |
| Trek | - Go forward if any of the side IRs have been active recently. |
| Retreat | - Go backward if an object is detected in the near sonar range. |
| Joy-Trans | - Obey all of the driver's forward and backward commands. |
| Bounce | - Go forward or backward a while depending on which bumper was hit. |
| Halt | - Prevent travel in the direction corresponding to the impacted bumper. |
| Fend | - Prevent forward travel if any of the front IRs are active. |
Rotation behaviors (in order):
| Align | - Turn toward the the nearest object detected by the sonar. |
| Parallel | - Suggest turning to make both side IR sense the wall if one did. |
| Turn | - Turn away from side of the recently hit bumper. |
| Stymie | - Turn left if all the front IRs are active. |
| Thread | - Turn to unblock a single front IRs. |
| Veer | - Turn to unblock a single diagonal corner IRs. |
| Twist | - Turn toward the side on which a persistent IR signal recently disappeared. |
| Joy-Turn | - Obey the driver's left and right turn commands. |
| Point | - Prevent any turn if a bumper is hit. |
The outputs from these collections of production rules control the motors on a two-wheeled base. In this robot, we have divided the motion control problem into a forward/backward velocity component and a left/right velocity component. These are in essence two different "resources", each with its own set of behaviors as shown above. In other robots, we have further subdivided control by adding "speed" resources and special velocity regulating rules for each type of motion. Here, we just quantize each degree of freedom to either positive, negative, or no motion (i.e. 2 bits). Several times each second, Mr. Ed runs through all the active rules and updates his four motion control bits accordingly.
It usually not desirable to run all the robot's rules at the same time. For instance, the goals of person tracking and wall following (e.g. Align versus Parallel) can interfere with each other. Such interactions become an especially serious concern as the size of the rule base grows. While some of this disorder is resolved by breaking down the control of the robot based on different actuator resources, we address the fundamental problem by segregating rules into small groups. Each "competency module" constitutes a toolbox for achieving a particular goal. Since they are not intended to be used together in arbitrarily large groups, as a first approximation inter-rule dependencies need only be considered within each module.
This suggests another way in which the human driver can influence the robot, other than being just another rule in the system. We provide a series of toggle switches which allow the operator to selectively enable and disable various groups of rules. This is how the person tells the robot what its current "goal" should be. However, each user-level goal is usually comprised of a number of sub-goals. Thus, there is generally not a one-to-one mapping between switches and behavior groups. Figure 9 shows this breakdown. Also, certain basic behaviors, such as the joystick interpretation rules, are always active (dark bordered box) and others are active anytime the robot is allowed any control at all (gray bordered box). In our robot, these groups correspond roughly to the universal goals of obedience and self-preservation.
Figure 9 - The robot's situation-action rules are broken up into a number of functional groups. The robot can be authorized to perform a specific activity by enabling certain of these groups. Some groups (heavy bordered boxes) are always active, no matter what activity is selected.
The use of this partitioned system is best shown through several examples. Suppose, at the start, that all groups except the joystick repeaters and basic protective behaviors are disabled. The operator is basically free to drive the robot in any direction desired. However, if the front IRs detect an obstacle, the robot will refuse to continue going forward. Like a horse, it balks at this command. In certain cases, such as traversing a narrow doorway, the operator may decide that the robot is being too cautious and then disable the protective behaviors to obtain complete control. On the other hand, he may instead wish to delegate more authority to the robot by enabling the corrective steering behavioral groups. The rider now retains control of most of the forward/backward motion of the robot, but does not have to worry about veering around obstructions. He simply tells the robot to go forward and it takes care of the moment-to-moment heading changes required.
The rider may eventually get tired of driving altogether and give the robot even more control by activating the person following routines. This is useful in large open spaces where the final destination is unknown. Alternatively, the rider may instead decide to travel along some particular natural path in the environment, such as a the edge of a room or corridor. To start the robot in some particular direction, the operator enables the appropriate rule groups and then drives the robot until it is more or less aligned with the wall or corridor it is supposed to follow. At this point the driver can relax and the robot will continue along this environmentally defined path indefinitely. He is free to fall asleep in the saddle if he wishes. In this case, the robot is acting as a smart peripheral. A similar approach could have been used on the can collecting robot to emulate the convenience of the "grab-it" button found in many video-games. By relying on a collection of local procedures, the high level controller need not worry about actually moving the agent's hand or about a achieving a firm grasp on the desired object.
When running in the autonomous wall following mode, the driver will occasionally resume control for a moment. The usual reason is to a make strategic navigation choice such as which corridor to follow at a branching, or whether to go through an open door. Yet, even some of this can be delegated to the robot. If the door finder routine is enabled the robot will execute a 90 degree turn at the next aperture it sees, and then continue forward using its local navigation routines. Thus, the driver never has to take real-time control of the robot, he merely modifies its reflexes so the appropriate action will automatically be taken in each situation which is likely to occur. This is analogous to advice such as "the play is to second" muttered during a baseball game. All the computation intensive deliberation can be performed off-line and then compiled down for later use should the contingency arise.
Copyright © 1992, Johuco Ltd., All Rights Reserved