MASSACHUSETTS INSTITUTE OF TECHNOLOGY
Sea Grant College Program

Software Architecture

The primary objectives of software development at MIT Sea Grant have been to

  1. provide an intrinsically flexible mission reconfiguration capability
  2. simplify the integration of new capabilities into vehicles

Early research in the laboratory focused on control and simulation of underwater vehicles. Mission-level control research focused on layered control (also called subsumption architecture). Several years of development resulted in the development of a suite of software for configuring, simulating, executing, and analyzing missions. Elements of the development suite include:

For development of code, specialized software tools have been developed which greatly accelerate incorporation of new algorithms, such as navigation or control routines, into the vehicle code. The present generation software (the fifth developed at the lab) was written under ONR support for Odyssey II.

Specifying New Missions

A mission is executed by the layered control portion of the vehicle software. Layered control explicitly modularizes control laws in units called "behaviors." The behavior is the elementary unit of layered control, and represents the lowest level of mission related expertise. A behavior receives sensory input and generates commands to the vehicle. For example, the objective of an obstacle avoidance behavior is to prevent the vehicle from hitting objects. Much of the strength of layered control comes from the ability to run multiple control laws (i.e. behaviors) simultaneously. A layered control command structure consists of a number of behaviors, of which the outputs are resolved into the final command that is sent to the vehicle.

The layered control structure in the vehicle is completely reconfigurable by the user. It is composed of active behaviors which are selected from a library of behaviors. At present, more than twenty behaviors have been written for Odyssey II.

Programming a mission within layered control typically involves three steps: deciding which behaviors are required, assigning them appropriate priorities, and assigning values to the arguments of the behaviors. One attractive feature of our implementation is that these steps can be performed by editing a mission-initialization file. Because the vehicle source code does not need to be recompiled, missions can rapidly configured during field experiments. The initialization files are short and relatively simple to understand.

Adding New Capabilities to the AUV

Addition of new vehicle mission capabilities is accomplished by adding new behaviors to the vehicle behavior library. It is important to distinguish a new "capability" from a new "mission" in that a new capability involves adding to the vehicle software as opposed to specifying a new mission script. Five generations of AUV control software developed at MIT Sea Grant have created a "tool kit" of techniques and applications supporting rapid code development.

The central issue addressed by the MIT SG AUV software architecture is how complexity scales with increased vehicle functionality. The issue is not how to provide a mechanism for solving specific control issues, for example station-keeping or homing, but how to provide an environment which allows one to simply and incrementally add capability to a vehicle as solutions to discrete control problems are found. All of the mission capabilities envisioned for the first year, including docking and acoustic control of vehicles, will be implemented though the addition of behaviors to the vehicle behavior library.

Central to the simulation is the module which calculates the vehicle state and sensor readings as a result of commands from the control software. This module contains:

The simulation environment has been designed with several interesting capabilities. It allows a user to dynamically modify any parameter during a simulation including: parameters of the mission, gains of the different control laws, and the dynamic characteristics of the vehicle. For example, the weight and balance characteristics of the vehicle can be modified by changing the position of either or both the centers of gravity and buoyancy. Plots of any parameter against simulation time, or even another parameter can be made while the simulation is running. Also, simulation results can be logged to the hard disk.

In Perspective:

Layered control is one of a variety of architectures which have been employed for mission level control of mobile robots. Implemented originally on land robots, it was used to solve relatively low-level problems such as coordination of limbs on a walking robot (Brooks, 1986). In subsequent work, it was used to embed mission level control in mission-dedicated vehicles (Loch, 1989; Connell, 1990). Extension of the architecture to mission reconfigurable applications highlighted the subtlety of programming layered control (Bellingham et al., 1990) and led to the development of hybrid architectures such as state-configured layered control (Bellingham and Consi, 1991) and SSS (Connell, 1992).

A variety of institutions have developed and implemented high level control architectures for AUVs. Many share in common a three-layer approach, for example the NPS architecture (Byrnes et al., 1993). Other research groups, developing software for vehicles yet to be launched, have also adopted a three level approach, for example the (Bizingre et al., 1994). A distinguishing characteristic of the MIT approach is the degree to which it has been proven in field operations in challenging environments.

 

<- top of page ->