Development of a real-time control architecture for a semi-autonomous underwater vehicle for intervention missions

ARTICLE IN PRESS

Control Engineering Practice 12 (2004) 1521–1530

Development of a real-time control architecture for a semiautonomous underwater vehicle for intervention missions T.W. Kim*, J. Yuh Autonomous Systems Laboratory, Department of Mechanical Engineering, University of Hawaii, 2540 Dole St. Holmes 302, Honolulu, HI 96822, USA Received 24 October 2003; accepted 20 December 2003

Abstract The need for autonomous underwater vehicles (AUVs) for intervention missions becomes greater as they can perform underwater tasks requiring physical contacts with the underwater environment, such as underwater plug-in/plug-out, construction and repair, cable streaming, mine hunting, munitions retrieval, and scientific sampling. This paper describes a semi-autonomous underwater vehicle for intervention missions that has multiple on-board CPUs, redundant sensors and actuators, on-board power source and a robotic manipulator for dextrous underwater performance. Such a complex robotic vehicle system requires advanced control software architecture for on-board intelligence with a wide range of sensors and actuators to carry out required missions. In this paper, AUV control architectures are reviewed and a sensor data bus based control architecture (SDBCA) is presented. SDBCA is a modified hierarchical architecture that offers good controllability and stability while sensor data bus increases flexibility of system design, making it possible to have a prompt response from high-level control with respect to low-level sensor data. The overall sensor input mechanism of SDBCA becomes similar to the sensor input mechanism of subsumption architecture. r 2004 Published by Elsevier Ltd. Keywords: Autonomous underwater vehicle; Control architecture; Real-time control; Distributed system

1. Introduction The underwater community has recognized immediate needs for improving undersea intervention capabilities in terms of autonomy, cost-effectiveness, and performance. Various underwater intervention tasks include underwater plug-in/plug-out, construction and repair, cable streaming, mine hunting, munitions retrieval, and scientific data gathering. Most underwater vehicles currently used for intervention missions are either manned submersibles or remotely operated vehicles (ROVs) with manipulators. The ROV operation is very expensive and often faces many safety issues. Furthermore, its performance in terms of accuracy, speed, and efficiency, often suffers from human operator fatigue and the time delay in the man–machine control loop in a hazardous and unstructured environment. Autonomous underwater vehicles (AUVs) incorporated *Corresponding author. Tel.: +1-808-956-2863; fax: +1-808-9562373. E-mail addresses: [email protected] (T.W. Kim), [email protected] (J. Yuh). 0967-0661/$ - see front matter r 2004 Published by Elsevier Ltd. doi:10.1016/j.conengprac.2003.12.015

with robot arms have received great attention for various intervention tasks requiring physical contacts with the environment (Mahesh, Yuh, & Lakshmi, 1991; Angeletti et al., 1998; Lee & Yuh, 1999; Kim, Choi, Lee, West, & Yuh, 2000). Recent advances in sensors, communication, computers, and machine intelligence have made it possible to design more sophisticated AUVs. However, most AUVs are still fly by types with limited capabilities for limited applications, such as survey, observation, and search (Yoeger, Bradley, & Walden, 1991; Bellingham & Chryssostomidis, 1993; Ito et al., 1994; Dunn, Smith, Betzer, & Hopkins, 1995; Sousa, Cruz, Matos, & Pereira, 1997; Martins, Matos, Cruz, & Pereira, 1999; Bennett & Leonard, 2000; Kondo, Yu & Ura, 2001; Ura et al., 2002). Most underwater intervention missions require physical contacts with the surrounding and therefore encounter a high level of risk in damage to the overall system. Physical contacts with the surrounding present a highly complicated dynamic problem and the coupled hydrodynamic motion of the vehicle and manipulator. Those missions often require dexterous operation of the vehicle and manipulator with

ARTICLE IN PRESS 1522

T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

force/torque feedback in the presence of external disturbances, such as currents. All these issues compounded with insufficient on-board intelligence present very challenging problems that have impeded the development of fully autonomous and reliable AUVs, especially for intervention missions. As mentioned before, ROVs equipped with manipulators are generally utilized for undersea intervention missions. These systems have a human pilot on the surface mother-ship and tele-operate the sub-sea robot via an umbilical cord. Usually, outfitted with minimal automation such as auto-heading, the ROV and its manipulator are directed by the human pilot using a master–slave joystick controller with video and sonar displays of the local environment. Tasks requiring high accuracy and precision become tiring and time consuming to perform. In some cases, these operations fail even after several attempts due to the divergence between human and machine dexterity, and the cost of these operations drastically increase (Yuh, 1996). As a pioneering effort, the Autonomous Systems Laboratory of the University of Hawaii has proposed and is in the midst of developing a semi-autonomous underwater vehicle for intervention missions (SAUVIM). This vehicle differs from many AUVs presently in the commercial, military, and scientific arenas. Unique features are a fully functional robotic manipulator and a supervisory controller capable of communication with a land-based station that monitors and intervenes the vehicle-manipulator system if and only if the given operation strays. If the operation is working accordingly, the vehicle’s CPUs carry out the mission autonomously based on initial parameters. AUV systems like SAUVIM require a layered structure in hardware with redundancy and different bandwidths of subsystems, including various navigation sensors, mission sensors, system sensors, multiple thrusters and actuators, multiple CPUs, and power sources. One of the key elements to achieve successful operation of such a system is advanced control software architecture, addressing various issues such as controllability, stability, response time, communication, data management, and modularity. This paper focuses on control software architecture especially designed for the SAUVIM with the overall description of the SAUVIM.

2. AUV control architecture Control software architecture is a critical component in managing a wide-range of sensors and data flow, providing the on-board intelligence, monitoring the system, keeping the system integrity to make real-time, on-board decision-making, and autonomously performing required missions. Various AUV control architectures have been discussed in the literature (Hall &

Adams, 1992; Blidberg & Turner, 1995 (Chap. 5); CosteManiere, Wang, & Peuch, 1995; Caccia, Virgili, & Veruggio, 1995; Valavanis, Gracanin, Matijasevic, Kolluru, & Demetriou, 1997; Ridao, Batlle, Amat, & Roberts, 1999; Ridao, Yuh, Batlle, & Sugihara, 2000). They can be grouped into three main architectures: hierarchical, behavioral, and hybrid architectures. Hierarchical architecture is also known as deliberative architecture. Data from sensors are sent to the world model. The world model is updated and decisions are made based on the sensory data, the given mission, and information stored in the database. The new action commands are then sent to the actuators. This architecture is excellent in controllability and stability while it is inflexible and often presents a delay in the response time in a highly dynamic environment. Hall and Adams (1992) proposed a hierarchical planner arranged in three homogeneous layers. The upper layer is in charge of the mission planner while the lower one is responsible for issuing commands to the actuators. Wang, Marks, and Rock (1993) described an architecture applied to an underwater vehicle, OTTER. It has a three level control structure including a task level. The task level handles common tasks such as ‘‘go there’’ and ‘‘track that object’’, dealing with basic functions that have been planned as a sequence of orders. Barnett, McClaran, Nelson, McDermott, and Williams (1996) proposed AUV controller for an AUV, which has three hierarchical levels: planning level, control level and diagnostic level. The planner selects a predefined plan or creates a new plan based on the boundary conditions of the mission, then the plan is transferred to the control layer. The algorithmic modules then execute it and invoke re-planning procedure if the deadlines or restrictions of the mission are violated. Behavioral architecture (Arkin, 1998; Brooks, 1999; Pfeifer & Scheir, 1999) is also known as reactive or heterarchical architecture. The mission is usually described as a sequence of phases with a set of predefined ‘‘behaviors’’. The ‘‘behaviors’’ are based on the sensereact principle. Therefore, this architecture is very good for dynamic environments while it could be unpredictable as the active behaviors may have conflicts with each other and cause deviation from achieving the goal. Heterarchical architecture often results in heavy data/ communication traffic. While no example of pure heterarchical architecture-based AUV can be found, there have been a few approaches based on the subsumption technique (Brooks, 1999). Bellingham and Chryssostomidis (1993) proposed the subsumption architecture to the Sea Squirt AUV. They isolated the actuator control and the sensor code from the control layer and avoided inter-layer communication to ease the scalability. They also extended the arbitration mechanism proposing the masking. Instead of issuing actions to the actuators, the behaviors issue a set of actions called

ARTICLE IN PRESS T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

masks, and then the solving-trouble protocol chooses the best action. Zheng (1992) introduced the cooperation concept within a subsumption-like control architecture. The cooperation feature is closely connected to sharing actuators between behaviors. Two behaviors cooperate when they can be combined in a suitable way. He also used a layered sensing sub-system dealing with fault tolerance. Boswell and Leaney (1994) applied a layered control architecture to the Eric underwater robot, introducing protected modules (modules which should never be subsumed), devices (modules which specify physical devices), and hormone emitters (modules which send a ‘‘hormone level’’ affecting dependent behavior modules). The distributed vehicle management architecture (DVMA) was presented by Fujii and Ura (1996). In their scheme, missions are defined as a sequence of different behaviors. The basic idea is that a behavior can be created by a combination of specific functions given to the robot and a mission is accomplished by the robot performing sequentially appropriate behaviors. It has three levels, that are a hardware level, a function level, and a behavioral level. Recently, Rosenblatt, Williams, and Durrant-Whyte (2000) have applied the distributed architecture for mobile navigation (DAMN) to the Oberon submersible. Its main feature is the coordination mechanism which is a competence scheme using a voting mechanism to select an appropriate action. Carreras, Yuh, and Batlle (2001, 2002) proposed a hybrid methodology for reinforcement learning-based behavior coordination for AUVs. Hybrid architecture (Gat, 1998 (Chap. 8)) takes advantage of the two previous architectures while minimizing their limitations. Bonasso (1992) presented the situated reasoning architecture applied to the Hylas underwater vehicle. Using a special-developed language GAPPS/REX, goals can be specified logically and can be compiled into runtime virtual circuits, mapping sensor information into actuator commands while allowing parallel execution. Behavior coordination follows a competitive approach. The architecture also includes a deliberative layer. The RBM architecture developed by Healey, Marco, and McGhee (1996) is organized in three levels: Execution level, Tactic level, and Strategic level. Complex behaviors can be readily coordinated through Strategic level rules which act as state transitioning mechanisms and the communication through Tactical level software to the Execution level controllers is a simple and convenient way of commanding competent functions of the vehicle. Choi, Yuh, and Takashige (1995) presented an architecture for the ODIN AUV. It uses a supervisor to handle mission parameters on the basis of lower-level information and three separate blocks: Sensory database, Knowledge base, and Planner. Each block has multi-layers, demonstrating an increase in intelligence with the increase in the number of layers. Valavanis et al. (1997) presented

1523

an AUV control system architecture as well as the concept of goal-oriented modules. The state-configured embedded control architecture is based on a two-level hybrid control architecture, consisting of a supervisory control level and a functional control level. This architecture uses a master controller (MC) to coordinate the operation of the AUV by transferring control actions among several functionally independent modules.

3. SAUVIM hardware architecture This section describes the overall hardware of the SAUVIM vehicle being developed at the autonomous systems laboratory of the University of Hawaii. The SAUVIM specifications are shown in Table 1. SAUVIM’s maximum design depth is 6000 m. The vehicle weighs about 6500 kg in air and –2 kg in water. It measures approximately 6.1 m long, 2.1 m wide, and 1.8 m high with a fiberglass fairing. Its internal structural frame is made of aluminium 6061. SAUVIM has six 0.33 m(1300 ) inner diameter  0.46 m (1800 ) long cylindrical pressure vessels that contain all electronics, computers, and some sensors. Since SAUVIM was designed to conduct underwater tasks, it has an electric brush-less motor-driven dexterous robotic manipulator. The overall vehicle-manipulator system is a high degrees-of-freedom (DOF) multi-body system including the coupling effect of the vehicle and manipulator motion. It also has a passive arm as a position/ orientation feedback sensor with respect to the object during underwater manipulator operation. The manipulator and passive arm will be retracted into the vehicle’s fairing during cruising operations. Once the vehicle reaches its workspace, the passive arm sensor and other on-board sensors will provide vehicle’s relative position information to the worksite while the manipulator performs its tasks. The SAUVIM hardware has distributed architecture in which processing nodes are connected through Ethernet and VME-bus for soft realtime and hard real-time tasks, respectively. The distributed architecture allows us to use a wide range of hardware configurations. Any size or type of computer can be used for each processing node as long as they satisfy performance specifications. To build an open distributed system, no specific hardware platform is defined for the controller. However, each processing node and component should be selected based on industrial standards and reliability requirements. The hardware configuration of the SAUVIM system is shown in Fig. 1. 3.1. On-board CPU systems The SAUVIM controller is mainly composed of two VME bus systems; one is for navigation and sensor

ARTICLE IN PRESS 1524

T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

Table 1 Specification of SAUVIM Specifications

SAUVIM

Hull and frame

Length : 6.1 m, Height : 1.8 m, Width : 2.1 m, high-density composite fairing with a clear acrylic nose cone mounted on an open Al frame. Dry est.: 6500 kg, Wet est. : 2 kg at 6000 m. Cruising : Dorsal and bow mounted control rudders; Station Keeping : (8) 23 kg thrusters. Direct drive brushless motor (8 thrusters for instantaneous movement). Inherently built-in redundancy. Cruising speed 3 knots (maximum) 46 kg for 1 h Thruster : Deepsea batteries at 5000 w-h CPU : Deepsea batteries at 2500 w-h Robotic Arm : Deepsea batteries at 2500 w-h 2.7 nautical miles Six cylinders 0.33 m ID  0.46 m long; sized for standard 6U VMEbus; one pressure vessel port (MSP size) which can be replaced with a specialized mission package by the end-user. 6,000 m 7 degrees of freedom, 1.4 m reach, grip capacity 8.0-kg lift at a full extension. (3+) MC68060 computers mounted in two separate 6U VMEbus with communication; crossed wired to handle half of the sensors and thrusters; 8MB RAM; 4MB Flash EPROM (5+) Pentium-based PC-104+ for various sensor; (6+) BASIC STAMP II/sx micro-controller for Health Monitoring System; (5+) Rabit 2000 micro-controller for stepper motor control 3 rotations (roll, pitch, yaw) accelerometer INS system for Navigation CPU, lower cost system for Arm CPU 7 unidirectional sonars and 2 scan sonar units, 2–100 m. Laser with controllable beam system; passive arm; and passive optical homing system.

Weight Control and propulsion Drive Speed Lift Power supply

Range Pressure vessel Depth rating Manipulator 1 Main-computer Micro-controllers Attitude and angular rate Collision and altitude sonar Short distance positioning and ranging Depth Video imagery Monitoring system

(2) Absolute pressure sensors 0–10,000 psia. Redundancy via long-base sonar. (6) Vehicle mounted, low lux color cameras with auto iris; (1) Arm mounted color wide angle camera with auto iris; (5) flood lights. A graphic, visualization system via PC. Capable of monitoring and limited supervisory control.

processing, the other one is for 7 DOF manipulator control. They communicate with each other through Ethernet. Five additional Pentium-based PC/104+ CPU boards are used for sensor data processing that often becomes heavy computational loads, such as image processing for CCD cameras and scanning sonar with high-speed serial communication up to 115.2 Kbps. Two MC68060-based CPU boards (Force SYS68K60D; FORCE Computers, 1997), and four PC/104+ boards (Lippert, 2001) are contained in a navigation pressure vessel. Two multifunctional analog and digital I/O boards, MD-DAADIO (MATRIX Corporation, 1997) that consists of 64 channels ADC, 16 channels DAC, and 96 channel DIO, are used for interfacing with input sensors and output actuators. The intelligent serial communication board, MVC16 (Macrolink, Inc., 1992), has 12 RS-232C channels, 4 RS485 channels with its own control DSP. The MVC16 may be driven with an interrupt service routine, and thus the 16 serial ports can simultaneously acquire data. The board contains 128 Kbytes of buffers for efficient data handling and direct memory access. The Force SYS68K-60D CPU board uses some part of the on-board DRAM as a shared memory. Two main processors of the vehicle navigation controller are synchronized with the shared semaphore and memory

via VME bus. These two processors are also connected with each other via Ethernet. The VME bus interface I/O boards can be accessed by both of the processors. An additional memory board will be installed for the data storage and the external shared memory. The Navigation CPU I in Fig. 1 is a primary CPU board with four main functions: (1) It handles interprocess board communication, (2) it reports the status of the vehicle to the ground station using Ethernet or acoustic communication link, (3) it performs high-level control; it plans tasks based on task description language and sends commands to the secondary navigation CPU or the robot arm CPU, and (4) it responds to some fault situations. Although the secondary navigation CPU handles most of the fault situations, the primary CPU has minimal fault handling functions in case of failure of the secondary CPU. If an emergency occurs, it checks the status of the secondary navigation CPU and performs fault-handling routines in the case of the secondary CPU malfunctions. The Navigation CPU II is the secondary navigation CPU with three main functions: (1) It performs low-level control. It acquires data from sensors and sends command signals to actuators. (2) It sends acquired data to a shared memory on the primary navigation CPU, and (3) it has self-diagnostic and fault tolerance

ARTICLE IN PRESS T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

1525

Fig. 1. The overall hardware architecture of the SAUVIM.

routines. It monitors the vehicle’s status such as leakage, battery level and pressure level. If any signal exceeds the desired range, it automatically performs emergency handling routine (e.g. releasing weight) without commands from the primary CPU. 3.2. SAUVIM thrusters SAUVIM has eight thrusters. Four Technodyne Model 1020 thrusters are used for the vertical motion while two Technodyne Model 1020 and two Technodyne Model 2010 thrusters are used for the horizontal motion. It also has three fins with stepper motors. SAUVIM was designed to have a maximum speed of 3 knots and an operating range of about 2.7 nautical miles. 3.3. SAUVIM sensors The sensor suite used for navigation includes a 300 kHz RD instruments navigator Doppler velocity

logger (DVL) that measures the vehicle speed and attitude from the sea floor and magnetic heading, respectively. Angular rates and accelerations are measured using a Watson IMU. While surfaced, global positioning system (GPS) is used to correct any navigation error accumulated during underwater tasks. For redundancy, SAUVIM has TCM2 and a Mission Sensor Package that also provide attitude information. For the accurate position feedback, ultra short base line (USBL) will be used. The health monitoring system (HMS) was developed to monitor the status of pressure vessels that contain electronics and sensors. It monitors the battery power level, and any leakage, pressure, and humidity in pressure vessels. HMS has its own power. Six HMS’s are wired with RS-485 that supports multi-drops. Two Imagenex 881 high-resolution scanning sonars are used for obstacle avoidance, local mapping, and target acquisition. The sonar head can scan continuously 360 of rotation or swept through a defined angular sector. Two scanning sonars are used for

ARTICLE IN PRESS 1526

T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

forward and backward directions at the nose and the tail of the vehicle, respectively. The vehicle is equipped with seven Tritech PA200 range sonars for obstacle avoidance and local mapping. They can measure the distance between the vehicle and the object. Six fixed focus wide-angle CCD cameras were installed around the vehicle to monitor and record the environment. These video signals are fed into a frame grabber plugged in a PC/104+ CPU board and saved as files. 3.4. SAUVIM robotic manipulator The robot manipulator control system has its own pressure vessel and power. The robot controller uses one Force SYS68K-60D board as a processor board. A PC/ 104+ board is used for the homing device with CCD camera. The overall robot control system communicates with the navigation control systems via Ethernet. The same analog and digital I/O board, MD-DAADIO, is used to control seven brushless DC motors of the arm. Two IP quadrature counters (SBS GreenSpring, 1995) were installed on a carrier board for detection of seven resolver signals from the motor and one encoder signal of a gripper hall sensor. A 6 DOF force/torque sensor, JR3 (JR3 Inc., 1994), is attached on the wrist of the robot arm to measure contact force between the robot gripper and the object. The frequency bandwidth of the arm controller is programmable in the range of 100 Hz–1 kHz, while the vehicle is determined to be about 3–10 Hz.

4. SAUVIM control software architecture The SAUVIM control software architecture, Sensor data bus based control architecture (SDBCA) has a modular, flexible structure for any modification or additions. With the open architecture, it is possible to use any vendor’s hardware. Each module can be controlled with minimum interface with others. Thus, almost all of the software modules can be easily rebuilt or replaced for upgrading or testing like hardware components. Each module follows its own specification to maintain the specific software/control architecture. The overall architecture consists of three layers, application layer, realtime layer, and device layer, as shown in Fig. 2. The application layer consists of application software, an application integrator, and sub-task modules. Application software includes hardware independent highlevel modules such as user interface, interpreter for task description language, and supervisory control algorithm for SAUVIM. The actual processing module for application software is a sub-task module that includes

Fig. 2. Hierarchical control architecture for the SAUVIM.

all software modules for high- and mid-level processing. The application integrator is in charge of the connection between the application software and the sub-task modules by using a task managing method such as the creation and deletion of tasks, and the communication and synchronization between tasks. The real-time layer consists of a system configurator, a real-time operating system, and some parts of sub-task modules. The main role of a system configurator is mapping between hardware-independent application software and real hardware-related modules. The device layer is the only hardware dependent part. Most of the software modules in this layer are directly connected to hardware to send command data for actuators and to obtain actual data from sensors. But, a virtual device driver is used to emulate hardware or isolate software from hardware. It corresponds to real hardware components. It contains specifications of the real device itself as well as the data acquired during run time. It is also very easy to test whole functionality of software during developing the controller and to guarantee fault tolerant function of the system when some hardware has malfunctions, without occurring error or system down. While the architecture described above is easy to verify controllability and stability and is easy to evaluate the controller performance, it presents lack of flexibility, long response time (sensor input–system action), and difficulty in sensor integration/fusion due to no direct communication between high-level control and low-level peripherals. To overcome these disadvantages, a sensor data bus (SDB) is used to supply a direct

ARTICLE IN PRESS T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

communication channel between low-, mid-, and highlevel layers. With the SDB, urgent sensor signals can be handled in real-time, and other sensor signals can be filtered/fused, according to its criticality, to get reliable clean data. The block diagram of SDB is shown in Fig. 3. To be specific, raw data taken by device driver is handled by system configurator, where urgent hard-realtime data are stored in SDB. Unless it is urgent data, all data is passed to the filter module in order to filter out noise and smooth out fluctuated data. The filtered data are stored in the 2nd layer of SDB. In the final stage, all filtered data are translated, analyzed, and merged into the sensor fusion module to extract reliable and accurate physical data from all sensors. For the implementation of the architecture, the realtime layer in Fig. 2 is divided into two layers in Fig. 4: soft real-time layer and hard real-time layer. The

S

S

S

Fused Data

Soft-Real Time

Filtered Data

Hard-Real Time

Raw Data

Critical Hard-Real Time

*S :Semaphore to control concurrent data access Fig. 3. Structure of sensor data bus.

1527

detailed block diagram of SDBCA can be configured as shown is shown in Fig. 4. Since the overall system has to be real-time, time critical modules are running in the hard real-time layer, of which the cycle time is normally less than 10 ms. Most of vehicle managing and mid-level input/output modules are in the Soft Real-Time layer, of which the cycle time is in between 10 and 100 ms, depends on sensor/actuator response time. It should be noted that although the overall controller has a hierarchical architecture, it can share the whole data, from raw data to fused data, as subsumption architecture or heterarchical architecture can. However, the big difference is that its output is only generated by the output manager with the output of control algorithm, calibration manager, and system manager, according to the control state. Thus, the input–output relationship of SAUVIM controller can be easily analyzed with conventional software analyzing tools. The controller also includes AUV mode and ROV mode modules. When the vehicle is operated in AUV mode, the mission supervisor (MS) sends commands to the language/command interpreter to control the vehicle. When it is in ROV mode, remote control client (RCC) is connected to remote control server to get command through communication links, tethered Ethernet, RF wireless link, or serial link via acoustic modem. If the vehicle is running with a robot arm, it should run station-keeping control. In case a vehicle position change is needed, the arm controller sends a position command to RCC in the vehicle controller.

Fig. 4. Detail block diagram of the SAUVIM navigation control architecture.

ARTICLE IN PRESS T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

1528

Since the RCC has higher priority than the MS, it can always stop or modify commands from MS.

5. Implementation As explained in the Section 3, navigation controllers and manipulator controller are installed in separated pressure vessels. Although these two controllers are separated into their own pressure vessels, they must be corporate to make coordinated movement, which usually requires very time-critical communications. Fortunately, there is no need of hard real-time communications between two controllers in SAUVIM configuration. 10 Mbps Ethernet suffices for transmitting and receiving data between the navigation controller and the arm controller. Overall hardware has been fabricated and tested as shown in Fig. 5. For the navigation controller, there are lots of sensors and actuators to be monitored and controlled, and there is heavy computational load for mission planning, realtime trajectory planning, real-time obstacle avoidance, and task description language interpreter. Thus the whole software structure is divided into two parts for two MC68060 CPU boards; one is mainly application layer, and another is mainly real-time and device layer. And, the shared memory via VME bus is used to guarantee real-time communication between two CPU’s, since the bandwidth of VME bus communica-

tion is eight times faster than normal Ethernet. Although the main parts of each CPU are different, their software structures are maintained as an open architecture. It is remarked that, according to the openness concept, any kind of real-time operating system can be used for SAUVIM controller. However, to get more reliable performance, VxWorks (WindRiver, 1995), of which the performance is already confirmed in the realtime industry, is chosen. Hardware components are also selected by their reputation in the underwater industry, but can be changed to more reliable alternative when they become available. In order to guarantee the real-time processing in each controller and/or CPU, it is necessary to calculate and/ or distribute computational burden in each CPU during run time and analyze switching timing between tasks. A watchdog program is also required to prevent deadlock or system down due to software and/or hardware problems. To confirm reliability and validity of proposed control architecture, SAUVIM has been undertaking shallow water test at the University of Hawaii Marine Center, Snug Harbor, Honolulu, Hawaii, as shown in Fig. 6. Since the SAUVIM is still under development/evaluation, tether is connected for emergency power kill switch, Ethernet and serial communications between the SAUVIM and ground station. An open GL-based SAUVIM monitoring system (SMS) is employed to

Fig. 5. SAUVIM electronics: (a) navigation controller, (b) thruster controller.

Fig. 6. Shallow water test of SAUVIM at the University of Hawaii Marine Center, Snug Harbor, Honolulu, Hawaii.

ARTICLE IN PRESS T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

1529

Fig. 7. Open GL-based SAUVIM monitoring system.

monitor vehicle status as shown in Fig. 7. With SMS, users can monitor and control all sensors and actuators in SAUVIM, such as position, orientation, battery voltage/current, thrusters voltage/current, leakage, depth and sonar data. For the high level control, SAUVIM task description language (STDL) is prepared (Kim & Yuh, 2003), which can increase the flexibility of the vehicle tasks as it does not require any modification of control software for various tasks. With STDL, the user can easily describe a task with various sensor data, and handle multiple actuators. Concurrent tasks and sensor-based event handling are also available with STDL.

6. Conclusions In this paper, simple guide to control architecture selection was discussed. In order to compensate drawbacks of selected hierarchical architecture, SDBCA was presented with a novel modified hierarchical architecture and SDB concept. The SDBCA can adopt advantages of both traditional hierarchical architecture and subsumption architecture: controllability, stability, response time, and communication load. With the open and modular concept, modifiability can be somewhat achieved in the SDBCA as well. In order to verify the proposed architecture, the SAUVIM vehicle has been tested in shallow water as shown in Fig. 6.

Acknowledgements This research was sponsored in part by ONR (N00014-97-1-0961, N00014-00-1-0629, N00014-02-10840) and in part by KRISO, KORDI through MASE Inc.

References Angeletti, D., Bruzzone, G., Caccia, M., Cannata, G., Casalino, G., Reto, S., & Veruggio, G. (1998). AMADEUS: Dual-arm workcell for co-ordinated and dexterous manipulation. Proceedings of OCEANS ’98, Nice, France (pp. 947–952). Arkin, R. C. (1998). Behaviour-based robotics. Cambridge, MA: MIT Press. Barnett, D., McClaran, S., Nelson, E., McDermott, M., & Williams, G. (1996). Architecture of the Texas A&M autonomous underwater vehicle controller. Proceedings of the symposium on autonomous underwater vehicles technology, Monterey, CA, USA (pp. 231–237). Bellingham, J., & Chryssostomidis, C. (1993). Economic ocean survey capability with AUVs. Sea Technology, 34(4), 12–18. Bennett, A., & Leonard, J. (2000). A behaviour-based approach to adaptive feature detection and following with autonomous underwater vehicles. IEEE Journal of Oceanic Engineering, 25(2), 213–226. Blidberg, D. R., & Turner, R. (1995). Mission planner. In Yuh (Ed.), Underwater robotic vehicles: Design and control (pp. 129–144). Albuquerque, NM: TSI Press. Bonasso, R. P. (1992). Using parallel program specifications for reactive control of underwater vehicles. Journal of Applied Intelligence, 2, 201–223. Boswell, A. J., & Leaney, J. R. (1994). Using the subsumption architecture in an autonomous underwater robot: Expostulations

ARTICLE IN PRESS 1530

T.W. Kim, J. Yuh / Control Engineering Practice 12 (2004) 1521–1530

extensions and experiences. International advanced robotics program, workshop on mobile robots for subsea environments, Monterey, CA, USA Brooks, R. A. (1999). Cambrian intelligence, the early history of the new AI. Cambridge, MA: MIT Press. Caccia, N., Virgili, P., & Veruggio, G. (1995). Architectures for AUVs: A comparative study of some experiences. Proceedings of the international symposium and exhibition on AUVS, Washington, DC, USA (pp. 164–178). Carreras, M., Yuh, J., & Batlle, J. (2001). A hybrid methodology for RL-based behavior coordination in a target following mission with an AUV. Proceedings of MTS/IEEE OCEANS ‘01 conference, Honolulu, HI, USA (pp. 2666–2672). Carreras, M., Yuh, J., & Batlle, J. (2002). High-level control of autonomous robots using a behavior-based scheme and reinforcement learning. Proceedings of the 15th IFAC world congress on automatic control, Barcelona, Spain. Choi, S. K., Yuh, J., & Takashige, G. Y. (1995). Design of an omnidirectional intelligent navigator. Underwater robotic vehicles: Design and control (pp. 277–297). Albuquerque, NM: TSI Press. Coste-Maniere, E., Wang, H. H., & Peuch, A. (1995). Control architectures: What’s going on? Proceedings US-Portugal workshop on undersea robotics and intelligent control, Lisbon, Portugal (pp. 54–60). Dunn, S., Smith, S., Betzer, P., & Hopkins, T. (1995). Design of AUVs for coastal oceanography. Underwater robotic vehicles: Design and control (pp. 299–325). Albuquerque, NM: TSI Press. FORCE Computers (1997), SYS68K/CPU-60 Manual, CA, USA. Fujii, T., & Ura, T. (1996). Development of an autonomous underwater robot ‘twin-burger’ for testing intelligent behaviors in realistic environments. Autonomous Robots, 3(3), 285–296. Gat, E. (1998). Three layer architectures. In: Kortenkamp, Bonaso, & Murphy (Eds.), Artificial Intelligence and Mobile Robots (pp. 195– 210). Menlo Park, CA: AAAI Press. Hall, W. D., & Adams, M. B. (1992), Autonomous vehicle taxonomy. Proceedings of the symposium on autonomous underwater vehicle technology, Washington, DC, USA (pp. 49–64). Healey, A. J., Marco, D. B., & McGhee, R. B. (1996). Autonomous underwater vehicle control coordination using a tri-level hybrid software architecture. Proceedings of the IEEE international conference on robotics and automation, Minneapolis, MN, USA (pp. 2149–2159). Ito, Y., Kato, N., Kojima, J., Takagi, S., Asakawa, K., & Shirasaki, Y. (1994). Cable tracking for autonomous underwater vehicle. Proceedings of symposium on autonomous underwater vehicle technology, Cambridge, MA, USA (pp. 218–224). JR3, Inc. (1994). JR3 DSP-based force sensor receivers manual, CA, USA. Kim, T.W., Choi, S. K., Lee, J.W., West, M. E., & Yuh, J. (2000). A real-time distributed control architecture for AUVs. Proceedings of the symposium of underwater robotic technologies (SURT 2000), CD-ROM, Maui, HI, USA. Kim, T.W., & Yuh, J. (2003). Task description language for underwater robots. Proceedings of IEEE/RSJ intelligent robots and systems (IROS ‘03), Las Vegas, NV, USA.

Kondo, H., Yu, S., & Ura, T. (2001). Object observation in detail by the AUV ‘‘Tri-Dog 1’’ with laser pointers. Proceedings of OCEANS ‘01, Honolulu, HI, USA (pp. 390–396). Lee, P. M., & Yuh, J. (1999). Application of non-regressor based adaptive control to an underwater mobile platform-mounted manipulator. Proceedings of IEEE international conference on control applications, Honolulu, HI, USA (pp.1135–1140). Lippert Automationstecknik GmbH (2001). Cool road runner II PC/ 104-Plus CPU board technical manual, Mannheim, Germany. Macrolink, Inc. (1992). 16-Line asynchronous communications multiplexer: User’s manual, CA, USA. Mahesh, H., Yuh, J., & Lakshmi, R. (1991). A coordinated control of underwater vehicle and robotic manipulator. Journal of Robotic Systems, 8(3), 339–370. Martins, A., Matos, A., Cruz, N., & Pereira, F. L. (1999). IES an open system for underwater inspection. Proceedings of OCEANS ’99, Seattle, WA, USA (pp. 549–554). MATRIX Corporation (1997). MD-DAADIO user’s manual, NC, USA. Pfeifer, R., & Scheir, C. (1999). Understanding intelligence. Cambridge, MA: MIT Press. Ridao, P., Batlle, J., Amat, J., & Roberts, G. N. (1999). Recent trends in control architectures for autonomous underwater vehicles. International Journal of Systems Science, 30(9), 1033–1056. Ridao, P., Yuh, J., Batlle, J., & Sugihara, K. (2000). On AUV control architecture, Proceedings of IEEE international conference on intelligent robots and systems, Takamatsu, Japan (pp. 855–860). Rosenblatt, J., Williams S., & Durrant-Whyte, H. (2000). BehaviorBased Control for Autonomous Underwater Exploration, Proceedings of IEEE international conference on robotics and automation, San Francisco, CA, USA (pp. 920–925). SBS GreenSpring (1995). IP-quadrature user manual, CA, USA. Sousa, J., Cruz, N., Matos, A., & Pereira, F. L. (1997). Multiple AUVS for coastal oceanography. Proceedings of OCEANS ‘97, Vol. 1. Halifax, NS, Canada (pp. 409–414). Ura, T., Kumagai, M., Sakakibara, T., Kimura, Y., Okumura, T., Kazuyoshi, S., Sasaki, M., & Matsushima, M. (2002). Construction and operation of four autonomous underwater vehicles for lake survey. Proceedings of the international symposium on underwater technology, Tokyo, Japan (pp. 24–29). Valavanis, K. P., Gracanin, D., Matijasevic, M., Kolluru, R., & Demetriou, G. A. (1997). Control architectures for autonomous underwater vehicles. IEEE Control Systems Magazine, 17(6), 48–64. Wang, H. H., Marks, R. L., & Rock, S. M. (1993). Task-based control architecture for an untethered, unmaned submersible. Proceedings of the eighth international symposium on unmanned untethered submersible technology, Durham, NH, USA (pp. 1–12). WindRiver Systems, Inc. (1995). VxWorks programmer’s guide, CA, USA. Yoerger, D., Bradley, A., & Walden, B. (1991). The autonomous benthic explorer. Unmanned Systems Magazine, 17–23. Yuh, J. (Co-Editor with T. Ura, & G. A. Bekey) (1996). Autonomous underwater robots. Dordrecht: Kluwer Publisher. Zheng, X. (1992). Layered control of a practical AUV. Proceedings of the IEEE symposium on autonomous underwater vehicles technology, Washington, DC, USA (pp. 142–147).