In Proceedings of the 11th International Symposium on Unmanned Untethered Submersible Technology (UUST99),
Durham, NH, August, 1999.
(Copyright © 1999 The Autonomous Undersea Systems Institute.)

Interfacing the Orca AUV Controller
to the NPS UVW and to a Land Robot

Roy M. Turner
Jason Mailman
Department of Computer Science
University of Maine
Orono, ME 04469-5752
Voice: 207-581-3909.25in Fax: 207-581-4977
{rmt,mailman}@umcs.maine.edu

Abstract:

The Orca intelligent AUV mission controller, although still under development, is in daily use to support ongoing research on interagent communication, context-sensitive reasoning, and opportunistic reasoning for multi-AUV systems, such as autonomous oceanographic sampling networks. It is currently being developed and tested in a low-fidelity simulator. The plan is to transition the program, as it and its knowledge matures, to higher-fidelity simulations and ultimately to in-water testing aboard AUVs. This paper reports on recent work along these lines. Orca has been successfully interfaced to the Navy Postgraduate School's Underwater Virtual World to control a simulated Phoenix AUV, and it has been interfaced to a Pioneer land robot. The paper describes how this was done and the issues involved, as well as plans for future work.

Introduction

The Orca program [Turner & Stevenson, 1991,Turner, 1994,Turner, 1998] is an intelligent mission controller for ocean science AUVs and a testbed for research on intelligent agent control. Although it is still in development, the current version of the program is in daily use to support ongoing research on interagent communication, context-sensitive reasoning [Turner, 1998], and opportunistic reasoning for multiagent systems composed of autonomous underwater vehicles (AUVs) [Lawton et al., to appear,Turner & Turner, 1998], such as autonomous oceanographic sampling networks (AOSNs) [Curtin et al., 1993].

Orca is being developed and tested in a low-fidelity multiagent simulator (SMART) developed locally [Turner et al., 1991]. The plan is to transition testing, as the program and its knowledge matures, from this simulator to higher-fidelity simulations, then finally to actual AUVs for in-water testing.

This paper reports on recent progress in this area. In particular, we report on our progress in interfacing Orca to a high-fidelity AUV simulator, the Naval Postgraduate School's Underwater Virtual World [Brutzman, 1995] and in interfacing the program to a small land robot. We discuss issues uncovered in this process, and we describe plans for interfacing Orca to a distributed, high-fidelity simulator, CADCON [Chappell et al., 1999], that is currently being built by the Autonomous Undersea Systems Institute (AUSI).

Orca

Orca is a mission controller for AUVs that has been in development for several years. The original target vehicle for Orca was the EAVE-III AUVs [Blidberg & Chappell, 1986] developed by the Marine Systems Engineering Laboratory (now AUSI). The target mission domain was oceanography. The goal was to allow the AUVs' users to specify missions to Orca in terms of high-level goals (e.g., ``take samples every two minutes while running a lawnmower pattern in area 1''), constraints, and other information, then have Orca decide how to carry out the mission and then do it. This frees the users from needing to know how to operate AUVs and allows them to concentrate on what they need from the mission. Orca is also responsible for monitoring mission execution, maintaining the health of the vehicle, and handling unanticipated events that occur.

Orca was developed based on the idea that it will interface with low-level vehicle control software that is specific to the vehicle being controlled. This low-level architecture (LLA) is expected to provide low-level control theoretic algorithms and handle hard real-time constraints. Orca sends it commands and receives sensor data from it.

In the case of the EAVE AUVs, the LLA is the EAVE layered software architecture [Blidberg & Chappell, 1986], as shown in Figure 1. This LLA is able to accept high-level commands (e.g., ``move to (x,y,z)''), to provide processed sensor data (sometimes by fusing several sensors), to handle some unanticipated events, and to control the vehicle to a limited extent should Orca malfunction or not respond quickly enough. The EAVE LLA was simulated in SMART.

**Figure:** The EAVE software architecture, with Orca.
$\begin{figure} \centerline{\ \psfig {figure=msel-arch3-w-orca.eps,height=4in} }\end{figure}$

Orca is a complex artificial intelligence program. Technically, it can be characterized as a reactive planner [Georgeff & Lansky, 1987, e.g.,] and also as an adaptive, schema-based reasoner [Turner, 1994]. It uses packets of procedural and contextual knowledge, called procedural schemas (p-schemas) and contextual schemas (c-schemas), respectively, to control all facets of its behavior. It is able to change its focus of attention and respond to unanticipated events as the situation demands.

**Figure:** Internal structure of Orca.
$\begin{figure} \centerline{\ \psfig {figure=orca.eps,height=4in} }\end{figure}$

Figure 2 shows a diagram of Orca's components. Event Handler (EH) is responsible for handling input from the LLA, including communication from other AUVs and users. This information is examined to detect unanticipated as well as predicted events. Processing goes on here, as well, to convert the incoming information into the appropriate knowledge in Orca's working memory. All mission-related and other tasks are represented as goals on Orca's agenda. Agenda Manager (AM) is responsible for maintaining an appropriate focus of attention--that is, for deciding which goal(s) to work on at any given time. Schema Applier (SA) is responsible for deciding which actions to take to achieve the goal in focus. It does this by retrieving appropriate procedural schemas from the long-term memory based on features of the goal and the situation, then interpreting these schemas to issue commands to the LLA and to do other, internal, actions. A communication module (not shown) handles vehicle-to-vehicle and user-to-vehicle communication.

The context manager, ECHO (Embedded Context-Handling Object) [Turner, 1998], is responsible for maintaining Orca's sense of what its current context is. It does this by retrieving contextual schemas from the long-term memory based on features of the situation, then merging these c-schemas to form a coherent picture of the context. Knowledge contained in the c-schemas is used to handle unanticipated events (by sending EH context-specific knowledge about how to detect, assess, and respond to them), maintain the focus of attention (by sending AM information about context-specific goal priorities), decide how to achieve goals (by sending SA suggestions for context-specific p-schemas for goals), and interpret the situation (by providing all modules with predictions about the world given the assessed context and by suggesting context-specific ontology changes). ECHO also provides appropriate standing orders for the context, that is, goals and parameter settings that should be in force due to being in the current context. These include parameter settings for the LLA (e.g., turn off obstacle avoidance behavior when docking, etc.).

Though Orca was developed with an eye toward controlling EAVE vehicles, we intend Orca to be a general-purpose agent controller. Consequently, in addition to testing Orca's ability to control simulated and real EAVEs, we also want to test its ability to control other kinds of agents, including other AUVs, land vehicles, and software agents. Orca was designed as a standalone reasoner, but we intend it to be useful in multiagent, cooperative distributed problem-solving systems as well. Consequently, we want to test its ability to control vehicles and other agents in a multiagent setting.

In addition to testing Orca's abilities, it is hoped that by using Orca to control several different kinds of agents, we will be able to expose inappropriate assumptions we made in the design of the program and to extend its capabilities.

Test Platforms

To begin testing Orca's ability to control multiple kinds of agents, we selected two test platforms, one a high-fidelity simulation of an AUV, the NPS Underwater Virtual World, and another an actual robot, the Pioneer 1 land robot.

NPS Underwater Virtual World

Don Brutzman's brutzman95 Underwater Virtual World is a high-fidelity simulation of the Navy Postgraduate School's Phoenix AUV [Brutzman et al., 1998] operating in a realistic environment. The version of the UVW we used runs on two Silicon Graphics computers. Figure 3 shows a screen shot of the UVW. Locally, we created a Java-based network client to help Orca, which is written in Lisp, communicate with the simulated Phoenix.

**Figure:** Screen shot of the NPS UVW.
$\begin{figure} \centerline{\ \psfig {figure=phoenix.ps,height=4in} }\end{figure}$

Phoenix has a layered software architecture. Ideally, Orca would replace the topmost level and communicate directly with the tactical level. This would give it control of the vehicle at roughly the same level as it expects when controlling the simulated EAVEs. However, at the time the work was done, the tactical level was not available. Consequently, we interfaced with the lowest level of the hierarchy, the execution level. This is actually a benefit, however, since this allows us to test Orca's ability to control a vehicle that does not have significant high-level control available.

Pioneer 1 Robot

The Pioneer 1 robot (see Figure 4), from ActivMedia Robotics, is a small, inexpensive land robot. It is controllable from a variety of platforms using either a serial cable or a radio modem. For our tests, we used a radio modem connected to a Sun SPARCstation.

**Figure:** The two UM Pioneer 1 robots.
$\begin{figure} \centerline{\ \psfig {figure=two-pioneers-3in.ps} }\end{figure}$

The Pioneer robots come with a sophisticated interface and programming environment, Saphira [Konolige et al., 1997]. Locally, we created a Lisp-based interface to Saphira. Orca then communicated Saphira using that mechanism.

Interface Issues

Our approach to interfacing Orca to the things it is controlling involves creating a low-level architecture interface to sit between Orca and the other software and hardware. This allowed Orca to be written without regard for the details of the ``body'' it would be inhabiting.

In its original incarnation in SMART, the LLA interface was very simple and relied on being embedded in a particular simulation environment. For example, communication between the simulated AUV LLA architecture and Orca was handled by simple message queues, and execution of all parts of the system was synchronous with ``clock ticks'' from the simulator controller. This obviously would not work with other simulators, much less with a real robot.

Our approach is to create an interface for each LLA Orca is to control. At the current time, these are: the EAVE/SMART interface, for when Orca controls a simulated EAVE in SMART; the Phoenix interface, for controlling a Phoenix AUV in the UVW; and the Pioneer interface, for controlling a Pioneer robot. Orca is written in Common Lisp and CLOS; the interfaces are as well. Consequently, each interface is written as a CLOS class with associated methods. All three classes are related and built on a common class that provides some instance variables and methods needed by all three. When Orca is to control a particular vehicle, simulated or otherwise, the appropriate LLA interface is instantiated for it. Figure 5 shows a diagram of the Phoenix interface. The Pioneer interface is similar.

**Figure:** The Phoenix LLA interface.
$\begin{figure} \centerline{\ \psfig {figure=lla-interface.eps,height=4in} }\end{figure}$

Several issues arise when designing an LLA interface, ranging from prosaic to challenging. The simplest to handle is the mechanics of communicating with the target platform. The LLA interface can continue to communicate with Orca via message queues, one for input to Orca and one for commands from Orca, but now it must communicate with software it is not so tightly integrated with. For the interface to Phoenix, we used Unix sockets. The LLA interface opens a socket to a Java client, which communicates with the simulated Phoenix's execution level software via another socket. For the Pioneer interface, communication is via subroutine calls to Saphira functions, which in turn communicate with the robot.

Orca needs to know the current time for various reasons, and how it gets the time differs depending on what it is controlling. When controlling a simulated EAVE in SMART, it can directly access the global simulated time. For Phoenix, however, this will not work. Instead, its time needs to agree with the Phoenix's time. For Pioneer, time agreement doesn't matter; neither Saphira nor Pioneer needs to know the time. Consequently, Orca is free to use its own computer's clock.

To isolate Orca from its computational environment, we made time-keeping a function of the LLA interface in all cases. Orca always asks the interface for the time when it needs it. The EAVE/SMART interface returns SMART's simulation time, the Phoenix interface uses time information included in Phoenix's telemetry, and the Pioneer interface can just use Lisp's time function.

Much of the functionality of the LLA interface consists of ``impedance matching'': translating the representation of sensor information, vehicle status information (telemetry), and commands from one agent (e.g., Orca) to the other (e.g., Phoenix). This is handled in the Phoenix and Pioneer interfaces by a telemetry translation function.

The LLA interface has associated with it a process that is responsible for most of what the interface does. (Lisp processes are more accurately thought of as threads.) This process sleeps until there is information available on the socket or until a housekeeping timeout occurs. When there is telemetry information available, one of the things it does is to replace the stored telemetry with the new value so that the most current telemetry is always available. At periodic intervals, it translates the telemetry and delivers it to Orca via a message queue. For example, Phoenix's velocity is reported as three telemetry values, x-dot, y-dot, and z-dot; these are combined and delivered to Orca as:

(velocity x-dot y-dot z-dot)

The message queue decouples the two processes, the LLA interface's and Orca's Event Handler, allowing them to each run at their own speed.

At the present time, only telemetry values such as position and velocity are handled by the interfaces. Both Phoenix and Pioneer provide sensor information (e.g., sonar) as part of what we are here loosely calling ``telemetry''. In the near future, we will add functionality to the interfaces to handle this information as well.

Orca's commands must also be translated by the interface and delivered in a reasonable manner. Orca has a set of general commands it uses to control the vehicle it is a part of. These are not in principle fixed, but neither do we want to modify Orca's command set to match every vehicle or agent it is controlling. Some commands (e.g., (move-to (x y z))) are useful across a wide range of vehicles, even though the vehicle commands they correspond to may vary widely.

The problem is somewhat more complex than simply translating from one command format to another. Some of Orca's commands may, for example, have to be translated into more than one vehicle command. For example, the Orca command:

(MOVE-TO-DEPTH 5)

is currently translated into two commands for Phoenix: DEPTH 5 and HOVER. Another Orca command, currently not handled, MOVE-WAYPOINTS, would need many Phoenix commands, at least one per waypoint.

To handle this, the LLA interface process translates incoming commands into objects that are then placed on a queue of commands. These objects contain information about what LLA commands are needed to carry out the corresponding Orca command. Each time the LLA is ready to accept a command, the interface sends one of the LLA commands from the object at the head of the queue. When there are no more commands for the object, it is removed from the queue and Orca is notified that the command is done.

In some cases, commands that may be reasonable for some vehicles might not be readily translatable to a sequence of commands for another. For example, EAVE has some ability in its LLA to carry out search patterns; Pioneer does not. It may make sense for Orca to have a ``lawnmower search'' command that corresponds to one of EAVE's search patterns. However, it would be needlessly complex to make the Pioneer interface carry this out. It would make more sense in this case to have Orca, when it is controlling a Pioneer, directly control the lawnmower search by means of a procedural schema and issuing lower-level commands to Pioneer.

It is easy to determine when one of Orca's commands has been carried out: all of the LLA commands have completed successfully. But how do we know when a LLA command has completed?

For some vehicles (e.g., the simulated EAVE), the LLA can tell the interface when the command is finished. For other vehicles, this is not the case. For these, the LLA interface must monitor the telemetry to decide when the command has finished. This is done in the Phoenix and Pioneer interfaces by their processes; when telemetry is received, the process checks command completion. For each LLA command, a corresponding function must be provided to be called to determine if the command is done. For example, the command to move to a particular depth is considered done when the AUV is near that depth, where what ``near'' means is settable by Orca.

Other issues have not yet been addressed in our work. For example, Orca normally checks its input only every five seconds, for two reasons: we expect it to sit atop a complex, competent LLA that will handle events requiring faster responses; and Orca's current event handling mechanism is CPU intensive and rather slow. Though this cycle time is sufficient for the EAVE/SMART interface, and seems to be for Phoenix, it definitely will not be for Pioneer. We will need to experiment with input cycle times to determine what is appropriate for each vehicle.

We have also not addressed the need to handle multiple simultaneous commands. For example, Orca may direct the AUV to move to a location a kilometer away, then take data samples as the vehicle transits. At the moment, the Phoenix and Pioneer interfaces use a queue for outgoing commands, which restricts the commands that can be executing simultaneously to one. In the near future, we will modify the interfaces to be able to handle multiple simultaneous commands. This will also allow commands that do not, by design, complete (e.g., ``move along this heading until I tell you otherwise'') not to prevent other commands from being executed.

So far, we have not modified Orca's knowledge to fit the vehicle it is controlling; Phoenix, for example, is being controlled by an Orca instance whose knowledge is designed for controlling an EAVE. This will be addressed in the near future for Phoenix, and it will be critical for Pioneer. It will entail changing not only some schemas and commands (e.g., Pioneer does not move in three dimensions, so the MOVE-TO command will need to be modified), but also Orca's basic concepts relating to who it is, that is, what ``body'' it has. By the time of the symposium, we should have made significant progress on this.

Status and Future Work

At the time of writing, Orca can control a simulated Phoenix in the UVW to a limited extent. A version of the Pioneer interface was built as a student project in late 1998. That version, which is very similar to the Phoenix interface, was able to accept commands from Orca and send them to the Pioneer robot. It was never tested with Orca interpreting schemas in normal operating mode, since that version of the interface was missing command completion code. Work is underway to upgrade the Pioneer interface to bring it up to the level of the Phoenix interface. Lessons learned while building the Phoenix interface should help speed this process along.

The ultimate goal is a set of LLA interfaces for targets of interest that will allow us to test Orca as it controls a variety of vehicles in a variety of environments. There are several areas for future work relating to this goal:

Finish Pioneer interface.

The Pioneer interface needs to be upgraded to at least the level of the Phoenix interface. In addition, the current interface uses very low-level commands to control the robot. Other, higher-level commands are available by interfacing with the software provided with the robot. This software also provides sophisticated sensor interpretation routines. We will investigate interfacing with this software to allow Orca to have a more capable LLA to work with. However, it will be instructive to have Orca control Pioneer without these capabilities. This will help give us a range of vehicle and LLA capabilities to experiment with.

Addressing remaining interface issues.

The issues mentioned above that remain to be addressed will be the subject of future work.

Extend LLA interfaces.

The LLA interfaces need to be extended to allow interaction with sensors (and, ultimately, effectors). This should not be difficult. The major effort will likely be giving Orca the knowledge necessary to handle the sensor input and to control the sensors (and effectors).

Interfacing to CADCON.

Our colleagues at AUSI have developed a distributed simulation testbed, called CADCON [Chappell et al., 1999], that can simulate a variety of vehicle types, including crawlers, ``copters'' (vehicles that have roughly the maneuverability of a helicopter, such as EAVE), torpedo-shaped vehicles, and so forth. CADCON can simulate multiple vehicles operating simultaneously. We would like to develop LLA interfaces to allow Orca to control these vehicles. Not only will this provide us with additional tests of Orca's abilities, but it will allow us to test Orca as a controller of agents in a multiagent system. This will benefit related projects, in particular, CoDA [Turner & Turner, 1998], whose goal is to develop distributed intelligent control mechanisms for autonomous oceanographic sampling networks.

Exercise and extend Orca.

The major motivation for this work has been to further develop and test Orca, with the ultimate goal of fielding Orca aboard an AUV to conduct useful missions. By experimenting with having Orca control a variety of different vehicles, we can identify its shortcomings and where it needs to be extended. We can identify the part of Orca's knowledge that needs not change from vehicle to vehicle and that part that is vehicle-dependent.

Developing the interfaces gives us experience that will be critical when interfacing Orca to real hardware. Indeed, the interfaces we are developing will most like be able to control real hardware; in the case of the Pioneer interface, it already does.

References

Blidberg & Chappell, 1986: Blidberg, D. R. & Chappell, S. G. (1986).
Guidance and control architecture for the EAVE vehicle.
IEEE Journal of Oceanic Engineering, OE-11(4):449-461.
Brutzman, 1995: Brutzman, D. (1995).
Virtual world visualization for an autonomous underwater vehicle.
In Proceedings of the IEEE Oceanic Engineering Society Conference OCEANS 95, pages 1592-1600, San Diego, CA.
Brutzman et al., 1998: Brutzman, D., Healey, T., Marco, D., & McGhee, B. (1998).
The Phoenix autonomous underwater vehicle.
In Kortenkamp, D., Bonasso, P., & Murphy, R., editors, AI-Based Mobile Robots, chapter 13. MIT/AAAI Press.
Chappell et al., 1999: Chappell, S. G., Komerska, R. J., Peng, L., & Lu, Y. (1999).
Cooperative AUV Development Concept (CADCON) - an environment for high-level multiple AUV simulation.
In Proceedings of the 11th International Symposium on Unmanned Untethered Submersible Technology (UUST99), Durham, NH. The Autonomous Undersea Systems Institute, Lee, NH.
Curtin et al., 1993: Curtin, T., Bellingham, J., Catipovic, J., & Webb, D. (1993).
Autonomous oceanographic sampling networks.
Oceanography, 6(3).
Georgeff & Lansky, 1987: Georgeff, M. P. & Lansky, A. L. (1987).
Reactive reasoning and planning: An experiment with a mobile robot.
In Proceedings of the Sixth National Conference on Artificial Intelligence, pages 677-682, Seattle, Washington.
Konolige et al., 1997: Konolige, K., Myers, K., Ruspini, E., & Saffiotti, A. (1997).
The Saphira architecture: A design for autonomy.
Journal of Experimental and Theoretical Artificial Intelligence, 9(1):215-235.
Lawton et al., to appear: Lawton, J. H., Turner, R. M., & Turner, E. H. (to appear).
A unified long-term memory system.
To appear in the Proceedings of the International Conference on Case-Based Reasoning (ICCBR'99), Monastery Seeon, Munich, Germany, July, 1999.
Turner, 1994: Turner, R. M. (1994).
Adaptive Reasoning for Real-World Problems: A Schema-Based Approach.
Lawrence Erlbaum Associates, Hillsdale, NJ.
Turner, 1998: Turner, R. M. (1998).
Context-mediated behavior for intelligent agents.
International Journal of Human-Computer Studies, 48(3):307-330.
Turner et al., 1991: Turner, R. M., Fox, J. S., Turner, E. H., & Blidberg, D. R. (1991).
Multiple autonomous vehicle imaging system (MAVIS).
In Proceedings of the 7th International Symposium on Unmanned Untethered Submersible Technology (AUV '91), pages 526-536, Durham, NH.
Turner & Stevenson, 1991: Turner, R. M. & Stevenson, R. A. G. (1991).
ORCA: An adaptive, context-sensitive reasoner for controlling AUVs.
In Proceedings of the 7th International Symposium on Unmanned Untethered Submersible Technology (UUST '91), pages 423-432.
Turner & Turner, 1998: Turner, R. M. & Turner, E. H. (1998).
Organization and reorganization of autonomous oceanographic sampling networks.
In Proceedings of the 1998 IEEE International Conference on Robotics and Automation (ICRA'98), pages 2060-2067, Leuven, Belgium.

About this document ...

Interfacing the Orca AUV Controller
to the NPS UVW and to a Land Robot

This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)

The command line arguments were:
latex2html -split 1 -font_size 10pt -no_navigation -local_icons body.tex.

The translation was initiated by Roy Turner on 7/7/1999

Roy Turner
7/7/1999

Interfacing the Orca AUV Controller to the NPS UVW and to a Land Robot

Abstract:

Interfacing the Orca AUV Controller
to the NPS UVW and to a Land Robot