In most existing robotics applications, the robot controllers are written using specialized, non-logic-based robot programming languages. Those languages provide features which are not present in the GOLOG family of languages and which have proven to be quite useful in practice. We will now take a look at the area of non-logic-based robot control and on the features provided by modern non-logic-based robot programming languages.
2.3.1 Robot Control Architectures
In the early days of AI-based robotics, the dominant control architecture for autonomous robots was the classical sense-plan-act (SPA) approach. This approach, which goes back to the work on the (first version) of the robot Shakey [Nil84], decomposed the control problem into three functional elements: a sensing system which translated sensor input into a world model, a planning system, and an execution system. This classical approach suffered from numerous shortcomings. In particular, planning and world modeling turned out to be very hard which caused the approach to have difficulties to react in real-time, and open-loop plan execution was inadequate in the face of the uncertainty encountered in realistic robot environments.
Several alternative approaches to robot control have been proposed to overcome the short- comings of SPA. One the most prominent (and radical) departures from SPA is the behavior- based approach advocated by Rodney Brooks [Bro86, Bro91]. The behavior-based approach stresses the use of minimal internal representation, following the slogan “the world is its own model”. Brooks proposed to decompose the problem of robot control into layers correspond- ing to different levels of behavior. Central to his approach is the concept of subsumption, which means that more complex layers can influence lower layers. Subsumption achieved dramatic success regarding basic-level tasks like obstacle avoidance or navigation. However, the approach had severe difficulties to scale to more complex tasks (cf. [Gat98]).
Today, most robot control architectures are hybrid systems that make use of both reactive components like behaviors, and components which are based on a symbolic representation. All of these approaches comprise two main layers: a reactive feedback control mechanism, and a task-control or sequencer layer which initiates and monitors behaviors, taking care of temporal aspects of coordinating behaviors. In addition, these architecture usually include a higher-level deliberative layer to provide look-ahead planning capabilities. The communica- tion between the different layers is achieved via messages. Some of the most prominent hybrid
control architectures are the 3T architecture [BFG+97], Atlantis [Gat92] and SSS [Con92].
But they also include the mobile robot Diablo [BFH+98], whose higher control level is based on
the languageA, the very successful museum tour-guide robots Rhino [BBC+95, BCF+00] and
2.3. ROBOT CONTROLLERS 33
Low-Level Processes At the lowest layer, most hybrid architectures employ a suite of
continuous processes (often called behaviors or skills) that provide situated control for the physical actions effected by the system. Here, we refer to such processes as low-level processes. We won’t elaborate on the topic of low-level robot control except to note that this layer can be quite complex. It may involve a fuzzy controller [KMRS97] or may be based on POMDPs
[SK95]. State-of-the-art basic-task levels like the BeeSoft system [BCF+00] used in the Rhino
and MINERVA projects provide robust facilities for collision avoidance [FBT97], localization
[FBT99, FBDT99], map building building and path planning [TBB+98].
2.3.2 Non-Logic-Based Robot Programming Languages
In most of these architectures, it is the sequencer that plays the role of the main executive, and which (eventually) invokes the planner to accomplish goals. The sequencer must support continuous processes and concurrent actions, since a robot must generally perform many
activities. While parts of the sequencer programs may automatically be generated by a
planner, quite often they are hand-tailored by a robot programmer. As stated by Kurt
Konolige [Kon97], “when one thinks of writing robot programs, it is sequencer programs that are the result.” We will now briefly go over some of the most prominent robot programming languages and then elaborate on McDermott’s reactive plan language RPL [McD91].
PRS-Lite PRS-Lite [Mye96] is a derivative of the family of Procedural Reasoning Systems
[GI89] optimized for compactness and efficiency. PRS-Lite provides constructs like test in- structions which provide the ability to test environment variables, execute instructions used to set environment variables or to trigger external actions, intend and unintend instructions used to activate respectively to explicitly terminate low-level processes, and wait-for instruc- tions that enable limited suspension until a certain condition or event occurs. The wait-for modality is critical in that it enables synchronization among concurrent processes. Sequencing constructs like if (conditional activation) and and (parallel activation) allow goal-ordering. A compiler transforms the specifications into finite-state machines, which allows the realization of an execution loop with a very short cycle time.
Colbert Colbert [Kon97] is a successor of the PRS-Lite system which provides similar in-
structions. A major difference between PRS-Lite and Colbert is that the syntax of the latter is based on ANSI C, which facilitates the readability of robot control programs for programmers used to sequential, conditional and iterative constructs. Nevertheless, it provides much the same functionality as PRS-Lite, including iteration, concurrent activities and suspension via waitfor. Just like PRS-Lite, Colbert does not include capabilities for deliberation over different procedures.
RAP The RAP system [Fir87, Fir95] is a plan and task representation based on program-
like reactive action packages, or RAPs. The idea is that a planner produces “sketchy” plans, relatively vague plans where some steps must be determined at run-time. The RAP execution system then fills in the details of the sketchy plan at run time. The RAPs thus serve as a bridge between the planner and the control system. They expand vague plan steps into detailed instructions by choosing an appropriate method for the next step from a preexisting library. To determine what method to use, it maintains a memory containing what is believed to be true about the world. If a method does not achieve its intended goal, the RAP system
chooses another method and tries again. Like PRS-Lite and Colbert, RAP provides facilities for concurrent execution and synchronization (in particular, the wait-for construct). The RAP system can thus be seen in two different ways: as a reactive system which can accomplish quite complex goals given the methods in the library, or, on the other hand, as supplying a planner with abstract “primitive actions.”
RPL RPL [McD91, McD92a, Bee99] is a notation for writing reactive plans for agents, e.g.
for robots. Recently, it has been used successfully to control the behavior of the mobile robot
MINERVA deployed in a realistic environment for an extended period of time [TBB+99].
RPL’s immediate ancestor is the RAP notation. Compared to RAP, however, it does not attempt to maintain a world model that tracks the situation outside the robot. The intent of RPL is to spell out how the behavior of an agent is to be driven by events around it, and to do so in a transparent notation.
RPL is implemented in LISP, and RPL programs look like LISP programs. RPL provides the constructs (seq c1... cn), (if cond cthencfalse) and (loop cond -body-), which allow, respectively,
sequential execution of several sub-plans, conditional execution depending on the truth-value of cond, and while-loop iteration. Local variables can be declared by the usual LISP construct (let ((v1 val1) (vn valn)) -body-), which introduces new variables vi with initial value vali.
Finally, RPL code affects the outside world by special RPL procedures that send signals to the output ports.
As mentioned above, the intent of RPL is to specify how the behavior of an agent is to be driven by events around it. A key mechanism to achieve this aim is the concept of a fluent. Here, the term fluent is used to refer to a program variable of time-varying value which is set by sensors. The RPL run-time system takes care of automatically updating the value of fluents when new sensor inputs arrive. For example, a reactive controller written in RPL will make use of fluents like robot-x and robot-y to represent the robot’s x and y coordinates. We stress that in RPL fluents are merely a special kind of program variable, and should not be confused with the situation calculus notion of a fluent.
robot-x 860.0 1265.0 819.0 robot-y < > < AND in-room?
Figure 2.1: A fluent network An RPL plan can react to changes of the values of
fluents by means of the RPL instruction (wait-for fl), where fl is a binary fluent. This construct causes the execution to suspend if the truth value of fl is false, and to wait until it becomes true. The wait-for instruction can not only be applied to primitive fluents, but also to fluent-networks, boolean expressions involving fluents. Figure 2.1 illustrates an example fluent network which verifies that the robot’s position lies in a certain range. Using wait-for and such a fluent-network, it is possible
to specify a robot program that reacts as soon as the robot enters a specific area.
RPL supports true concurrency, meaning that several sub-programs can be executed in parallel. In particular, RPL provides the constructs (par a1...an) and (try-all a1...an), which
both start executing the sub-plans a1...anin parallel. The difference between the two construct
is that the former ends only after all sub-plans a1...anhave ended, while the latter is completed
as soon as the first sub-plans ends.
Programs running concurrently often compete for resources. For example, different pro- cesses may compete for the control of the robot’s wheels. In order to synchronize concurrent
2.4. DISCUSSION 35