3. Coordinating Multiple Behaviors
Here we describe the design of part of a sophisticated mobile robot named Herbert. This robot is 18 inches in diameter and stands about 4 feet tall (see Figure 5). Herbert's overall goal is to collect empty soda cans. It starts by wandering around its environment and searching for cans with a structured-light ranging system. When it finds a promising candidate, it carefully approaches and aligns itself with the target. The robot then releases its arm and gropes around using local sensors to retrieve the can from wherever it is sitting. Once the robot has picked up the can, it slowly navigates back to its home position and deposits its trophy. Finally, the cycle repeats and the robot ventures forth once again on its quest. We concentrate here on just the manipulation phase and skip over the other subtasks.
Figure 5 - Herbert's primary goal is to collect empty soda cans. It locates them with a laser light-striper, grabs them with a long arm, then uses proximity sensors and a compass to bring them back.
The most essential goal for our robot is to actually grasp a can. Crucial to the development of this subsystem is the arrangement of sensors on the hand (see Figure 6). These are positioned so they directly detect relevant situations. The types of situations and appropriate responses are described below. Our approach to this problem is to imagine a progression of increasingly complex situations, and then devise ways of reducing each case to the next easier one.
Figure 6 - The hand has a variety of local sensors which serve as the basis for our "matched filters".
Let us start with the simplest case in which the can is already between the robot's fingers. This can be easily detected by looking for an interruption in a light beam near the back edge of the fingers. In this situation, the robot should obviously close its hand around the can. This is the first behavior in our control system: if anything is ever placed in the robot's hand, it grabs the object. Note that the physical construction of the robot's hand and the placement of the beam sensor already form a "matched filter" for graspable objects. Only things that fit between the spread fingers (a 5" gap) can be grabbed. Also, if the object is inserted from the front, it will be well positioned for gripping by the time the beam at the back is activated.
Next, let us consider the case in which a can placed directly in front of the hand. Here, a reasonable default strategy is to extend the arm forward until the grab reflex is actuated. This then becomes our second behavior. However, depending on the relative heights of the hand and the can, the robot might very well knock the can over. While many cans would fit in the hand even in this new orientation, they are much more prone to rolling across the table. To avoid this, we augment the robot's repertoire by adding a third behavior which monitors the crossed infrared proximity detectors affixed to the front of the hand. Again, the geometry is arranged such that this sensor directly detects objects that would collide with the upper part of the hand. Thus, when either of the two sensitive regions is occupied, the hand instead rises straight upward until the signal disappears. At this point, it has reduced the situation to one in which simply extending forward will successfully trigger the ordinary grasp reflex.
Normally, however, the can is some distance away from the hand at the start. Extending the hand straight forward while it is several feet up in the air is unlikely to achieve satisfactory results. Instead, it makes more sense to search for a surface which might be supporting a can. This can be done by starting the arm at the top of its workspace and then slowly moving straight down. Eventually, the robot's hand should touch either a table or the floor. We can detect this by watching for the small switches at the tips of the fingers to be activated. Since it is potentially damaging (and certainly unproductive) to push the fingers through the table top, when contact is detected we add a behavior which causes the robot to lift its hand slightly until it is no longer touching the surface. Now that a surface has been found, a good strategy is to cruise along parallel to it in search of cans. We do this by adding yet another behavior which drives the hand diagonally forward and down if the tip switches have been active recently. The purpose of the diagonal motion is to keep the fingertips close to the surface. If there is some sort of pit on the table, we want the robot to be able to reach into it. Usually, however, the tip switches will quickly be activated again and the hand will rise up and move forward. Bouncing along the surface like this serves to reduce the situation to one of the earlier cases. Typically, the front infrareds will detect the can (if any) and cause the hand to rise over and grab it like before.
Note that this collection of behaviors essentially represents both cans and tables procedurally. Cans are things that fit between the fingers when the hand rises above them (as governed by the front beam sensors) and then extends forward. A number of other objects besides soda cans could also allow this sequence to run to completion. Examples are beer cans, baseballs, and small boxes. In this sense, we have really built a "graspable object" recognizer. Similarly, the robot's table representation is really based on functional properties. A table is a more or less flat horizontal surface which the hand can skim across. The robot does not really distinguish tables from floors but, since it starts at the top of the arm's workspace, the hand is more likely to encounter a table top first. The knowledge that tables are high up and that cans are often found on tables (or at least on supporting surfaces) is built directly into the rule set.
Suppose now, however, that all these behaviors are insufficient to keep the hand out of trouble and it manages to get stuck somewhere. One way to detect this situation is by noticing that the arm's angular configuration has not changed in a while. When this happens, we kick in a new behavior which attempts to retract the arm until it either reaches a special "home" position or a specific time limit is exceeded. This causes the robot to give up on grabbing the can, or to repeatedly tug on whatever is obstructing its arm. Thus, we ensure that the robot continues to make progress by monitoring a sensory-derived predicate which is indicative of that progress. Interestingly, we can use this same escape procedure for two other ways in which a groping trial may terminate. One situation is the successful grasping of a can. Here, we purposely freeze the arm until the fingers have had a chance to close. However, to the monitoring behavior this looks like a lack of groping progress and hence automatically initiates retraction. The other case is when the arm has travelled all the way to the edge of its physical workspace without finding a can. In this case, since it can no longer proceed in the commanded direction, it stops. Once again, this lack of progress triggers withdrawal of the arm.
Figure 7 - The nominal environment consists of a can on a table top (thin lines). Here we show the path (thick lines) followed by the tips of the fingers during 10 consecutive runs on the real robot.
Herbert is very good at the grabbing task. Figure 7 shows some typical trajectories generated by the complete set of behaviors. At the start the ENGARDE and DESCEND behaviors locate the table top. Next, BOUNCE takes over and raises the hand and then lets SURFACE skim the hand along the table. However, before the next contact occurs the front IRs are activated which causes OVER to raise the hand to the top of the can and EXTEND to bring the can between the fingers. The GRAB behavior then comes on and closes the robot's hand around the can. Finally, HOIST and PARK bring the can back toward the robot's body. Note that events do not necessarily have to proceed in this manner. If, after the first bounce, contact is not re-established with the table, DESCEND will again become active in an attempt to better follow the surface. Similarly, if a sheer wall is encountered, OVER will raise the hand to near the top of the wall and then, with a little help from a behavior which monitors the force on the wrist, surmount it and allow the hand to continue groping at this higher level. Because the robot does not have a preset plan, there are never any overt "exceptions" or "contingencies". In this system, the trajectory is effectively programmed by the environment itself.
Copyright © 1992, Johuco Ltd., All Rights Reserved