control architecture for multiple autonomous unmanned...

Control Architecture for Multiple Autonomous Unmanned Vehicle Operations – Trial Results F. Maurelli, Z. Saigol, G. Frost, N. Tsiogkas, and D. M. Lane Ocean Systems Laboratory Department of Electrical, Electronic and Computer Engineering School of Engineering and Physical Sciences Heriot-Watt University Project Manager: D. M. Lane, +44 (0) 131 451 3328 Contract Number: W7714-115079/001/SV Contract Scientific Authority: B. U. Nguyen, 613-947-9759 and F-.A. Bourque, 613-992-3206 The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada. This document contains proprietary information. It is provided to the recipient on the understanding that proprietary and patent rights will be respected.

Defence R&D Canada

Centre for Operational Research and Analysis

Maritime Operational Research TeamDirector of Maritime Strategy

DRDC CORA CR 2013–072 May 2013

Control Architecture for MultipleAutonomous Unmanned Vehicle OperationsTrial Results

F. MaurelliZ. SaigolG. FrostN. TsiogkasD. M. LaneHeriot-Watt University Ocean Systems Laboratory

Prepared by:

Ocean Systems LabDepartment of Electrical, Electronic and Computer EngineeringSchool of Engineering and Physical SciencesEarl Mountbatten BuildingHeriot-Watt UniversityRiccarton, Edinburgh, EH14 4AS Scotland

Project Manager: D. M. Lane, +44 (0) 131 451 3328Contract Number: W7714-115079/001/SVContract Scientific Authority: B. U. Nguyen, 613-947-9759 and F-.A. Bourque, 613-992-3206

The scientific or technical validity of this Contract Report is entirely the responsibility of the Con-tractor and the contents do not necessarily have the approval or endorsement of Defence R&DCanada.

Terms of release: This document contains proprietary information. It is provided to the recipienton the understanding that proprietary and patent rights will be respected.

Defence R&D Canada – CORAContract ReportDRDC CORA CR 2013-072May 2013

Principal Author

Original signed by F. Maurelli

F. Maurelli

Approved by

Original signed by Dr. R. E. Mitchell

Dr. R. E. Mitchell

Head Maritime and Air Systems OR

Approved for release by

Original signed by Paul Comeau

Paul Comeau

Chief Scientist

© Her Majesty the Queen in Right of Canada as represented by the Minister of

National Defence, 2013

© Sa Majeste la Reine (en droit du Canada), telle que representee par le ministre de la

Defense nationale, 2013

Abstract

This report is the final deliverable of the DRDC - Control Architecture for Multi-

ple Autonomous Unmanned Vehicle Operations prepared under Contract W7714 −115079/001/SV . This project addresses the topic of a decentralised world model ser-

vice that operates across multiple underwater vehicles. This document focuses on field

trials performed in Loch Earn, in November 2012 and follows a previous report doc-

umenting the simulation results. Despite some technical problems related to modem

use, especially with the REMUS vehicle, the decentralised world model service has

been successfully demonstrated.

Resume

Le present rapport constitue le produit livrable final du projet, intitule Structure de

commandement de multiples vehicules autonomes sans pilote de RDDC, et il est

prepare conformement au contrat no W7714 115079/001/SV. Le projet porte sur le

systeme decentralise pour le Modele du monde pouvant commander plusieurs vehicules

sous marins. Le document presente aussi les essais sur le terrain realises a Loch Earn,

en novembre 2012, et fait suite a un rapport anterieur qui porte sur les resultats des si-

mulations. Malgre quelques problemes techniques associes a l’utilisation de modems,

surtout avec le vehicule REMUS, le systeme decentralise pour le Modele du monde a

bien reussi la demonstration.

DRDC CORA CR 2013-072 i

This page intentionally left blank.

ii DRDC CORA CR 2013-072

Executive summary

Control Architecture for Multiple AutonomousUnmanned Vehicle Operations

F. Maurelli, Z. Saigol, G. Frost, N. Tsiogkas, D. M. Lane; DRDC CORA CR2013-072; Defence R&D Canada – CORA; May 2013.

Introduction: This document describes the experiments performed by Heriot-Watt

University’s Ocean Systems Laboratory (OSL) during the trials for the DRDC-sponsored

research project “Control Architecture for Multiple Autonomous Unmanned Vehicle

Operations”. It represents the third and last deliverable.

The goal of the trials conducted in November 2012 was to demonstrate that the OSL

World Model (WM) software performs well on real Autonomous Underwater Vehicles

(AUVs) in an underwater environment, while conducting a simulated mine counter-

measures mission. A key aspect of running the WM on a vehicle was to interface it

with the Woods Hole Oceanographic Institution (WHOI) acoustic modems that OSL

uses.

Results: The trials were successful from the point of view of being able to deploy

OSL’s assets on missions in Loch Earn. Further, to the extent that testing was possible,

the world model worked well on the hardware platforms.

The major issue encountered during the trials was that the communication range we

could acheive using high-data-rates was considerably less than we had anticipated,

which made full testing of the world model challenging due to the extremely high loss

of the communication channel. However, through liaison with WHOI, we were able

to make several changes to improve the modems’ performance, and the final status

was that packets could be reliably exchanged at a range of up to 300m, when using the

Nessie vehicle and the towfish modem. With REMUS, the maximum range for reliable

exchange was limited to approximately 55m. We believe the poor range to be mainly

due to the acoustic properties of Loch Earn.

Conclusions and Outlook: The trials of November 2012 had two key successful out-

puts:

• Demonstrated the ability to send and receive high data-rate acoustic messages

between vehicles

• Proved the OSL world model software works on-board real vehicles

DRDC CORA CR 2013-072 iii

The key problem that arose during trials was the quality of the acoustic communica-

tion. Despite this, we were able to test the World Model in water between a vehicle and

a standalone modem, and confirm that data stored into the ontology on one platform

was seamlessly synchronised to the other platform.

The key aims for any future work would be:

1. Identify and solve the problems causing worse range with REMUS than other

platforms.

2. Improve the overall acoustic range, if possible.

iv DRDC CORA CR 2013-072

Sommaire

Control Architecture for Multiple AutonomousUnmanned Vehicle Operations

F. Maurelli, Z. Saigol, G. Frost, N. Tsiogkas, D. M. Lane ; DRDC CORA CR2013-072 ; R & D pour la defense Canada – CARO ; mai 2013.

Introduction : Le present document decrit les experiences menees par l’Ocean Sys-

tems Laboratory (OSL) de l’Universite Heriot Watt pendant les essais effectues dans le

cadre du projet de recherche parraine par RDDC, et intitule Structure de commande-

ment de multiples vehicules autonomes sans pilote. Ce document constitue le troisieme

et dernier produit livrable du projet. De plus, les essais realises en novembre 2012 vi-

saient a demontrer que le logiciel Modele du monde (MM) de l’OSL fonctionne bien

sur des vehicules sous marins autonomes (UAV) reels situes dans un environnement

sous marin, pendant la tenue d’une mission simulee de lutte contre les mines. Un as-

pect cle lie a l’utilisation du logiciel MM sur un vehicule consistait a realiser une in-

terface entre ce vehicule et les modems acoustiques de la Woods Hole Oceanographic

Institution (WHOI) employes par l’OSL.

Resultats : Les essais ont ete une reussite sur le plan de la capacite a deployer les res-

sources de l’OSL dans les missions a Loch Earn. De plus, dans la mesure ou la mise a

l’essai etait possible, le MM a bien fonctionne sur les plateformes materielles. Le prin-

cipal probleme rencontre pendant les essais a trait au fait que la portee des communi-

cations obtenue avec des debits eleves etait tres inferieure a celle prevue, rendant ainsi

difficile la mise a l’essai complete du MM en raison des pertes extremement elevees

dans la voie de communication. Par contre, au moyen d’une liaison avec la WHOI,

nous avons pu effectuer plusieurs modifications afin d’ameliorer la performance des

modems, et nous avons ainsi reussi a echanger des paquets de maniere fiable a une

distance maximale de 300 m, en utilisant un vehicule Nessie et un modem remorque.

Avec le vehicule REMUS, la portee maximale pour un echange de donnees fiable etait

limitee a environ 55 m. Nous croyons que cette faible portee est surtout due aux pro-

prietes acoustiques de Loch Earn.

Conclusions et perspectives : Les essais realises en novembre 2012 ont donne lieu a

deux reussites cles :

1. la demonstration de la capacite d’envoyer et de recevoir des messages acous-

tiques a debit eleve entre des vehicules ;

2. la preuve que le logiciel MM de l’OSL fonctionne a bord de vrais vehicules.

DRDC CORA CR 2013-072 v

Le principal probleme rencontre pendant les essais a trait a la qualite des commu-

nications acoustiques. Malgre cela, nous avons reussi a mettre a l’essai le MM dans

l’eau entre un vehicule et un modem autonome, ainsi qu’a confirmer que les donnees

stockees dans l’ontologie sur une plateforme etaient synchronisees de facon continue

avec l’autre plateforme. Les principaux objectifs des recherches futures seraient :

1. de cerner et de resoudre les problemes qui causent une portee inferieure avec le

vehicule REMUS par rapport aux autres plateformes ;

2. d’ameliorer la portee acoustique globale, si possible.

vi DRDC CORA CR 2013-072

Table of contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Sommaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Trials Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Overview of Working Environment . . . . . . . . . . . . . . . . . . . . . 3

4 Overview of the WHOI Micromodem . . . . . . . . . . . . . . . . . . . . 5

5 Experimental Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.1 Two Vehicles on Shore . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2 Two Vehicles in Loch . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3 One Vehicle in Loch, One Standalone Modem . . . . . . . . . . . . 8

5.4 Acoustic Modem Tests . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.5 World Model Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 Notes on Modem Performance . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1 Firmware Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.2 Optimising Acoustic Performance . . . . . . . . . . . . . . . . . . . 10

6.3 REMUS Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11

DRDC CORA CR 2013-072 vii

7 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7.1 Modem Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7.2 World Model Performance . . . . . . . . . . . . . . . . . . . . . . . 15

8 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

viii DRDC CORA CR 2013-072

List of figures

Figure 1: The trials environment on the shore of Loch Earn . . . . . . . . . . 3

Figure 2: The standalone Yellowbox modem, with the white 12V battery

housed in the Peli-case, and black BT-2 transducer mounted on a

white plate at the bottom of the photo. . . . . . . . . . . . . . . . . 6

Figure 3: The standalone Towfish modem. The black box at the top is the

deck box, which essentially just connects the modem to a power

supply and a host computer. The cylinder contains the actual

modem and is submersible, and the towfish transducer is shown at

the bottom right of the photo. Note the 12V battery is not shown. . 6

Figure 4: Packet Success Rate Vs Distance . . . . . . . . . . . . . . . . . . 13

Figure 5: Packet Type Vs Packet Success Rate . . . . . . . . . . . . . . . . . 14

List of tables

Table 1: Trials Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Table 2: Nessie to Standalone Modem in Bucket . . . . . . . . . . . . . . . 14

Table 3: Standalone Modem to Nessie in Bucket . . . . . . . . . . . . . . . 14

DRDC CORA CR 2013-072 ix

Acknowledgements

The authors would like to thank Lee Freitag, Jim Partan, Keenan Ball and Sandipa

Singh of WHOI, Rasmus Raag and Taavi Salumae of the Tallinn University of Tech-

nology, and all the other members of OSL who made these trials possible.

x DRDC CORA CR 2013-072

1 Introduction

This document describes the experiments performed by Heriot-Watt University’s Ocean

Systems Laboratory (OSL) during the trials for the DRDC-sponsored research project

“Control Architecture for Multiple Autonomous Unmanned Vehicle Operations”. It

represents the third and last deliverable, following [1] and [2]. The aim of this project

was to enable cooperation between multiple autonomous underwater vehicles (AUVs)

by using a distributed world model service.

The goal of the trials conducted in November 2012 was to demonstrate that the OSL

World Model (WM) software performs well on real AUVs in an underwater environ-

ment, while conducting a simulated mine counter-measures mission. A key aspect of

running the WM on a vehicle was to interface it with the Woods Hole Oceanographic

Institution (WHOI) acoustic modems that OSL uses.

Sections 2 and 3 present the trial details and working environment, while the WHOI

modem and experimental methods are described in Sections 4 and 5, respectively. The

following two sections discussed issues with the modem performance and results from

the trials. The report ends with final conclusions and outlook

DRDC CORA CR 2013-072 1

2 Trials DetailsDates: 12th – 30th November 2012

Location: Loch Earn, Scotland

Participants: Zeyn Saigol, Nikolaos Tsiogkas, Gordon Frost,

Francesco Maurelli, Len McLean (OSL)

AUVs: REMUS-100: Remote Environmental Measuring UnitS.

Commercial autonomous underwater vehicle developed

by Hydroid Inc, equipped with WHOI Micromodem

with a custom LBL transducer.

Nessie VI (AUV developed by OSL, equipped with

WHOI Micromodem with a BT-2 transducer)

Other key hardware: Standalone WHOI Micromodem, battery, BT-2

transducer, and yellow Peli Case box (referred to as

Yellowbox modem). This is shown in Figure 2.

Hydroid Acomms bottle with WHOI Micromodem,

battery, towfish transducer (referred to as Towfish

modem). This is shown in Figure 3.

Table 1: Trials Details

2 DRDC CORA CR 2013-072

3 Overview of Working Environment

The working environment for all of the experiments that are outlined within this doc-

ument was located in Loch Earn, Scotland, shown in Figure 1. This loch is a common

testing ground for the OSL, though no testing had previously been done with high data

rate acoustic communication. The basic properties of the loch are:

• Fresh water

• Mixture of sediment and rock comprising the bottom

• Has some very steep sides as well as gentle gradients of the loch floor creating

a basin type of underwater channel

• 87 metres maximum depth

• 10.5 km maximum length

• 1.2 km maximum width

Figure 1: The trials environment on the shore of Loch Earn

Along with the physical attributes of the loch, the weather (November in Scotland) in

which these trials were completed affected the team’s ability to perform experiments.

Out of the 3 weeks:


• The first was very wet with nearly constant heavy drizzle which makes it very

difficult to work with electrical equipment (eg. laptops) and notebooks without

them being destroyed.

• The second week was good weather considering the time of year, being dry and

not extremely cold.

• The third week brought very low temperatures (-4°C) making it extremely diffi-

cult to work to ones full potential outdoors. These temperatures also made most

tasks quite hazardous due to the slippery conditions.

• Daylight hours were limited to approximately 08:00 to 16:00 over the 3 weeks.


4 Overview of the WHOI Micromodem

The WHOI Micromodem [3] is a modem designed to transmit data acoustically un-

derwater. It operates with a transducer, which can be seen along with the modem in

Figure 2, and it transmits data in discrete packets. WHOI states that a typical range

for shallow-water operation at 25 kHz (the frequency used by all OSL’s modems) is

2.5-4 km. The interface between a host computer and the modem is by sending ASCII

strings over a serial connection.

Packets can be encoded using one of two schemes: frequency-hopping frequency-shift

keying (FSK) or phase-shift keying (PSK), and all packets take approximately 5s to

transmit. FSK packets (packet type 0) can contain up to 32 bytes of data, so using FSK

results in a low data-rate, whereas PSK packets can be from 192 bytes (packet type 1)

up to 2048 bytes (packet type 5). However, in order to be able to decode PSK packets,

a WHOI modem must be fitted with the optional coprocessor.

The modem has approximately 60 firmware parameters, which are stored in permanent

memory and can be set by the user. These cover configuration settings such as the baud

rate of the modem’s serial port, whether certain status messages are sent by the modem

to the host computer, and some factors affecting acoustic output and signal processing.


Figure 2: The standalone Yellowbox modem, with the white 12V battery housed in

the Peli-case, and black BT-2 transducer mounted on a white plate at the bottom of the

photo.

Figure 3: The standalone Towfish modem. The black box at the top is the deck box,

which essentially just connects the modem to a power supply and a host computer. The

cylinder contains the actual modem and is submersible, and the towfish transducer is

shown at the bottom right of the photo. Note the 12V battery is not shown.


5 Experimental Methods

Experiments carried out varied from testing the world model’s functionality to test-

ing the acoustic communication capabilities of the acoustic modem. The underwater

communication channel in the Loch proved to be far more problematic than the world

model’s reliability.

There were two main types of tests carried out during the Loch Earn trials with 3 main

scenarios (modem configurations). The two types of test were:

• World Model (WM) tests

• Acoustic Modem Tests: Packet Error Rate Tests

The 3 scenarios, or modem configurations, for testing each of the above were:

• 2 vehicles on shore

• 2 vehicles in Loch

• 1 vehicle in Loch, 1 standalone modem in Loch

There were many more variations than this, however, for the purposes of demonstrating

how the results were obtained, these methods are sufficient. A brief explanation of each

method follows.

5.1 Two Vehicles on ShoreThe dry tests involved the vehicles sitting in their containers with their transducers

placed next to each other making air the medium between the transducers. This test

was also repeated with several different mediums between the transducers. These

were: water by having the transducers placed in a bucket, a cable wrapped around the

transducers and a wet towel (as suggest by WHOI). By having the transducers placed

in a bucket of water, a controlled test was achieved using exactly the same medium as

the later tests would have but with out having to have the vehicles in the water.

These “dry” tests carried out on the shore gave completely controlled conditions for

testing both the acoustic modem communication and the world model. With satisfac-

tory results from this scenario, the testing procedure was moved on to having one, or

both, vehicles in the Loch.


5.2 Two Vehicles in LochThe experiment using both vehicles in the Loch followed exactly the same procedures

as the shore tests above with the only difference being the vehicles were submerged in

the water and a greater separation distance between the transducers.

5.3 One Vehicle in Loch, One Standalone ModemThis configuration of modems gave a more controlled testing environment than having

both vehicles in the water allowing real time diagnosis of log files on both the trans-

mitting and receiving sides. In this configuration, a standalone modem was commu-

nicating with either Nessie VI or REMUS, where multiple tests were carried out with

varying distances of separation, depths and orientations (of the vehicles and hence

their transducers). As it is logistically difficult to have two vehicles being operated si-

multaneously in the boat that OSL own, this provided an easy way to test the acoustic

communication or WM operation by only taking one vehicle out into deeper water and

having the second modem as a stand alone unit.

5.4 Acoustic Modem TestsThe Packet Error Rate (PER) tests consisted of specifying a desired packet type you

wish to send and at what periodic rate. The program then reads the appropriate amount

of text from a text file and sends it acoustically. Crucially, the receiving end knows

the content of the text file as well as the time that transmission occurs so, therefore,

can determine if it receives the packet correctly. This method of experimentation was

used as knowing when the messages are transmitted, what packet type and the content

allows better debugging capabilities as the acoustic communication channel is then the

only variable between tests.

These tests enabled the team to quantify, as much as possible in the working conditions,

the number of packets lost and the reasons for being lost.

5.5 World Model TestsThe OSL world model operates as a service on each platform, so to test it a set of sim-

ple client programs was required. This test suite implemented a basic mine-counter-

measures mission, where a survey vehicle generated the location of potential targets,

and one or more inspection vehicles navigated to these locations and reported the clas-

sification of the target. The test programs did not include any automated target recog-

nition (ATR), but instead generated fixed target locations and random classifications

(either mine or rock).


The data put into the world model and exchanged between the vehicles comprised

the platforms and their data needs, the location and classification of targets (with the

classification being unknown for new targets), and which platforms were inspecting

which targets.

During the trials, REMUS was designated as a survey vehicle, and Nessie as an in-

spection vehicle. When either of the standalone modems was used with a vehicle, it

assumed the role complementary to that of the vehicle. On REMUS, standard mis-

sions were run, with the world model being used passively to generated fixed-location

targets. On Nessie, the vehicle was stationary until the first target was generated and

the location data exchanged with Nessie, at which point it commenced inspection of

that target. However, during the trials we stopped the controller process on Nessie as

soon as it started to move, as the vehicle moving confirmed that the world model was

functioning correctly, and this avoided the vehicle travelling out of communication

range.


6 Notes on Modem Performance6.1 Firmware UpgradesAt the beginning of the trails, it was realised that most of the acoustic modems that

the OSL own had an old firmware version, and that none of them were on the same

firmware version number. During the initial diagnosis of why some modems were not

communicating with others, this was one of the prime candidates. Thus, it was decided

(having consulted with WHOI) to update the firmware of all modems to the latest

firmware version. This proved to be more difficult than initially thought as several of

the older generation of hardware boards required a CTS cable to enter the bootloader,

as in-situ programming was impossible.

The team then had to develop a workable procedure for upgrading the firmware of both

the modem mainboard and the coprocessor firmware installers using just a console se-

rial program, which required some alterations to WHOI’s documented procedure. It

was discovered that some of the main modem boards were not able to upgrade the

coprocessor’s firmware. Having explored all other possible causes and after much dis-

cussion with WHOI, they suggested moving the coprocessor onto a different modem

board as some of the hardware was a little unreliable when being used to upgrade

firmware. Having swapped boards, the firmware was able to be upgraded without any

further problems.

6.2 Optimising Acoustic PerformanceDuring the course of the trials observations were made regarding the acoustic modem

performance. Multipath has proved to be a major issue, and is exacerbated by several

conditions:

• Small, enclosed water volume. For example, in the OSL test tank (approx 4m

x 3m x 2m deep) the multipath is very bad. However we would expect it to

improve in a large Loch such as the trials location (see section “Overview of

Working Environment and Typical Experiments”)

• Transducers placed near the surface of the water

• Shallow water (especially water less than 2m deep; but even 30m is relatively

shallow compared to ideal operating environments)

• Reflective boundary surfaces, such as rocky lake bottoms/sides, or layered hard-

sediment bottoms

We believe the multipath conditions in Loch Earn were particularly bad. Many of our

experiments were conducted with the transducers close to the surface, but results did


not improve when we had the vehicles operate deeper in the loch. Further experi-

mentation would be needed to confirm whether multipath is the sole cause of the bad

modem performance experienced during trials.

Given these multipath problems, we were unsurprised to find that the low-datarate FSK

packets worked much better than PSK packets. WHOI also suggested to us that we try

a newly-implemented PSK packet type, type 1, and this was found to be more robust

than other PSK rates.

While sound energy will drop off with increasing range, another problem is clipping,

which occurs when the modem transducers are too close to each other and the signal is

saturated. This will occur with ranges of the order of metres, and will affect higher-rate

data exchange much more than FSK or PSK type 1. An ideal range for good reception

would be 10-20m.

Another issue was that the transducers are not omnidirectional in the vertical plane.

This means that BT-2 type transducers should be mounted vertically, i.e. with the dome

pointing either up or down, in order to transmit most effectively to other platforms that

are horizontally displaced from them (with the full beam strength reaching ±30° of

horizontal). This meant the standalone Yellowbox modem transducer in particular had

to be carefullly arranged to hang vertically in the water.

6.3 REMUS ConsiderationsThe configuration of the modem and world model software on REMUS is different

from Nessie in several ways due to REMUS being a commercial product with its own

navigation and control software. This REMUS control software runs on a main vehicle

computer (MVC), and there is a secondary payload computer onboard which we use to

run the world model software. As the MVC needs to send status messages and receive

mission start/abort commands via the acoustic modem, both the MVC and payload

computer need to be connected to the modem. The WHOI modems have two serial

ports to allow for such a setup; however if both the payload and MVC try to send a

command to the modem at the same time, only one will get processed.

To avoid messages being lost due to collisions between the MVC and world model

software, we can set the WM time slots and REMUS status message sending interval

so as to avoid clashes. We can also use a longer time slot for the WM – which can be

doubly beneficial as the onboard CPUs on the REMUS are relatively slow, and take

slightly longer to send data to the modem. Despite these precautions, we suspect there

were still occasional clashes resulting in OSL messages not being sent, which explains

some of the difference in performance between REMUS and Nessie sending messages.

Finally, the REMUS uses a different type of transducer to Nessie and the standalone

modems, and uses a transponder system for navigation, which uses the same trans-


ducer to send interrogation pings to the transponders. Both of these could potentially

negatively impact acoustic communications via the OSL software.


7 Results and Analysis7.1 Modem PerformanceThe data from Figure 4 was collated from 6 different experiments that were run over

a period of several days. This data was mainly collected from executing the packet

error rate test (where packet success rate (PSR) = 1-PER) as well as several runs of the

world model. The PER test was favoured to collect the data as it gave more control

over when the packet will be transmitted, and therefore, expected to be received.

Figure 5 shows the results of a systematic chain of experiments running the PER test

for 10 transmit slots on packet types 0, 1 and 3. Packet type 2 was omitted due to

the modem software needing to be re-compiled. It is possible to see that the perfor-

mances deteriorates over time, when NessieAUV is transmitting. When RemusAUV is

transmitting, the error rate is incredibly high, due to circumstances the team is still

investigating.

Figure 4 shows the relationship between the achieved packet success rate for given dis-

tances for both the REMUS and Nessie vehicles. This highlights problems that were

encountered while transmitting from the REMUS AUV. Strangely, it is only the trans-

mission side of REMUS which encounters poor results. It is seen from Figure 5 that

when REMUS is receiving, some good results are obtained whereas on the previous

graph (with REMUS transmitting) there were few good packets being received.

Figure 4: Packet Success Rate Vs Distance

The error bars shown in Figure 4 are a calculated error margin using the Wilson Score


Figure 5: Packet Type Vs Packet Success Rate

Packet Type Number of Transmits Number of Receives Packet Success Rate (%)

0 10 10 100

1 10 10 100

2 10 10 100

3 10 8 80

Table 2: Nessie to Standalone Modem in Bucket

Interval method to calculate the Binomial proportion confidence interval [4]. The rea-

son for displaying these error margins is that, for each data point shown on the graph,

there were not necessarily the same number of samples thus meaning the probabilistic

accuracy of the PSR varies. This variation is only between 12-14% and 18-22% for

Nessie and REMUS transmitting respectively.

s 2 and 3 are the results of running a PER test in completely controlled conditions

achieved by submersing the Nessie transducer and the standalone modem’s transducer

in a bucket of water on the shore. As can be seen, all but packet type 3 gave 100%

Packet Type Number of Transmits Number of Receives Packet Success Rate (%)

0 10 10 100

1 10 10 100

2 10 10 100

3 10 7 70

Table 3: Standalone Modem to Nessie in Bucket


packet success rate. It is believed that the reason for this working better than in the

Loch, despite being in a round reflective walled bucket, is that the path of the acous-

tics is short enough for there to be virtually no delay at all from reflections. Whereas,

when the distance to reflective walls is increased, such as in the Loch, then the time

difference of the reflections are enough to cause collisions. According to the modem

manufacturer, the multipath phenomenon is the major contributing factor to the prob-

lems encountered by us. It is also believed that the reason for losing several packets of

type 3 in both directions is that a clipping effect is occurring due to the close proximity

of the transducers. This effectively over saturates the signal and, therefore, resulting

in data being lost.

7.2 World Model PerformanceSeveral shore tests and a demonstration in the Loch proved that the world model archi-

tecture worked extremely well. The demonstration showed a vehicle communicating

with a standalone modem, which represented a second vehicle, exchanging each of

their capabilities and ultimately having the search vehicle send the coordinates of a

target position to the vehicle in the Loch. While running this in the Loch, even at fairly

short distances of approximately 30m, the world model had to allow for packets being

lost and the need to re-transmit a packet. Due to the reliable communication distance

being rather limited, there was no need for complicating the test further by having a

third vehicle using the world model. Should there be a third vehicle, however, the

world model incorporates a more sophisticated acknowledgement scheme adopting an

acknowledgement matrix so that if one vehicle does not receive an acknowledgement

it is sent again but from a different platform (vehicle). This helps prevent the system

from getting stuck when two vehicles are out of range of each other but a third vehicle

is between them.

It was learnt that the underwater communication channel and associated hardware

knowledge was the weakest link in the system where the world models performance

suffered from physical communication channel limitations. These limitations allowed,

and forced, the team to look into the operation of the WHOI modems further and the

underwater communication channel characteristics in general.


8 Conclusions and Future Work

The DRDC trials of November 2012 had two key successful outputs:

• Demonstrated the ability to send and receive high data-rate acoustic messages

between vehicles

• Proved the OSL world model software works on-board real vehicles

The key problem that arose during trials was the quality of the acoustic communica-

tion. After speaking to WHOI, we were able to make several improvements to our

modem installations and configuration, and achieve acoustic communications over a

range of 300m for Nessie and 55m for REMUS. Liaison with WHOI was complicated

by the fact they are located in the USA, so as well as a time difference, it was hard for

them to understand exactly the operating environment we had at Loch Earn.

We believe the deficit to the manufacturer’s expected ranges to be due to multipath

in Loch Earn, in the case of Nessie, and additionally to interference with existing

onboard systems on REMUS. Given these limited ranges, it was not practical to run

a full vehicle-to-vehicle test of the world model software. The WHOI modems have

proved to be complex devices, requiring significant time and training to understand

both their control interface and parameters, and how to get the best out of the complex

underwater acoustic channel [5, 6]. Despite this, we were able to test the World Model

in water between a vehicle and a standalone modem, and confirm that data stored into

the ontology on one platform was seamlessly synchronised to the other platform.

The key aims for any future work would be:

1. Identify and solve the problems causing worse range with REMUS than other

platforms.

2. Improve the overall acoustic range, if possible.

For the first aim, we have several ideas:

• Put the REMUS in the water without any transponders around, to try to prevent

it from pinging the transponders, in case such pinging is interfering with the

world model messages.

• Disconnect the REMUS main vehicle computer completely from the modem,

and use the modem’s primary serial connection for the payload computer (which

runs the world model software). This should identify whether or not data sent

by the MVC to the modem is interfering with world model messages.


For the question of overall acoustic range, our first experiment should be to use hy-

drophones to make recordings of acoustic activity in the Loch in the 25 kHz range.

These recordings can be sent to WHOI to analyse the extent of the underlying multi-

path in Loch Earn.

Further ideas are to try Nessie and REMUS in another environment that is less likely

to have multipath, such as an open-sea environment, or potentially even in deeper

sections of Loch Earn with the vehicles at greater depths.

Another possible solution to the problem would be to reduce the transmission power,

which would hopefully lead to less multipath.


References

[1] Maurelli, F., Cartwright, J., and Lane, D. M. (May 2012), Control Architecture

for Multiple Autonomous Unmanned Vehicle Operations - Research Proposal,

DRDC CORA CR 2012-100, Technical Report Heriot-Watt University.

[2] Maurelli, F., Saigol, Z., Cartwright, J., and Lane, D. M. (June 2013), Control

Architecture for Multiple Autonomous Unmanned Vehicle Operations -

Simulation Results, DRDC CORA CR 2013-066, Technical Report Heriot-Watt

University.

[3] Freitag, L., Grund, M., Singh, S., Partan, J., Koski, P., and Ball, K. (2005), The

WHOI Micro-Modem: An Acoustic Communications and Navigation System for

Multiple Platforms, In Proceedings of Oceans ’05.

[4] Wilson, E. B. (1927), Probable Inference, the Law of Succession, and Statistical

Inference, Journal of the American Statistical Association, 22(158), 209–212.

[5] Singh, S., Webster, S. E., Freitag, L., Whitcomb, L. L., Ball, K., Bailey, J., and

Taylor, C. (2009), Acoustic Communication Performance of the WHOI

Micro-Modem in Sea Trials of the Nereus Vehicle to 11,000 m Depth, In

Proceedings of Oceans ’09.

[6] Stojanovic, M. (2007), On the relationship between capacity and distance in an

underwater acoustic communication channel, SIGMOBILE Mob. Comput.Commun. Rev., 11(4), 34–43.


DOCUMENT CONTROL DATA(Security classification of title, body of abstract and indexing annotation must be entered when document is classified)

1. ORIGINATOR (The name and address of the organization preparing thedocument. Organizations for whom the document was prepared, e.g. Centresponsoring a contractor’s report, or tasking agency, are entered in section 8.)

Ocean Systems LabDepartment of Electrical, Electronic and ComputerEngineeringSchool of Engineering and Physical SciencesEarl Mountbatten BuildingHeriot-Watt UniversityRiccarton, Edinburgh, EH14 4AS Scotland

2a. SECURITY CLASSIFICATION (Overallsecurity classification of the documentincluding special warning terms if applicable.)

UNCLASSIFIED2b. CONTROLLED GOODS

(NON-CONTROLLEDGOODS)DMC AREVIEW: GCEC JUNE 2010

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriateabbreviation (S, C or U) in parentheses after the title.)

Control Architecture for Multiple Autonomous Unmanned Vehicle Operations4. AUTHORS (Last name, followed by initials – ranks, titles, etc. not to be used.)

Maurelli, F.; Saigol, Z.; Frost, G.; Tsiogkas, N.; Lane, D. M.

5. DATE OF PUBLICATION (Month and year of publication ofdocument.)

May 2013

6a. NO. OF PAGES (Totalcontaining information.Include Annexes,Appendices, etc.)

32

6b. NO. OF REFS (Totalcited in document.)

67. DESCRIPTIVE NOTES (The category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter

the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period iscovered.)

Contract Report8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development –

include address.)

Defence R&D Canada – CORADept. of National Defence, MGen G. R. Pearkes Bldg., 101 Colonel By Drive, OttawaON K1A 0K2, Canada

9a. PROJECT OR GRANT NO. (If appropriate, the applicableresearch and development project or grant number underwhich the document was written. Please specify whetherproject or grant.)

10bz04

9b. CONTRACT NO. (If appropriate, the applicable number underwhich the document was written.)

W7714-115079/001/SV10a. ORIGINATOR’S DOCUMENT NUMBER (The official

document number by which the document is identified by theoriginating activity. This number must be unique to thisdocument.)

DRDC CORA CR 2013-072

10b. OTHER DOCUMENT NO(s). (Any other numbers which maybe assigned this document either by the originator or by thesponsor.)

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by securityclassification.)( X ) Unlimited distribution( ) Defence departments and defence contractors; further distribution only as approved( ) Defence departments and Canadian defence contractors; further distribution only as approved( ) Government departments and agencies; further distribution only as approved( ) Defence departments; further distribution only as approved( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspondto the Document Availability (11). However, where further distribution (beyond the audience specified in (11)) is possible, a widerannouncement audience may be selected.)

Unlimited

13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highlydesirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of thesecurity classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It isnot necessary to include here abstracts in both official languages unless the text is bilingual.)

This report is the final deliverable of the DRDC - Control Architecture for Multiple AutonomousUnmanned Vehicle Operations prepared under Contract W7714−115079/001/SV . This projectaddresses the topic of a decentralised world model service that operates across multiple under-water vehicles. This document focuses on field trials performed in Loch Earn, in November 2012and follows a previous report documenting the simulation results. Despite some technical prob-lems related to modem use, especially with the REMUS vehicle, the decentralised world modelservice has been successfully demonstrated.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and couldbe helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such asequipment model designation, trade name, military project code name, geographic location may also be included. If possible keywordsshould be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified.If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

auvmission planningworld modellingontologyacoustic communication

control architecture for multiple autonomous unmanned...

Documents