A Behavior-based Architecture

8/2/2019 A Behavior-based Architecture

http://slidepdf.com/reader/full/a-behavior-based-architecture 1/19

A behavior-based architecturefor autonomous underwater exploration

Julio Rosenblatt *, Stefan Williams, Hugh Durrant-Whyte

Australian Centre for Field Robotics, University of Sydney, Sydney, NSW 2006, Australia

Received 4 July 2001; received in revised form 8 October 2001; accepted 28 November 2001

Abstract

We present a system for behavior-based control of an autonomous underwater vehicle

for the purpose of inspection of coral reefs, a task currently performed by divers holding

a video camera while following a rope. Using sonar and vision-based approaches, be-

haviors have been developed for guiding the robot along its intended course, for main-

taining a constant height above the sea floor, and for avoiding obstacles. A task-level

controller selects which behaviors should be active according to user-defined plans and in

response to system failures. Behavior arbitration has been implemented using both fuzzy

logic and utility fusion. Initial experiments have been conducted in a natural coastal inlet,

and the system is to be soon demonstrated in the coral reef environment.

Ó 2002 Elsevier Science Inc. All rights reserved.

1. Introduction

In unstructured, unknown, and dynamic environments, such as those en-

countered by outdoor mobile robots, an intelligent agent must address the

issues of incomplete and inaccurate knowledge; it must be able to handle un-

certainty in both its sensed and a priori information, in the current state of the

agent itself, as well as in the effects of the agent Õs actions. Autonomous un-

derwater vehicles have the potential to play a substantial role in ecology

management, geophysical surveying, offshore oil and gas exploration and well

Information Sciences 145 (2002) 69–87

www.elsevier.com/locate/ins

* Corresponding author.

E-mail addresses: [email protected] (J. Rosenblatt), [email protected] (S. Wil-

liams), [email protected] (H. Durrant-Whyte).

0020-0255/02/$ - see front matter Ó 2002 Elsevier Science Inc. All rights reserved.

PII: S 0 0 2 0 - 0 2 5 5 ( 0 2 ) 0 0 2 2 4 - 4

http://mail%20to:%[email protected]/





maintenance, undersea mineral exploration and mining, and in surveillance

and defence. However, a subsea environment is particularly unstructured and

dynamic, the degrees of freedom in the control and estimation problem aregreater than on land, and there exists no reliable positioning data.

To function effectively in such conditions, an autonomous system must be

responsive to its environment, proceeding in a data-driven manner, as well as

goal-oriented, taking into account the higher-level goals of the system. When

used appropriately, deliberative planning and reactive control complement each

other and compensate for each otherÕs deficiencies. In order to achieve this de-

sired symbiosis of deliberative and reactive elements, the distributed architecture

for mobile navigation (DAMN) consists of a group of distributed task-achieving

modules, or behaviors, communicating with a centralized command arbiter [8].

Within this framework, we have developed an architecture for behavior-

based control of an autonomous underwater vehicle for the purpose of in-

spection of coral reefs. A survey project for reef management, carried out by

the Australian Institute of Marine Sciences, is designed to provide long-term

quantitative data about corals, algae and marine life over the extent of the

Great Barrier Reef. This data are for studies of abundance and population

change in selected organisms on a large geographic scale. Currently, visual

transect information is recorded using underwater video cameras held by a

diver following a rope, as shown in Fig. 1.

The reef surveillance task, as it is currently defined, consists primarily of fol-lowing an assigned path while maintaining a fixed altitude above the reef and

avoiding collisions [13]. Independent behaviors and arbiters, using decoupled

controllers, have been developed as a modular means of accomplishing these

various sub-tasks. For example, two behaviors have been developed for the path

following aspect of the task; the first behavior uses video input to track a rope laid

outalongthecoral,whilethesecondbehaviorusessonartodetectpassivebeacons.

TheDAMN arbiters arethen responsible forcombining the behaviorsÕ votesto

generate controller commands. Fuzzy logic arbiters are currently used for control

of the vehicle; another set of behaviors and arbiters that perform utility fusion [9]

are under development. In both cases, the distributed, asynchronous behaviorsprovide real-time responsiveness to the environment, while the centralized com-

mand arbitration provides a framework capable of producing coherent behavior.

A task-level controller selects which behaviors are active at any given moment.

2. Oberon submersible vehicle

We have constructed a simple low-cost underwater robot named Oberon,

shown in Fig. 2, as a test-bed for experimental work in autonomous under-

sea navigation. There are currently five thrusters on the vehicle. Three of these are oriented in the vertical direction while the remaining two are di-

70 J. Rosenblatt et al. / Information Sciences 145 (2002) 69–87



rected horizontally. This gives the vehicle the ability to move itself up and down,

control its yaw, pitch and roll, and move forwards and backwards. This thruster

configuration does not allow the vehicle to move sideways but this does not pose

a problem for the missions envisaged for this vehicle.

The submersible vehicle is connected by tether to a ground base station,

which provides power to the robot. The tether also provides communicationsbetween the off-board computers at the surface and those on-board the vehicle,

and includes a coaxial cable for transmitting video data, as well as serial lines.

The on-board computer is directly interfaced to the vehicle hardware and is

used to control the motion of the robot and to acquire sensor data. There is

also a leak detection circuit that shuts off power to the vehicle if water is de-

tected inside the pressure hulls using a pair of optical diodes.

2.1. Internal sensors

Gyroscope. An Andrews Fiber Optic Gyro has been included in the Oberonrobot to allow the robotÕs orientation to be determined. This sensor provides the

Fig. 1. Diver taking visual transect of the reef.

J. Rosenblatt et al. / Information Sciences 145 (2002) 69–87 71



yaw rate and is used to control the heading of the submersible. The bias in the

gyroscope is first estimated while the vehicle is stationary. The bias compensated

yaw rate is then integrated to provide an estimate of vehicle heading. Because

the missions described here were less than 30 minutes, the yaw drift caused by

the integration of a noisy signal did not pose a significant problem.

Compass. An integrated compass and tilt sensor has recently been added to

the vehicle. The compass signal is filtered with the output of the gyroscope to

estimate the yaw rate bias of the gyroscope on-line.

Pressure sensor. A bathyometric pressure sensor measures the externalpressure experienced by the vehicle and is used to measure depth. This sensor

provides a voltage signal proportional to the pressure and is sampled by an

analogue to digital converter on the embedded controller. Feedback from this

sensor is used to control the depth and altitude of the submersible.

2.2. External sensors

Sonars. There are two scanning low frequency terrain-aiding sonars that

serve as the main sensors for the robot. The first is a Tritech SeaKing imaging

sonar, which has a dual frequency narrow beam sonar head. It is mounted ontop of the submersible and is used to scan the environment in which the sub-

Fig. 2. Oberon submersible vehicle is propelled by 5 thrusters and is equipped with a sonar on top

and in front and a color CCD camera. The on-board processor communicates with off-board

computers via a tethered cable, which also supplies power.




mersible is operating. It can achieve 360° scan rates on the order of 0.25 Hz

using a pencil beam with a beam angle of 1.8°. This narrow beam allows the

sonar to accurately discriminate bearing returns to objects in the environment.It has a variable mechanical step size capable of positioning the sonar head to

within 0.5° and can achieve range resolution on the order of 50 mm depending

on the selected scanning range. It has an effective range of up to 300 m in the low

frequency mode, thus allowing for long range target acquisition, but can also be

used for high definition scanning at lower ranges. The information returned

from this sonar is used to build and maintain a feature map of the environment.

The second sonar is an Imagenex sonar unit operating at 675 kHz. It has

been mounted at the front of the vehicle and positioned such that its scanning

head can be used as a forward and downward looking beam (see Fig. 5). This

enables the altitude above the sea floor as well as the proximity of obstacles to

be determined using the wide angle beam of the sonar. The sonar Õs beam width

is 15:0° Â 1:8°, thus covering a broad swath with each ping, making it an ideal

sensor for altitude estimation and obstacle avoidance. Because this sonar is

used for multiple purposes, a scheduler is used to allocate this resource to the

appropriate behaviors.

Camera. A color CCD camera mounted in an underwater housing provides

a PAL signal via a coaxial cable to an off-board computer, where a Matrox

Meteor card is used to digitize the image for further processing.

2.3. Communications

Inter-process communication occurs asynchronously via a TCP/IP socket-

based interface using a distributed message passing system. Processes register

as either producers or consumers of a particular message type. It transparently

communicates with processes on the same processor or across the network,

without requiring a fixed network topology to be defined prior to operation.

Messages are sent as a continuous stream of inputs to behaviors and outputs to

controllers; a lost message may introduce a slight delay in the response of abehavior to a stimulus, but otherwise operation is unaffected. The communi-

cations system also logs message data and provides a playback facility which

can later be used to send and receive commands, thus providing a simulated

vehicle for testing and development purposes.

Fig. 3 shows a schematic diagram of the vehicle sensors and their connec-

tions. The Oberon robot uses a CompactPCI system running Windows NT

that interfaces directly to the hardware and is used to control the motion of the

robot and to acquire sensor data. While the Windows operating system does

not support hard real-time performance, it is suitable for soft real-time ap-

plications and the wide range of development and debugging tools make itan appropriate environment in which to test new navigation algorithms.




Fig. 3. Sensor data is collected by the on-board processor and communicated to the surface computers via ethern



Time-critical operations, such as sampling of the analog to digital converters, are

performed on the hardware devices themselves and use manufacturer supplied

device drivers to transfer the data to the appropriate processes. The low-levelprocesses run on the embedded controller and are used to interface directly with

the hardware. This allows the controllers to respond quickly to changes in the

state of the submersible without being affected by delays due the data processing

and high-level control algorithms running on the remote computers.

Sensor data are collated by the on-board processor and sent to the surface

via the tether using an ethernet connection. The base station contains a net-

work of computers that are used for further data processing, data logging, and

providing feedback to the user about the state of the submersible. Set points to

the low-level controllers are provided by the behaviors and high-level con-

trollers described in the following section.

3. Behavior-based control architecture

In order to avoid the bottlenecks and brittleness of centralized systems, the

DAMN consists of a group of distributed specialized task-achieving modules,

called behaviors, communicating with centralized command arbiters, as shown

in Fig. 4. A behavior encapsulates the perception, planning and task execution

capabilities necessary to achieve one specific aspect of robot control, and re-

ceives only that data specifically required for that task [2]. Each behavior

Fig. 4. DAMN consists of centralized arbitration of votes from distributed behaviors, activated by

the task-level controller based on vehicle and behavior status.




operates independently and asynchronously from the others, and uses domain

and procedural knowledge to vote for desirable actions and against objec-

tionable ones, from the perspective of the task for which it is responsible.An arbiter is responsible for combining the behaviorsÕ votes to generate

actions, which are then sent to the vehicle controller. One type of arbiter used

for control of the vehicle employs fuzzy logic [15]; the behaviors send depth or

heading commands as fuzzy sets. Another type of arbiter used performs utility

fusion; instead of voting directly for actions, behaviors vote for the utility of

possible outcomes and their associated uncertainty, and the arbiter determines

which action will maximize expected utility. Each of these schemes has their

own advantages and disadvantages, and both have been demonstrated to be

effective for navigation of land-based vehicles [4,9].

A task-level controller is also employed to select which behaviors should be

active according to user-defined plans and in response to system failures,based on

knowledge of which behaviors are most relevant and reliable in a given situation.

3.1. Decoupled control

Control of an mobile robot in six-dimensional space in an unstructured and

dynamic environment would be a highly computationally intensive endeavor,

even more so with the difficulties in controlling an underwater robot. We in-

stead chose to decouple the control of motion in the horizontal plane frommotion along the vertical axis. Thus greatly simplifying the individual design of

controllers, behaviors, and arbiters for the two subproblems.

The dynamics of the Oberon vehicle are such that the vertical motion of the

vehicle is largely decoupled from the lateral motion. The vehicle is very stable in

the roll and pitch axes due to the large righting moment induced by the vertical

configuration of the pressure vessels. A steel keel provides an added moment to

maintain the vehicle in an upright pose. Furthermore, this decoupling of the

control problem is reasonable for the types of task we anticipate performing with

underwater vehicles. In the reef surveying task, for example, we need to maintain

a fixed height above the sea floor, independent of the path following behaviorsthat operate in the horizontal plane. The surveying task can then be made in-

dependent of maintaining the vehicle altitude. In addition, we are not interested

in explicitly controlling the vehicleÕs roll or pitch, merely minimizing them.

Thus, there is one PID controller for the vertical thrusters which servos on

depth, and another PID controller for the horizontal thrusters which governs

yaw and speed. These controllers can then be designed, tuned, and operated

independently of each other.

There are also two arbiters in the system, each one corresponding to a

separate controller. Likewise, behaviors are separated into those involved in

vertical movement along the Z -axis and those involved in horizontal movementin the X – Y plane, as illustrated in Fig. 4.




3.2. Behaviors

In order to perform the task of surveying a coral reef transect, there are atleast three behaviors that must be part of the system: following the transect

path, maintaining a certain height above the coral, and avoiding collisions.

Because there is no global positioning data and only highly inaccurate internal

data available to the robot, we attempt only to maintain position relative to

sensed features in the environment. Two methods currently being used are

vision-based navigation using a rope laid out along the coral and sonar-based

navigation using passive beacons. They each have different failure modes and

can be used in a complementary manner. Research into the simultaneous lo-

calization and mapping is also being conducted [13].

This approach allows the Imagenex sonar to be shared by both the task that

maintains the altitude of the sub and by tasks interested in obstacle avoidance.

Since the resources of any robot will be limited, it important to share these

resources as necessary. A resource scheduler has been implemented that allows

resources to be shared between various tasks based on their relative priority

and their urgency.

Maintain Altitude. In the context of this project, the robot must be able to

detect the coral reef and maintain a relatively constant height above it in order

to videotape the coral specimens and of course to avoid colliding with them.

This behavior provides the ability to maintain the robot at a certain altitudeabove the sea floor. A sonar is used to periodically determine the altitude of the

robot; several pings are taken directly downward and at slight angles in either

direction, as shown in Fig. 5(a), and the minimum distance measured is used as

a conservative estimate of altitude.

The Imagenex sonar is pointed downward to measure height above the

bottom. However, because this sensor must also be used for other purposes

such as obstacle avoidance, and because of the sonarÕs slow scanning rate, it is

not possible to respond to disturbances and maintain stable control using this

sensor alone. Thus, the task is accomplished using the sonar in combination

with the depth sensor, which is continuously sampling the depth. The differencebetween the desired and actual altitudes is used to set a new desired depth for

this behavior, as illustrated in Fig. 5(b).

Avoid Collisions. When the sonar is pointed forward, its returns are pro-

cessed to determine if there are any obstacles that may lie ahead, as shown in

Fig. 5(b). For the fuzzy arbiter, the behavior would vote against the heading in

which the obstacle lies; for the utility fusion arbiter it would indicate a negative

utility at the computed obstacle location, along with uncertainty estimates.

Follow Rope. The vision-based approach uses camera images in order to

detect the survey line by color. A target color is specified, and a distance metric

for image pixels is defined as the sum of the differences between a given pixel ÕsRGB values and the target RGB values, normalized by pixel intensity:




D p ¼j Rt À R p j þ jG t À G p j þ j Bt À B p j

R p þ G p þ B p : ð1Þ

A random sample of pixels are then chosen from the image, and a dynamic

programming search [5] is begun from each pixel to find a least cost path from

the top to the bottom of the image, using the color distance metric defined

above, as shown in Fig. 6(a).

Fig. 5. Sonar-based behaviors: (a) Several altitude measurements are taken; (b) Maintain Altitude

behavior then uses minimum altitude measurement to set desired depth, and Avoid Collisions

behavior makes forward measurements to avoid obstacles.

Fig. 6. Path following sensors: (a) Follow Rope behavior performs visual tracking; (b) Follow

Targets behavior uses sonar to detect two targets in natural terrain.




Once the line has been found in the image, a pursuit algorithm is used to

determine which orientation would best bring the robot onto the line and sends

that as a vote to the fuzzy arbiter. The location of the line itself can simply be

sent to the utility fusion arbiter as a positive utility.

Follow Targets. At present, sonar targets are introduced into the environ-

ment at the two ends of the transect to be followed. These targets present large,

easily detectable features for the sonar, as indicated in Fig. 6(b). By main-

taining a fix on two of these targets, the robot can find its current position andorientation relative to the line joining the two targets. Multiple targets can be

used, depending on the roughness of the terrain and the length of the transect.

The redundant information will also allow a better estimate of the lineÕs po-

sition and orientation, thus improving line tracking.

Using the range and bearing information to both of the targets to define the

line to be followed, the perpendicular distance from the sub to the line (d ) as

well as the difference in orientation between the principle axis of the sub and

the line (w) are calculated, as shown in Fig. 7. These two values can then be

used to compute a new desired heading ðwd Þ that will keep the sub on its de-

sired path [14]; this is used to define the vote sent to the fuzzy arbiter. Again,for the utility fusion arbiter, the line is sent as a positive utility.

3.3. Fuzzy logic arbiter

Fuzzy logic has found many uses for mobile robot control, including

command fusion systems (see [11] for a survey). For the DAMN fuzzy logic

arbiter, each behavior must determine the desired action, in this case either a

heading or a depth, and vote for a fuzzy membership set with that action at the

peak. Command defuzzification is achieved using the maximum criterion to

take the peak value; other defuzzification strategies, such as center of mass,assume a unimodal function and in general this averaging of inputs will select

Fig. 7. Follow Targets behavior calculates desired heading wd based on distance d and heading wd

from sub to line between targets.




inappropriate commands. A fuzzy vote is specified by four points that may

take the form of a triangle, rectangle, or trapezoid.

Fig. 8 shows votes from two behaviors. The first is the Move To behavior,

which simply steers the vehicle to a specific set of coordinates; it is voting with atriangle whose apex is at 55°. The second behavior is Avoid Collisions, which

has a weight of 5; it has detected an obstacle ahead and is voting equally

against all headings between 50° and 70°. The fuzzy sum of all votes is shown

as a solid gray line, and the output direction determined by the arbiter (40°) is

shown as a dashed black vertical line. The current direction (60°) is shown in

the figure as a solid black vertical line.

3.4. Utility fusion arbiter

Utility fusion is a novel means of action selection in which behaviors de-termine the utility of possible world states and their associated probabilities,

and the arbiter evaluates candidate actions based on that information [9].

Utility theory provides a framework for defining votes and dealing with un-

certainty in an explicit fashion using Bayesian probabilities [1]. If assign a

utility measure U ðcÞ for each possible consequence of an action a, then the

expected utility U ðaÞ is

U ðaÞ ¼X

c

U ðcÞ Á P ðc ja; eÞ; ð2Þ

where P ðc ja; eÞ is the probability that consequence c will occur given that weobserve evidence e and take action a [6]. Thus, if behaviors provide these

Fig. 8. Fuzzy Arbiter combines votes from two behaviors by computing their sum, shown as a solid

gray line, and selecting the maximum, shown as a dashed black vertical line. The current direction is

shown as a solid black vertical line.




utilities and probabilities to an arbiter, it can then apply the Maximum Ex-

pected Utility (MEU) criterion to select a Pareto-optimal action based on all

current information [7].Utility fusion does not create a world model as sensor fusion systems do.

The information combined and stored by the utility fusion arbiter does not

represent sensed features of the world, but rather the desirability of being in a

particular state according to some criterion defined within the behavior. The

processing of sensory data is still distributed among behaviors, so the bottle-

necks and brittleness associated with sensor fusion are avoided.

Unlike command fusion systems, the utility fusion arbiter does not simply

select among or combine actions proposed by behaviors. Instead, behaviors

indicate the utility of possible world states, together with estimates of uncer-

tainty; the arbiter maintains a map of these utilities, and evaluates candidate

actions within it. A more complete overview of various types of architectures

and their corresponding advantages and disadvantages can be found in [10].

Another advantage of map-based utility fusion over command fusion is that

the dynamics of the system being controlled can be fully modeled and ac-

counted for by the arbiter.

The utility arbiter maintains a local map of the utilities and associated un-

certainties sent to it by the behaviors. The utilities are represented by geometric

constructs (points, lines, and polygons) with associated two-dimensional

Gaussian distributions. For the sake of efficiency, the command choices to beevaluated are discretized; the results are smoothed and interpolated to avoid

problems with bang–bang control, i.e., switching between discrete choices to

achieve an intermediate value.

In the example shown in Fig. 9, the two negative utilities correspond to

obstacles detected by the Avoid Obstacles behavior; a line of positive utility is

placed between the two sonar targets by the Follow Targets behavior, and the

Follow Rope behavior has submitted another line of positive utility corre-

sponding to the rope found in the video image. The arrows emanating from the

vehicle represent the candidate actions being evaluated by the arbiter. The one

which has maximum expected utility is selected as the current commandedaction.

3.5. Task-level controller

A task-level controller selects which behaviors should be active according to

user-defined plans and in response to system failures, based on knowledge of

which behaviors are most appropriate in a given situation. The system pro-

grammer defines schemas, parameterized planning constructs that indicate

under which circumstances a behavior should run and how various success andfailure signals sent by the behavior should be responded to.




Schemas may be invoked within other schemas, thus creating a task tree

whose root is the overall mission plan and whose leaves are the behaviors to be

executed. Each schema and behavior also has a set of preconditions whichmust be satisfied before it becomes active. In Fig. 10, the task-level controller is

executing a user-defined mission for surveying a coral reef. The root-level

schema, SU R V E Y TR A N S E C T, enables the AV O I D CO L L I S I O N S behavior, as

well as the FI N D TR A NS E C T and FO L L O W RE E F sub-schemas; the FO L L O W

RE EF schema enables the MA I N T A I N AL T I T U D E behavior and the FO L L O W

LI N E sub-schema, which in turn enables the FO L L O W TA R GE T S and the

FO L L O W ROP E behaviors.

These last two behaviors, when enabled by their parent schema, are active

when their respective conditions are true; if the targets are detected by the

sonar, then FO L L O W TA R G E T S is active, and if the rope is visible in the videoimage, then FO L L O W ROP E is active. In the example shown in the figure,

FO L L O W TA R GE T S is active and FO L L O W ROP E is inactive, but the reverse

could be true, or it could be the case that both behaviors are active at once, and

the outputs from the two behaviors would be combined by the arbiter. When

neither the targets nor the rope is visible, these behaviors are quiescent, but the

conditions for FI N D TR A NS E C T are satisfied and that schema and its de-

scendants (not shown) become active.

At any given moment, the systemÕs state of execution is defined by a hier-

archy of active schemas and behaviors, the set of goals that they are trying to

satisfy, and the values of various state variables. Thus, unlike TCA [12], thehierarchy is not strictly top-down and the behaviors do not operate in a fixed

Fig. 9. Utility Fusion Arbiter combines positive utilities from the Follow Rope behavior (shown as

a wavy solid line) and the Follow Targets behavior (shown as a straight dashed line) with negative

utilities from the Avoid Obstacles behavior (shown as two dark solid octagons); each of the can-

didate actions (shown as arrows pointing away from the vehicle) is evaluated and the one with the

highest expected utility is selected.




sequence, but rather are active only when all pre-conditions are satisfied. Inaddition, if one behavior or schema fails to produce the desired result, an al-

ternative method will automatically be selected if available. This task-level

controller is somewhat similar to he proposed continuous process extension to

RAPS [3], with further capabilities and a more structured syntax.

A behavior or schema signals success when it has successfully achieved its

goal, otherwise it throws an exception back up to the calling schema when it

has failed. This signal is caught by the parent, which can then assert or retract a

predicateÕs truth value, effectively invoking some children and causing others to

halt. If this schema is unable to handle the signal, it can instead pass the signal

up to its parent, which then handles the exception in the same manner.A schema can indicate whether its children should be run in sequence or in

parallel. If they are in sequence, then the behaviors and schemas will wait for

the previous one to be successful before executing. Those in parallel will exe-

cute simultaneously until one or more of the children (as specified) signal

completion.

3.6. Complete software system

The complete software system for the task of reef surveillance is shown inFig. 11 below.

Fig. 10. Task Tree: the SU R V E Y TR A N S E C T schema has activated the AV O I D CO L L I S I O N S be-

havior and the FO L L O W REE F sub-schema, which enables the MA I N T A I N AL T I T U D E behavior

and the FO L L O W LIN E sub-schema, which in turn enables the FOLLOW TA R G E T S and the FOL -

L OW OP ELO W ROP E behaviors.




Fig. 11. Complete software system: raw sensor data is processed by virtual sensors, which provide input to task-sp

votes to control arbiters. Sets of behaviors are activated by the task-level planner as appropriate.



Fig. 12. Results from Maintain Altitude behavior: (a) plot of altitude vs. time shows that the

desired altitude was maintained; (b) depth vs. time as vehicle changed depth to match the profile of

the sea floor.

Fig. 13. Path of robot executing Follow Targets behavior is shown as series of ellipses connected by

a line, within a map created from sonar data.




4. Experimental results

This section presents some preliminary results from deployment of the ve-hicle in a natural terrain environment along SydneyÕs coastline. The first be-

havior developed was Maintain Altitude, which keeps the vehicle at a fixed

standoff distance from the ocean floor. In the experimental results showing

altitude and depth in Fig. 12, the desired altitude was 1.5 m, which was

maintained within a standard deviation of 0.2 m, as can be seen in the first plot

if altitude vs. time. This is despite a rapidly changing bottom profile, as can be

seen in the second plot of depth vs. time.

Executing the Follow Targets behavior resulted in the path shown in Fig. 13

as a series of covariance ellipses representing 95% certainty in vehicle location.

The vehicle was deployed in a natural coastal inlet with sonar targets placed in

a line at 10 m intervals. The areas on either side of the vehicle are reef walls

detected and mapped from sonar data.

5. Conclusion

We have developed a behavior-based system for control of an autonomous

underwater vehicle performing a survey of coral reefs. Implemented behaviors

provide the ability to avoid collisions, maintain a proper standoff distance, and

following the transect either using a rope with video or targets with sonar.Command fusion is performed using a fuzzy logic arbiter, and a utility fusion

system is under development. A task-level controller selects which behaviors

should be active according to user-defined plans and current environmental

conditions. Initial experiments conducted in a natural coastal inlet have yielded

promising early results, and the system is to be soon demonstrated in the coral

reef environment.

Acknowledgements

The authors would like to thank the other members of the AUV project

team at the ACFR, as well as Dr. Hugues Talbot of the CMIS CSIRO, who

assisted in developing the rope detection algorithm.

References

[1] J. Berger, Statistical Decision Theory and Bayesian Analysis, second ed., Springer, New York,

1985.

[2] R. Brooks, A robust layered control system for a mobile robot, Journal of Robotics and

Automation RA-2 (1) (1986) 14–23.




[3] J. Firby, Task networks for controlling continuous processes, in: Proceedings of the Second

International Conference on AI Planning Systems, Chicago, IL, June 1994.

[4] D. Langer, J. Rosenblatt, M. Hebert, A behavior-based system for off-road navigation,Journal of Robotics and Automation 10 (6) (1994) 776–782.

[5] N. Nilsson, Principles of Artificial Intelligence, Tioga Publication, Palo Alto, CA, 1980.

[6] J. Pearl, Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference,

Morgan Kaufmann, Los Altos, CA, 1988.

[7] P. Pirjanian, The notion of optimality in behavior-based robotics, Journal of Robotics and

Autonomous Systems, 2000 (to appear).

[8] J. Rosenblatt, The distributed architecture for mobile navigation, Journal of Experimental and

Theoretical Artificial Intelligence 9 (2/3) (1997) 339–360.

[9] J. Rosenblatt, Utility fusion: map-based planning in a behavior-based system, Field and

Service Robotics, 1998.

[10] J. Rosenblatt, J. Hendler, Architectures for mobile robot control, in: M. Zelkowitz (Ed.),

Advances in Computers, vol. 48, Academic Press, London, 1999.[11] A. Saffiotti, The uses of fuzzy logic in autonomous robotics: a catalogue raisonne, Soft

Computing 1 (4) (1997) 180–197.

[12] R. Simmons, Structured control for autonomous robots, Transactions on Robotics and

Automation 10 (1994) 1.

[13] S. Williams, D. Dissanayake, H. Durrant-Whyte, Towards terrain-aided navigation for

underwater robotics, Advanced Robotics 15 (5) (2001) 533–550.

[14] J. Yuh, Modeling and control of underwater robotic vehicles, Transactions on Systems, Man

and Cybernetics 20 (6) (1990) 1475–1482.

[15] L. Zadeh, Outline of a new approach to the analysis of complex systems and decision

processes, Transactions on Systems, Man and Cybernetics 3 (1) (1973).


Documents

A Behavior-based Architecture