273
1 INTRODUCTION
Autonomous Underwater Vehicles (AUV) are
underwaterrobotsthatoperateontheirownwithout
human support. Thanks to the ability to operate
independently, they can replace people in the
implementation of dangerous underwater missions,
forexample,duringworkrelatedtothemaintenance
ofoilrigsorunderwaterpipelines.
These
vehiclescanalsooperateaspartofteamsor
swarms.Inthefirstcase,thevehiclesusuallyoperate
atadistancefromeachotherandthecommontaskof
theteamisdividedintoseparatesubtasksthatcanbe
performed independently by each team member.
Vehiclesoperatinginteamsmust
alsousuallybefully
equipped with all navigation and sensory devices,
which results from the fact that they operate at a
certain distance from other vehicles and have to
manageontheirown.
Another option is to operate in a swarm. In this
case, the vehicles form a closely cooperating group,
moving in close proximity to each other. This
approach means that a swarm of vehicles can be
consideredasadispersedsingleunderwatervehicle,
oravehicle‐swarm,consistingofcomponentvehicles,
eachofwhichmayberesponsibleforadifferentpart
ofthetaskofthevehicle‐swarm.
Distribution
of competences over many different
vehicles makes individual vehicles in a swarm
cheaper, smaller, lighter and easier to operate than
super‐vehiclesoperatingontheirown.Theproblem,
however, in this case is the organization of
cooperation between the vehicles so that they can
reallybeconsideredasonecompactorganism.
The main objective of European Defense Agency
project category B entitled “Swarm of Autonomous
Biomimetic Underwater Vehicles” (SABUVIS II) to
whichthe current paper isdevotedis to design and
implement a swarm of closely cooperating AUVs,
including the leaders that are responsible for global
swarmnavigationandthefollowers
responsiblefora
specificswarmtask.
The cooperation of vehicles within a swarm, as
mentionedbefore,isaseriouschallenge.Inorderfor
the vehicles to cooperate with each other, operate
close to each other in a specific formation, certain
Design of Software for Underwater Vehicles Operating
in a Swarm
T.Praczyk&K.Naus
PolishNavalAcademy,Gdynia,Poland
ABSTRACT: The paper presents a design of software for underwater vehicles constructed as part of the
EuropeanDefenceAgencyprojectentitledSABUVISII.Sincetheaimoftheprojectistodevelopatechnology
foraswarmofunderwatervehicles,thesoftwareofthesevehicles,in
additiontothefunctionalitiestypicalfor
eachautonomousunderwatervehicle,musthavefunctionalitiesdedicatedtotheswarmofvehicles.Thepaper
presentsthedesignofboththevehicle‐sideandtheshoresidepartofthesoftware.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 18
Number 2
June 2024
DOI:10.12716/1001.18.02.01
274
conditions must be met. These conditions apply to
boththehardwareandsoftware.
Whenitcomestothehardware,itisimportantto
equip the vehicles with sensors that enable
omnidirectional observation of the vehicle
surroundings so that the vehicles are able to track
othervehiclesintheswarmand
detectobstacles.The
necessary equipment of vehicles is also appropriate
navigation. In the case of the leader, these must be
systems that allow navigation over long distances,
while in the case of followers, simpler systems
operatingovershortdistancesaresufficient.
Inthecaseofthesoftwarepart,itis
importantto
handleallhardwaredevicesandon‐boardhardware
systems, provide thevehicle with information about
theexternalenvironment,controlvehiclesathighand
low‐level,controlvehicleinanautonomousaswellas
remote control mode, and handle emergency
situations.
Thepaperpresentsasoftwarearchitecturedesign
for vehicles
built in the SABUVIS II project. The
software consists of a vehicle‐side part and a
shoreside part. The presented architecture assumes
theuseofMOOS‐IvP[1]whichisasetofopensource
C++ modules for providing autonomy on robotic
platforms,inparticularautonomousmarinevehicles.
2 DESIGN
OFHIGH‐LEVELCONTROLSYSTEM
INCLUDINGVEHICLESOFTWARE
COMPONENTS
The high‐level control system (HLCS) is understood
inthepaperasasoftwaresystemwhichmakeshigh‐
level decisions regarding movement of the vehicle,
e.g. turn right, increase speed, go down. The high‐
level decisions are then transformed into low‐level
decisions for vehicle drive, rudder and other
executiveelements.Thetaskoflow‐leveldecisionsis
toreachadesirablestateofthevehicleintheformof
desirable values of vehicle parameters, i.e. heading,
depth,andspeed.
In addition to the HLCS working on the vehicle,
there is also
another system, called Deck Unit (DU),
whichcloselycooperateswiththeHLCSandwhichis
situated on the shoreside. Both HLCS and DU are
design in the same technology, namely, based on
MOOSIvPframework[1].
MOOSIvPisasetofopen‐sourceC++modulesfor
providing autonomy on robotic
platforms, in
particular autonomous marine vehicles. The
abbreviation MOOS comes from “Mission Oriented
OperatingSuiteʺwhereastheabbreviationIvPstands
forʺIntervalProgramming”.
Inthepaper,thehigh‐levelarchitectureofMOOS
IvP software for shoreside and vehicle‐side is
specified.Thearchitectureispresentedintheformof
list
of MOOS IvP applications which constitute the
basiccomponentofeachMOOSIvParchi tectureand
the network of communication links between the
components. Application MOOSDB plays a central
role in both architectures being a communication
mediumbetween most applications belongingtothe
sameMOOScommunity
Thevehicle‐sidearchitectureisdepicted
inFigure
1.ItconsistsofeighteenMOOSIvPapplications,i.e.:
MOOSDB, pJANUS‐MOOSBridge, pShare, pLow‐
LevelSoftBridge, pMission, pRemote, pHelmIvP,
pNodeReporter,pNavigation,pNavDevicesHandlers,
pCamera, pEchosounder, pSonar, pBMS, pLogger,
pGenVehicleState, pContactMgrV20, and
pObstacleMgr. All the applications are outlined
below.
Figure1.Vehicle‐sidesoftwarearchitecture
2.1 MOOSDB
Asalreadymentioned,MOOSDBisacommunication
medium between other MOOS IvP applications. It
storesinformationforother applicationsintheform
of double or string variables. Each variable has a
uniquenameforidentificationandthecontent.Other
applicationscanbebothproducersandconsumersof
theinformation
–theycanproducesomeinformation
by directly writing/updating/sending to MOOSDB a
valueofnamedvariable(operationNotifyinC++code
of an application) or consume information by
subscribing for a selected variables (operation
Registerin C++codeof anapplication).Subscription
foravariablemeansthatasubscribingapplication
is
periodically fed with, say, mails including a list of
variable‐name,variable‐valuepairs.
2.2 pJANUS‐MOOSBridge
Thisapplicationhandlesacousticcommunicationlink
from/tothe vehicle.It reads/writesmessages from/to
hydro‐modemsviaJANUSintermediatelayerofthe
acousticcommunicationsystem.Themessageswhich
are to be sent (selected MOOSDB
variables) are
appropriatelyencodedintheformpreviouslydefined
data structures and then passed on to the JANUS
layer. In turn, messages received from JANUS are
decoded from the structures and then send to
MOOSDBasvariables.
There are at least two variables sent from the
vehicle to the shoreside
or the leader vehicle , i.e.
NODE_REPORT_LOCAL / NODE_REPORT and
REPORT_APP_LOCAL / REPORT_APP. The first
variable stores complete information about vehicle
including such parameters as: (x,y),
(latitude,longitude),depth,speedandotheravailable
parameters. All the parameters are encoded as
275
parameter‐name/parameter‐value pairs, converted
into strings and combined. In turn,
REPORT_APP_LOCAL / REPORT_APP store
information about state of all key applications in
MOOS community which is run on main vehicle
computer. The state of each app is expressed in the
formofasingleintegerwhichcanbethen
converted
intobinaryvalue.
NODE_REPORT_LOCAL /
REPORT_APP_LOCAL are variables relating to the
own vehicle whereas NODE_REPORT /
REPORT_APParein fact NODE_REPORT_LOCAL /
REPORT_APP_LOCAL variables read by the
shoreside and renamed into NODE_REPORT /
REPORT_APP.
2.3 pShare
The difference between pJANUS‐MOOSBridge and
pShare is a communication channel‐pJANUS‐
MOOSBridge
uses acoustic underwater channel
whereaspShareworksonthesurfaceanditusesWiFi
channel.Ineffect,pSharecansendmoreinformation
in shorter time thanpJANUS‐MOOSBridge. For that
reason, pShare, in addition to NODE_REPORT and
REPORT_APP sends also APPCAST varia ble which
storesdetailedstateofaselectedMOOSIvP
app.This
app has to be indicated by APPCAST_REQ variable
which is sent from the shoreside by an appcast
viewer,e.g.pMarineViewer.
2.4 pLow‐LevelSoftBridge
Thisappismeantforcommunicationwithlow‐level
control software which according to assumptions
made in the project works on other computer than
high‐
levelcontrolsystemorevenonmicro‐controller.
Thetask of pLow‐LevelSoftBridgeis tosenddesired
motion parameters of the vehicle stored in variables
DESIRED_HEADING, DESIRED_SPEED and
DESIRED_DEPTHtolow‐levelsoftwarewhosetaskis
toconverttheparametersintocommandsforavehicle
drive.
2.5 pMission
This app manages
missions of the vehicles, that is,
starts and stops mission, and sets parameters of the
missionsuchas:sequenceofwaypoints,marchspeed,
typeofformation,distancesbetweenvehicles,depth,
securityregion,max depth,maxdistance.Moreover,
italsosendstoMOOSDBareportwithmissionstatus,
thatis,whether
themissionisready,run,orstopped.
All the information about the mission which is
processed (parsed) by pMission is sent in MISSION
variable which is a string with parameter‐
name/parameter‐valuepairsseparatedwithcommas.
Each time before the mission is started pMission
examinesthestateofthevehicle.If
thestatemakesit
possibletostartthemission,itisstartedandstateof
the vehicle is appropriately updated through
changing MOOS variables which collectively
determine the state. Otherwise, a message is sent to
the shoreside with the information about reasons of
startmissionfail.
2.6 pRemote
Thisapp
isacounterpartofpMissionwithrespectto
variable REMOTE‐, and remote‐control operation
mode. pRemote reads REMOTE variable from
MOOSDB, parses it, and sends appropriate
commands (MOOS variables) to low‐level control or
activatesvehiclebehaviorresponsibleformovingthe
vehicletoapointindicatedinREMOTEvariable.
Like
pMission,alsopRemoteexaminesthestateof
thevehicle beforeactivating a remote‐control action.
Activationor refusal of the action is associated with
changingthestateofthevehicleoramessagetothe
shoreside with the information about reasons of
remote‐controlactionfail.
2.7 pHelmIvP
Thisis
astandardMOOSIvPappwhichismeantfor
making decisions in autonomous mode. The key
elementofpHelmIvPisasetofbehaviorswhichare
runifthevehicleisinanoperationalmodeassigned
to each behavior. Behaviors activated in the same
modegeneratevehicleactionswhicharereduced
by
pHelmIvP (the so‐called IvP Solver which is a
componentofpHelmIvP)toasingleactionthrougha
process of behavior reconciliation. The same
behaviors can have different instances activated in
differentvehiclemodes.
The list of behaviors usedby pHelmIvPincludes
bothbehaviorsavailableinMOOSIvPand
behaviors
specificforSABUVISIIproject:
1. OpRegionbehavior–thisisastandardMOOSIvP
behavior which provides different safety
functionalities, that is: (i) “do not go beyond a
region” specified by a convex polygon being the
parameter of the behavior, (ii) “do not operate
longer than” a time limit
specified in a behavior
parameter, (iii) “do not go down deeper than” a
depth limit specified in a behavior parameter. If
some safety parameters are exceeded by the
vehicle, pHelmIvp enters the mode which stops
thevehicle.
OpRegionbehaviorwillbeactiveduringthewhole
operation of each vehicle. The
parameters of the
behaviorwillbedeterminedattheverybeginning
of the mission by the operator and they will
remainconstant.
2. ConstantDepth behavior – this is also a standard
MOOS IvP behavior which as its name implies
cares about keeping the vehicle on a constant
depthwhichisa
parameter ofthebehavior. Like
OpRegion behavior also ConstantDepth one will
be active during the whole vehicle mission. This
time, however, parameters of the behavior can
change, depending on the swarm trajectory
definedbytheoperator.
3. MaxDepth behavior – this standard MOOS IvP
behavior which does not “deactivate” pHelmIvP
like OpRegion. It keeps the vehicle above a
threshold which is a parameter of the behavior.
Like the above behaviors, also MaxDepth will be
276
active during the whole vehicle mission for one
invariabledepththreshold.
4. AvoidCollisionbehavior–thisisastandardMOOS
IvP behavior which controls vehicle heading in
caseofanobstacleonthevehicleway.Maneuvers
of the vehicle are made only on the horizontal
plane. The obstacles are in
the form of convex
polygonswhichgroupobstacle point detectedby
vehiclesensorslikesonar.AvoidCollisionbehavior
willhavetobeusedverycarefullybecauseinthe
swarmtherewillbearisktomistakeotherswarm
membersforobstacles.
This behavior will be used on the vehicles if
sensors
areabletodifferentiateothervehiclesfrom
trueobstacles.
5. AvoidCollisionUpDown behavior – this is also
collision avoidance behavior which however
controls depth of the vehicle. It is assumed the
collisionavoidancebehaviorwillbemadebythree
different behaviors, i.e. ConstantDepth,
AvoidCollision,andAvoidCollisionUpDown.The
first behavior will keep the
vehicle close to one
predefineddepth.Ifanobstacleisdetectedonthe
way, at the safe distance from the vehicle,
AvoidCollisionUpDown is activated which forces
thevehicletodecreasedepth(goup).Ifthevehicle
passes over the obstacle, ConstantDepth will
“pull” the vehicle back to the desired depth.
However,iftheobstacleisclosetothevehicle,for
example, it reaches the surface and, in
consequence, it cannot be avoided by “jumping”
overit,thenAvoidCollisionisactivated.
LikeAvoidCollisionalsothisbehaviorwillbeused
onthe vehicles if sensors areabletodifferentiate
other vehicles from true
obstacles.
AvoidCollisionUpDown behavior is a new
behavior which will be implemented within the
project.
6. KeepFormationbehavior–thisbehavioristhemain
objectiveoftheproject.Thetaskofthisbehavioris
to keep a follower vehicle in the swarm. Its
implementationwilldependonthespecificswarm
concept.
For example, keeping the formation by
following the leader in the so‐called fixed
formation will be require a different algorithm
than long cloud formation. The task of this
behavior will be to control heading and speed of
thevehiclebasedontheinformationderivedfrom
vehicle sensors and the distance
to the leader
acquiredviacommunicationsystem.
As alreadymentioned, this behavior will be only
appliedonfollowervehicles.
7. NewWayPoint behavior – this behavior will be a
modification of a standard MOOS IvP behavior
meantforleadingthevehiclealongapathdefined
by a sequence of (x,y) way‐
points. In contrast to
the standard behavior, NewWayPoint will take
into account the sea current which can push the
vehicleawayfromthepredefinedpath.Inorderto
avoid such situation, NewWayPoint will
appropriatelyadjustvehicleheadingandspeedto
the distance to the path. This behavior will be
applied mainly
on the leader vehicles, although,
follower vehicles will be also equipped with this
behavior.
2.8 pNodeReporter
pNodeReporter is a core MOOS IvP app which is
meant for generating NODE_REPORT_LOCAL
variablestoringallthekeyinformationaboutthestate
ofthevehicle.Eachpieceoftheinformationisinthe
form
of parameter‐name/parameter‐value pair
encodedasastring.Allthepiecesarecombinedintoa
single variable by separating them with commas.
NODE_REPORT_LOCAL should be read by all
communication apps, i.e. pShare and pJANUS‐
MOOSBridge,andsentasNODE_REPORT variables
toexternalnodes.pSharereportsaresent directlyto
the
shoreside (when on the surface), whereas,
pJANUS‐MOOSBridge reports are sent either to the
shoreside(leader)ortotheleader(followers).
Example NODE_REPORT_LOCAL is given in
Figure2.
Figure2.ExampleNODE_REPORT
2.9 pNavigation
This app will be responsible for fixing navigation
parameters of the vehicle including (x,y) position,
latitude, longitude, depth, heading, pitch, roll, and
speed. The parameters should be published in
MOOSDB as appropriate variables, e.g. NAV_X,
NAV_Y, NAV_DEPTH, NAV_HEADING,
NAV_SPEED, NAV_LAT, NAV_LON, NAV_ROLL,
NAV_PITCH.Tofixtheparameters,pNavigationwill
be fedwith different navigation devices and sensors
likeIMU,DVL,FOG,pressuresensor,GNSS,satellite
compass.
pNavigation will work according to different
algorithms. The simplest of them will be Extended
Kalman Filter. It will be also possible to equip
follower vehicles with deep learning navigation
systeminwhichthe
positionandspatialorientationof
thevehiclewillbeproducedbydeeplearningneural
networksuppliedwiththesetofIMUs.
2.10 pNavDevicesHandlers
Thisisa single apporasetofapps.Theirtaskisto
provideinformationgeneratedbydifferentnavigation
devices/sensors to pNavigation. For the purpose of
high
speed of processing in pNavigation, the
communication between pNavDevicesHandlers will
beperformedwithoutparticipationofMOOSDBasa
communicationmedium.Tothisend,communication
mechanisms provided by operating system, for
example,socketswillbeapplied.
2.11 pCamera
The task of this app is to handle a camera and to
provide
the whole system the information about
noticed objects such as other vehicles and obstacles.
Thisappiscrucialforcollisionavoidanceandkeeping
formation behaviors. In order to fulfill the task,
277
pCamera has to implement video processing
algorithmswhichshouldbeabletodetectandclassify
visible objects. Since the algorithms require time‐
consuming calculations, the implementation of
pCamerashouldconsiderprocessingonGPU.
pCamera should publish two variables, i.e.
TRACKED_FEATUREandNODE_REPORT.Thefirst
variablecorrespondstonoticedobstacles(position
of
obstacle in local coordinate system) whereas the
second variable corresponds to other vehicles
detected.
2.12 pEchosounder
This is an app for handling echosounder(s) and for
providingthesystemtheinformationaboutdistance
tothebottomandpossibleobjectsabovethevehicle.
2.13 pSonar
Thisappisacounterpartof
pCamera,however,with
respect to sonar which isthe sensor of longer range
thancamerawhichmakesittheprimarysensorwhen
navigatingintheswarm.LikepCamera,pSonarhasto
beabletodetectand classify objects visible insonar
images. What is more, it has to able to differentiate
echoescomingfromtheseabottomandseasurface.In
orderforpSonartobeabletofulfillitstasks,ithasto
implement advanced video stream processing
algorithmsonGPU.
Like pCamera, also pSonar should publish two
variables, i.e. TRACKED\_FEATURE and
NODE_REPORT. The first variable corresponds to
noticed obstacles
(position of obstacle in local
coordinate system) whereas the second variable
correspondstoothervehiclesdetected.
2.14 pBMS
Thisisanappforhandlingbatteries.Ithastoprovide
information about all faults, analyze the situation
regardingenergyconsumption,andnotifythesystem
ifthereisnotenoughenergytocontinue
themission.
The mentioned information should be published to
MOOSDBinthevariableREPORT_BMS.
2.15 pLogger
ThisstandardMOOSIvPappismeantforrecording
selected publications to MOOSDB during the whole
MOOSsession.Itisanappessentialfromthepointof
viewofpost‐sessionanalysis.Theapp
isconfigurable,
that is, it allows for synchronous and asynchronous
loggingandselectionofMOOSvariableswhichareto
belogged.
2.16 pGenVehicleState
Itiscrucialappforsafetyofthevehicle.Itisassumed
that selected MOOS apps (the ones which are
necessary for the vehicle to operate) periodically
publish
theirstatetoMOOSDBintheformofinteger
variableREPORT_(APP)where APPisa labelofthe
app.pGenVehicleStatemonitorsthestateofallapps,
generates one cumulative report
(REPORT_APP_LOCAL)fortheshoreside(stateofall
appspluscurrentactionperformedbythevehicle,e.g.
remote control: turn right,
mission, returning to a
specified point, waiting for orders, breakdown) and
appropriately reacts if the state of the vehicle is
insufficientwithrespecttoperformedmission/action.
2.17 pContactMgrV20
This is a standard MOOS IvP app whose task is to
generate alerts regarding other vehicles visible
around.Theinformationaboutthesevehicles
isgiven
in NODE_REPORT variable whichcan be published
by vehicle sensors (pCamera, pSonar) and
communication apps (pShare, pJANUS‐
MOOSBridge).Thealertsarethenreadbyappropriate
behaviors (AvoidCollision, AvoidCollisionUpDown,
and KeepFormation) which adjust operation of the
vehicletothesituationaround.
2.18 pObstacleMgr
ThisisacounterpartofpContactMgrV20
withregard
to motionless obstacles reported in variable
TRACKED_FEATURE. In addition to alerts which
indicateparametersofobservedobstacles,andwhich
are then used by appropriate vehicle behaviors, the
taskofpObstacleMgrisalsotocompressinformation
provided by a sequence of TRACKED_FEATURE
publications. pObstacleMgr reads positions of the
obstacles and
builds convex polygons for each
obstacle. This way, the behaviors do not deal with
sequencesofpointsbutwithcompressedobjects.
3 DESIGNOFHIGH‐LEVELCONTROLSYSTEM
INCLUDINGDECKUNITSOFTWARE
COMPONENTS
The shoreside architecture is depicted in Figure
\ref{fig:moosBrzeg}. It consists of nine MOOS IvP
applications, i.e.: MOOSDB,
pJANUS‐MOOSBridge,
pJoystick, pMVEventHandler, pVehicleStateViewer,
pMarineViewer, uXMS, uPokeDB, pShare. All the
applicationsareoutlinedbelow.
Figure3.Shoresidesoftwarearchitecture
278
3.1 MOOSDB
MOOSDBapplicationisalready described in section
2.1MOOSDB
3.2 pJANUS‐MOOSBridge
In order to handle communication with a vehicle
pJANUS‐MOOSBridgeapplicationhastoknowwhich
MOOSvariablesaretobesentandreceived.Outgoing
messages relate to MOOS variables subscribed by
pJANUS‐MOOSBridge application. There are
three
such variables, i.e. REMOTE, MISSION, and
NAVIGATION. All of them are string variables
includingasequenceofparametersencodedasstrings
andseparatedbycommas.
REMOTEvariableincludesparametersforremote‐
control, e.g. turn right, speed up, go to the point
(10,10), heading 90 deg., speed 1 m/s. MISSION
variableincludesactionstoperformregardingvehicle
mission, i.e. start or stop mission, or it defines
parameters of mission, e.g. safety parameters (max
depth, max distance to cover, accepted operational
area),type of swarm,distances between individuals,
path(forswarmleader),communicationintervals(for
swarmleader).And,NAVIGATIONvariableincludes
parameters
fornavigationsystemofeachvehicle.The
keyparameteristheoriginofthecoordinatesystem,
thesameforallvehicles–geographicalcoordinatesin
theformoflatitudeandlongitude.
InadditiontooutgoingMOOSvariables,pJANUS‐
MOOSBridge has to know incoming variables. They
will be encoded in appropriate
data structures and
sentinacompressedform.Thenameofthevariable
will not be encoded as a string but as an integer.
Meanwhile,MOOSDBneedsthenameofthevariable
notaninteger.Inconsequence,pJANUS‐MOOSBridge
needsmappingbetweenintegersandvariablenames.
3.3 pShare
This application is
a counterpart of pJANUS‐
MOOSBridge, however, with respect to WiFi
communicationlink.Itisa standardMOOSIvPapp
which needs to be configured in a “.moos”
configuration file which defines the whole MOOS
community–eachappbelongingtothecommunityis
defined in the file by a list
of configurable app
parameterswiththeirdefaultvalues.pSharehastwo
parameters, i.e. configuration of input channel
(number of port used by pShare for input and
multicastnumberifused)andalistofoutputMOOS
variableswithassignedparametersofoutputchannel
toeachofthem(IPandthenumber
ofportofpShare
working on a vehicle). Detailed specification of
pSharecanbefoundin[2].
In addition to REMOTE, MISSION, and
NAVIGATION variables, pShare will also send
APPCAST_REQ variable. This variable is generated
by each appcast viewer application like
pMarineVieweranditisdirectedtoselectedappcast
apps
with request to send the so‐called appcast
reportswhichincludethestateoftheappintheform
ofappropriatelyformedstring.
3.4 pJoystick
ThisapplicationismeanttohandleJoystick.Inorder
for pJoystick to start working, it has to be
intentionally activated by sending REMOTE_CONF
messagewithactivation
stringasavariablevalue,e.g.
REMOTE_CONF=”activate”. The same applies to
stopping the app. In this case, REMOTE_CONF
should take deactivating value, e.g.
REMOTE_CONF=”deactivate”. Once activated,
pJoystick reads messages sent by Joystick, converts
themintoREMOTEmessages,andfinallysendsthem
to MOOSDB using Notify operation. After receiving
newvalue
ofREMOTE,MOOSDBsendsittopShare
and pJANUS‐MOOSBridge which send it further to
thevehicle.
3.5 pMVEventHandler
This app is intended to handle events generated by
DeckUnitappcalledpMarineViewer[3](seefurther).
pMarineViever is a standard MOOS IvP app which
generatesthreetypesofevents,i.e.:(i)
pressingoneof
four buttons – each button has variable‐
name/variable‐value pair assigned in “.moos”
configuration file, (ii) changing app context by
clockinganoptioninthemenu,(iii)pressingamouse
button. pMVEventHandler will cooperate with
pMarineViewer by intercepting events generated by
the latter app and by sending
appropriate orders to
pMarineViewertodisplayobjectsonthe map which
relatetotheevents.Forexample,ifpMarineVieweris
in generating path for the swarm mode (an
appropriate menu option) then each mouse click on
themapwillbereceivedbypMVEventHandlerwhich
will instruct pMarineViewer to draw a way
‐point in
the clicked position and to link it with neighboring
way‐points,throughdrawingaline.Aftercompleting
path definition, a button on pMarineViewer can be
pressed which should run pMVEventHandler
window aimed at specifying other mission
parameters, e.g. depth, distance for each vehicle,
safetyregion.
Thewholefunctionality
ofpMVEventHandlerwill
be strongly linked to pMarineViewer functionality
whichinturn will dependon taskswhich the entire
Deck Unit will have to perform. At the point of
writing this paper, three main functionalities have
beenidentified,i.e.missiondefinition(pathconsisting
of a sequence of way‐points), monitoring of
swarm
(individualvehicles)behavioronthemap,monitoring
of MOOS IvP appcast applications. Only the first
functionalitywillrequirepMVEventHandlerreaction.
3.6 pVehicleStateViewer
The task of this app is to view the state of each
vehicle. This state will be defined in a number of
MOOSvariables.Infact,pVehicleStateViewer
willdo
the same what pMarineViewer can do, without
viewing geoinformation. The idea is however, to
organizetheviewinamoreconvenientwaythanitis
donebypMarineViewer.Thatis,auserwillbeableto
choose vehicle and MOOS variable describing its
state. Then, all theparameters stored
inthevariable
will be displayed ina compact form. What is more,
279
the task of pVehicleStateViewer will be also to
generate log files for each vehicle. Each log will
include selected parameters from differentvariables.
pVehicleStateViewer will be configured either in a
“.moos”oraseparateXMLfile.
3.7 pMarineViewer
This app has already been mentioned above. It is a
standardMOOS
appwhichhastwomaintasks.First,
it is the only app which is able to process
geoinformation, that is, to define way‐points
determining the desired path of the swarm, and to
monitor position of each vehicle. Second, it is also
meant for monitoringdifferent MOOS variables and
state
of MOOS apps. Example widow of
pMarineViewerisdepictedinFigure4.
AnadditionalfunctionalityofpMarineVieweristo
notify MOOSDB about new values of variables
definedin“.moos”configurationfile.Itmeansthatif
weknowexpectedvaluesofthevariablesinadvance,
we can assign variable‐name/variable‐value pairs
to
selectedactioncomponents(differentbuttons,menu)
ofpMarineViewerandactivatethematanymoment.
Figure4.ExamplewidowofpMarineViewerapp[3]
3.8 uXMS
This is a standard terminal‐based MOOS app for
viewingthecontentofMOOSDB.Thecontentcanbe
displayed in different manner. The user can choose
variables to show, can show history of variable
updatesorcanshowvariablespublishedbyaselected
app. Example window of uXMS is
depicted in
Figure5.
Figure5.ExamplewindowofuXMSapp[4]
3.9 uPokeDB
This is a terminal‐based app for poking MOOSDB,
thatis,forupdatingthecontentofMOOSDB.Tothis
end, one indicatesMOOS community (“.moos” file),
andalistofvariable‐name/variable‐valuepairs.
uPokeDB is a supporting app for
pMVEventHandlerandpMarineViewerwhichisable
tosetvalues
ofvariableswhicharenothandledbythe
twolatterapps.
4 SUMMARY
The paper presents the software architecture for
underwater vehicles operating in a swarm. The
proposed architecture is consistent with the MOOS‐
IvP approach in which we are dealing with many
applications cooperating with each other using one
medium,whichistheMOOSDBapplication.
On the vehicle side, the architecture includes
applications responsible for the following
functionalities: handling navigation and observation
devices and sensors, handling the battery system,
generatinglogs,communication,highandlow‐level
control including swarm control, remote control,
handling emergency situations, generation of
messagesaboutthe
status of thevehicle.Inturn,on
the shoreside, the architecture includes applications
responsible for the following functionalities:
communication, monitoring the status of vehicles,
generatingoutputmessagesandcommands.
REFERENCES
[1]Link: https://oceanai.mit.edu/moos‐ivp/pmwiki/pmwiki.
php?n=Main.HomePage
[2]Link: www.moos‐ivp.org : Manifest‐P Share browse
(mit.edu)
[3]Link: https://oceanai.mit.edu/ivpman/pmwiki/pmwiki.
php?n=IvPTools.PMViewer
[4]Link: https://oceanai.mit.edu/ivpman/pmwiki/pmwiki.
php?n=IvPTools.UXMS
