Mobile Robot

Solution 3: Implicit Invocation

This figure summarizes the Task Control Architecture (TCA) [Simmons92] which uses implicit invocation. It was applied, among others, to the Ambler robot [Simmons90].

An Implicit Invocation Architecture

TCA is not only an architecture; it also provides a sophisticated tool box for building robots: a library of communication and control routines that implement the TCA philosophy. The following discussion focuses on task trees and the implicit invocation features. For a complete overview, see the references.

The TCA architecture is based on hierarchies of tasks, the task trees. The figure below shows a sample task tree. Parent tasks initiate child tasks. The software designer can define temporal dependencies between pairs of tasks. An example temporal constraint is: "A must complete before B starts." These features permit the specification of selective concurrency.

TCA's routines include many operations on task trees for dynamically reconfigure them at run-time.

A Task Tree

In TCA, tasks communicate by sending messages to a central server, which redirects the messages to tasks that have registered to handle them. This scheme, where the sender does not need to know the receiver, is the basic characteristic of implicit invocation.

Three more implicit invocation mechanisms are part of TCA's features:

• Exceptions: Certain conditions cause the execution of an associated exception handler. Exceptions override the currently executing task in the subtler that causes the exception. They quickly change the processing mode of the robot and are thus better suited for managing spontaneous events (such as a dangerous change in terrain) than the feedback loop or the long communication paths of the pure layered architecture.

  
  Exception handlers have at their disposal all the operations for manipulating the task trees: e.g., they can abort or retry tasks.

• Wiretapping: Messages can be intercepted by routines superimposed on an existing architecture, i.e., task tree. For instance, a safety check procedure can use this feature to validate all outgoing motion commands.

• Monitors: Monitors read information and execute some action if the data fulfill a certain criterion. An example from the TCA manual is the battery check: if the battery level falls below a given level, the actions necessary for recharging it are invoked. This feature offers a convenient way of dealing with fault tolerance issues by setting aside agents to supervise the system.

TCA also distinguishes itself from the previous paradigms by incorporating concurrent agents in its model. In TCA it is evident that multiple actions can proceed at the same time, more or less independently. The other two models do not show the presence of concurrency.

The amount of concurrency is limited by the capabilities of the central server. In general, its reliance on a central control point may be a weak point of TCA.

(R2) How TCA addresses uncertainty is less clear. If imponderables exist, a tentative task tree can be built, to be adapted by the exception handlers when the assumptions it is based on turn out to be erroneous.

(R3) As illustrated by the examples above, the TCA exception, wiretapping, and monitoring features take into account the needs for performance, safety and fault tolerance.

Fault tolerance by redundancy is achieved when multiple handlers register for the same signal; if one of them becomes unavailable, TCA can still provide the service by routing the request to another. Performance also benefits since multiple occurrences of the same request can be handled concurrently by multiple handlers.

(R4) The use of implicit invocation makes incremental development and replacement of components straightforward: it is often sufficient to register new handlers, exceptions, wiretaps or monitors with the central server; no existing component feels the impact.

In summary, TCA offers a comprehensive set of features for coordinating the tasks of a robot while respecting the quality and ease of development requirements. The richness of the scheme makes it most appropriate for more complex robot projects.

Updated Halloween 95 by Mary Shaw
Comments to maintainer