PRS(ID:7782/)


Procedural reasoning system


References:
  • Georgeoff, M. and A. Lansky. Reactive Reasoning and Planning. Proc. National Conference on Artificial Intelligence, pp 972-978, Seattle, WA, July, 1987 view details
  • R. Simmons and D. Apfelbaum "A Task Description Language for Robot Control" Proceedings Conference on Intelligent Robotics and Systems, October, 1998. view details Extract: Introduction
    Introduction
    Robot systems, such as autonomous mobile robots, need to
    achieve high level goals while remaining reactive to
    contingencies and new opportunities. They need to recover
    gracefully from exceptions and effectively manage their
    resources (such as actuators, sensors, and computation).
    These capabilities are referred to as task-level control [15],
    and they form the basis of the executive layer of modern
    three-tiered robot control architectures [1, 3, 4, 10]. In such
    architectures (Figure 1), the behavior (real-time control)
    layer interacts with the physical world, controlling
    actuators and collecting sensor data. The planning layer
    specifies, at an abstract level, how to achieve goals and how
    to deal with goal interactions. The executive layer mediates
    between the symbolic level of the planner and the
    continuous level of the behaviors. It expands abstract goals
    into low-level commands, executes the commands,
    monitors their execution, and handles exceptions.
    Unfortunately, task-level control programs are often
    difficult to develop and debug. One problem is that
    effective task-level control often requires that the robot do
    things concurrently, such as moving and sensing, planning
    and executing, manipulating and monitoring, etc. These
    concurrent activities often need to be scheduled and
    synchronized, either to avoid interactions or to coordinate
    activities. Another difficulty is that exception handling
    often involves non-local flow of control. For example, if a
    robot encounters an unexpected obstacle, it might first try
    the move again (the obstacle may have moved). If that fails,
    it might replan its path, switch to another goal, etc.
    Using conventional programming languages to implement
    such task-level control functions would result in highly
    non-linear code that is often difficult to understand, debug,
    and maintain. To address this, we have designed TDL (Task
    Definition Language), an extension of C++ that simplifies
    the development of robot control programs by including
    explicit syntactic support for task-level control capabilities.
    TDL directly supports task decomposition, fine-grained
    synchronization of subtasks, execution monitoring, and
    exception handling (support for resource management [11]
    is planned). We have developed a compiler that transforms
    TDL code into efficient, platform-independent C++ code
    that invokes a Task Control Management (TCM) library to
    manage task-control aspects of the robot system.
    The following section presents related research in
    languages for task-level control. We then describe task
    trees, the semantic construct underlying TDL and TCM.
    Task trees encode the hierarchical decomposition of tasks
    into subtasks, as well as synchronization constraints
    between tasks. We then describe the language itself, and
    illustrate it with a simplified example of its use in an
    autonomous delivery robot [16]. Finally, we present
    overviews of the TDL and TCM implementations, as well
    as tools that we are developing to further support the design
    and debugging of task-level control programs. Extract: PRS
    PRS (Procedural Reasoning System) is based around the
    concept of a procedural reasoning expert [6]. PRS
    facilitates deciding what actions an agent should be doing
    at any given time. Both Lisp-based and C-based
    interpreters for PRS have been implemented. PRS, like
    RAP, is tightly integrated with a ?world model? knowledge
    base that is used to identify opportunities, exceptions, and
    when to transition between tasks. TDL does not make this
    ontological commitment: A separate knowledge base could
    be integrated, but is not mandated. We feel that this gives
    developers more flexibility in deciding how to design their
    systems, without precluding such architectural decisions.