Getting Started with MOOS-IvP on the REMUS
Michael Benjamin and Maurice Fallon and later Liam Paull
October 6, 2015
1
Purpose of This Document
This document serves as an aid to executing initial missions on the MIT REMUS-100 platform at
the MIT Sailing Pavilion. It accompanies a simple “Hello World!” set of mission files.
2
The Alvin Mission
The Alvin mission is a simple mission for execution at the MIT Sailing Pavilion. It consists of a
small survey and some safety measures. The idea is shown in Figure 1. The large polygon represents
a safety op-box. In the figure the simulated UUV is just starting its mission and is heading for its
first waypoint — in front of Killian Court.
Figure 1: The Alvin Mission: The Alvin mission consists of a small survey at a depth of 2
meters.
3
Software Required
You will need to check out and compile the following:
• The MOOS-IvP tree moos-ivp.org
2
• The moos-ivp-remus tree http://oceanai.mit.edu/moos-ivp/pmwiki/pmwiki.php?n=Tree.
Remus
• Goby 2.0 or later gobysoft.org
This document deals primarily with the contents of the moos-ivp-remus tree, which consists really of three main components: software for interfacing with the REMUS (iRecon), acoustic message
definitions for command/control and monitoring of the AUV through MOOS-IvP, and a mission
structure for testing the system in progressively more realistic scenarios until final deployment of
the REMUS in the water.
It is assumed that a user account has been made on the REMUS payload computer named
ruser, short for “robot user”. This is a generic account that has certain read-only privileges on the
oceanai server. There is also a generic iver account for similar usage on the Iver2 UUVs. We may
make a generic remus account if desired.
3.1
The MOOS-IvP Tree
With the exception of the Gobysoft libraries, all software required to run the Alvin mission in
simulation is contained in the publicly available MOOS-IvP tree.
www.moos-ivp.org/download.html
This software should be downloaded directly on to the REMUS payload computer under the
ruser generic account. I recommend downloading the SVN trunk, but the latest stable release
of MOOS-IvP is another option. This tree includes the MOOS code from Oxford. To build the
moos-ivp tree fully, including the GUI related applications, one would need to install the graphics
related libraries described in the README.txt file. These are unnecessary on the UUV, and the
build can be configured to not build these applications. Alternatively one can launch the build
script with the -k option which is the standard make option to skip over un-built targets to build
all later targets.
3.2
The moos-ivp-remus Tree
To run the Alvin mission on the REMUS requires the iRecon process. This provides an interface between the MOOS payload computer and the REMUS front-seat computer via the Hydroid RECON
interface.
The iRecon process is located within the moos-ivp-remus tree and can be accessed as follows:
$ svn co https://oceanai.mit.edu/svn/moos-ivp-remus/trunk moos-ivp-remus
3.3
Goby-Acomms Tree including pAcommsHandler
NB: The Level 1 mission (SIMULATE auv only) can be completed without installing
goby-acomms. Skip to Section 5.1 if you wish and return here afterwards.
The Goby Acomms project has recently transitioned outside of moos-ivp-local Documentation
is available at gobysoft.com and the code is hosted at https://launchpad.net/goby. It also uses
bazaar instead of svn for version control. Please check out the version 2 branch of the project:
$ bzr branch lp:goby/2.0 goby_2.0
Follow the instructions in the root directory to build pAcommsHandler.
3
4
An Overview of the moos-ivp-remus Tree
Following a fresh checkout of the mission-ivp-remus tree, the following subdirectories will be created:
$ cd moos-ivp-remus/
$ ls
bin
build
build_proto.sh
build.sh
cmake
CMakeLists.txt
docs
lib
missions
README
src
The contents of each directory is as follows:
• bin - the location of compiled binaries (add to $PATH)
• build - the location of compilation files
• build.proto.sh - script for running the protobuf compiler on the *.proto message definitions
• build.sh - script for compiling protobufs into a library and iRecon into an executable binary
• cmake - contains FindGoby.cmake which tells compiler where to find goby
• CMakeLists.txt - top level CMakeLists file
• docs - these docs
• lib - this will contain the compiled message library once it’s made
• missions - more details on this in Sec. ??
• README - self-explanatory
• src - iRecon and protobuf source files
4.1
The mission subfolder
The mission subfolder contains all the necessary mission files. NB: the only thing that makes
this mission folder “REMUS” specific is the inclusion of iRecon in the final mission
(m4). This mission structure could easily be adapted to any other AUV by substituting iRemus for the appropriate frontseat-backseat MOOS application interface (e.g.
iOceanServerComms for Iver)
The following is the contents of the mission subfolder
• acomms - the id lookup file for mapping names to ids, and the goby store server config file
for simulating acomms. For more details see Section 5.2.
4
• bhv files - behavior-related files defining the mission that pHelmIvP will control. See Section
4.3.
• plugs - a series of reusable individual moos process configuration processes. Many of these
blocks are common across all of the tutorial missions
• tools - a coordinate conversion matlab script and remus missions files for use in frontseat VIP
software.
Additionally, there are four mission directories (m* preceeded by SIMULATE and REAL) are
discussed in Section 5.
4.2
Typical MOOS mission
A typical MOOS-IvP mission requires a .bhv and .moos configuration file for each mission. The
remus.bhv file serves as the helm configuration file for both simulation and field operation of the
AUV.
The remus.moos file is the AUV’s MOOS mission configuration file and the shoreside.moos file
is the MOOS configuration file for field operation.
4.2.1
nsplug:
nsplug is a scripting module used to assemble a full MOOS mission configuration file from a set
of individual process moos files — while also inserting specific settings and parameter names into
each file.
As mission configuration often requires 100s of configuration parameters, a single scripting error
can result in mission failure. Using nsplug allows for settings to be accurately shared across multiple
AUVs or between simulation and real operation while minimising the risk of a typo in the moos
script.
Each mission directory contains an expand nsplug.sh script which carries out this operation by
calling nsplug on a META shoreside or META remus mission file and forming the final mission
script.
In each mission folder, the mission parameters are inputted by including *.def files which are
in a folder called configs.
The behavior file is also generated by nsplug in a similar way. The behavior file remus bhv.def
and the META remus.bhv files are in the bhv files directory since they are common for each of the
four missions.
NB: the following warning (or something similar) is normal and is caused by the fact that
clicking on pMarineViewer display causes the generation of XPOS and YPOS but nsplug doesn’t
know about these variables at the time of generating the .moos file.
Warning: The following line of META_remus.moos (creating remus.moos)
may contain an undefined macro on Line: 48
>
right_context[remus] = ACOUSTIC_MOOSPOKE ="RPT=points=$(XPOS),$(YPOS)"
5
4.2.2
Launching scripts:
Each mission directory contains a handy script for launching the MOOS community. The script
begins launch . It is a convention used in other example missions distributed and documented on
the moos-ivp.org site. It is particularly handy for launching simulations with multiple UUVs.
Note that where a separate launch script is required, it is named to indicate which computer it
should be launched from e.g. launch remus.sh
More info about MOOS, MOOS-IvP and the conventions within the community can be found
in [1] or [2].
4.2.3
Shutting things down:
I typically use the command
$ killall pAntler
Pro Tip: you may even want to alias this to somethimg shorter.
4.3
The Behavior Configuration File
The helm, pHelmIvP module for the Alvin example mission is configured in remus.bhv, which is
generated by running expand plugs.sh in one of the mission folders. It consists of three simple
behaviors. The META remus.bhv file is short and given entirely in Listing 1 below. All variables
marked as $(·) are loaded from the remus bhv.def file.
Listing 1 - The META remus.bhv configuration file for the IvP Helm.
//-----------------------------------------------// File: remus.bhv
// Name: M. Benjamin and later L. Paull (2015)
// Date: Nov 26th, 2010
//-----------------------------------------------#include ../bhv_files/remus_bhv.def
initialize
initialize
DEPLOY = FALSE
RETURN = FALSE
//-----------------------------------------------Behavior = BHV_Waypoint
{
name
= waypt_survey
pwt
= 100
condition = (DEPLOY == TRUE)
condition = (RETURN == FALSE)
endflag
= RETURN=TRUE
lead = 8
speed = $(SURVEY_SPEED)
radius = 4.0
nm_radius = 10.0
updates = WPTS
points = $(SURVEY_POINTS)
nostarve = NAV_X, NAV_Y, 5.0
}
// meters per second
6
//-----------------------------------------------Behavior = BHV_Waypoint
{
name
= waypt_return
pwt
= 100
condition = (DEPLOY == TRUE)
condition = (RETURN == TRUE)
perpetual = true
lead = 8
speed = $(RETURN_SPEED)
// meters per second
capture_radius = 5.0
updates = $(RETURN_PT_MOOS_VAR)
points = $(RETURN_POINT)
nostarve = NAV_X, NAV_Y, 5.0
}
//-----------------------------------------------Behavior = BHV_ConstantDepth
{
name
= const_depth_return
pwt
= 100
condition = (RETURN == TRUE)
condition = (DEPLOY == TRUE)
duration
= no-time-limit
depth = 0
}
//-----------------------------------------------Behavior = BHV_ConstantDepth
{
name
= const_depth_survey
pwt
= 100
condition = (DEPLOY == TRUE)
condition = (RETURN == FALSE)
duration
= no-time-limit
depth = $(SURVEY_DEPTH)
}
//-----------------------------------------------Behavior = BHV_OpRegion
{
name
= op_region
pwt
= 100
condition = (DEPLOY == TRUE)
max_time
polygon
trigger_entry_time
trigger_exit_time
=
=
=
=
600
$(OP_REGION_POLY)
2.0
1.0
}
And here’s the contents of the remus bhv.def file:
#define SURVEY_POINTS -143,-141:89,-36:109,-71:-106,-175:-88,-207:129,-100:0,-40
#define RETURN_PT_MOOS_VAR RPT
#define RETURN_POINT 9,-14
7
#define
#define
#define
#define
SURVEY_SPEED 1.5
RETURN_SPEED 1.0
SURVEY_DEPTH 2.0
OP_REGION_POLY -200,-100:-100,-250:200,-100:144,3:84,35
The Waypoint behavior is configured with seven simple waypoints. This behavior is not configured to repeat its points. When it is finished, it is finished permanently. This can be changed
with the perpetual flag as described in [2]. The ConstantDepth behavior is provided to keep the
vehicle at a survey depth of 2 meters. The OpRegion behavior provides two safety checks. It limits
the total mission time to 600 seconds and limits the vehicle operation to be within the polygon
specified and rendered in Figure 1.
A good safety check would be to alter the max time and the polygon to allow the vehicle to
violate their limits and check that the helm properly posts the flag IVPHELM ENGAGED="DISENGAGED",
and that the iREMUS module properly reads this handles this properly by either bringing the vehicle
back to the surface, or handing control back to the REMUS front-seat computer, or both.
5
Training Missions
So as to allow users to easily understand the role of each of the sub systems of the MOOS-IvP
AUV system this tutorial is broken down into 5 increasingly complicated missions. An overview of
the 5 missions is as follows:
• m1 SIMULATE auv only: A beginner-level simulated mission which demonstrates the motion the
AUV is expected to make. The HelmIvP behavior configuration in this mission is common
to all subsequent missions (i.e. the vehicle does the thing it will be expected to do but in
simulation).
• m2 SIMULATE auv and shoreside acomms: The same mission as above except with the addition of
SIMULATED acoustic communication between the AUV MOOS community and a simulated
shoreside MOOS community commanding the AUV. This is mission to use to test and perfect
your acoustic packet designs.
• m3 REAL auv shoreside acomms no recon: Again maintaining the same mission, but now transferring the AUV MOOS community to a separate computer1 and integrating real WHOI
MicroModem hardware.
• m4 REAL auv shoreside acomms with recon: In this final mission the MOOS community will
interface directly with the main REMUS computer via RECON - but in simulation. Using
the REMUS simulation mode allows operation using exactly the same procedure and settings
as one would use in a real experiment.
• Actual Operation: Using EXACTLY the same mission configuration as in the previous example, the real world mission can be carried out.
Also see Figure 2 for an overview of each mission.
1
Not necessarily on the AUV
8
(a) Simulated AUV alone
(b) SIMULATED
acomms
(c) REAL AUV and shorseide acomms, no
RECON
auv
and
shoreside
(d) REAL AUV and shoreside acomms,
with RECON
Figure 2: The four levels of this training manual: from simulation to real world operation. Real
world operation uses exactly the same configuration as the final simulation
9
5.1
SIMULATE auv only
Located in the folder m1 SIMULATE auv only is the most basic tutorial mission. The mission can
be compiled from the required plugs by entering:
$ ./expand_nsplug.sh
And launched as follows
$ ./launch_remus.sh
This example mission is configured to launch all MOOS processes and the helm, with the helm
in a stand-by (‘‘PARK’’) mode (‘‘MOOS MANUAL OVERRIDE=TRUE’’).
The pMarineViewer window should pop up with the vehicle as shown in Figure 1. This is the
same pMarineViewer window that you will see when the real mission is run.
There are four buttons in the bottom right corner, “ENGAGE”, “ABORT”, “DEPLOY” and
“RETURN”. Push the “DEPLOY” button to start the vehicle in motion. In this simulation mode,
this pokes the DEPLOY=true message to the MOOSDB which triggers the conditions to be met for
the survey waypoint behavior. In water, this triggers an acoustic packet to be generated which is
sent to the vehicle. More on this later (The same goes for everything else described here).
The status of the vehicle can be monitored at the bottom of the screen.
Pushing the “RETURN” button invokes the return waypoint behavior and you should see the
survey path disappear and be replaced by a single point in front of the dock. Additionally, you can
update the return point by right-clicking on the display. In field operations, this method is used to
slowly guide the vehicle into the dock for recovery.
At this point, the “ENGAGE” button does nothing at all. In this future this button will be
used to transfer control from the frontseat vehicle controller to the backseat MOOS control.
The “ABORT” button should immediately halt the vehicle. Note that in the real water scenario,
the “ABORT” button will return the control to the frontseat, in which case the vehicle may
not completely stop, but will continue the frontseat mission that it was performing before the
“ENGAGE” button was pressed.
5.2
SIMULATE auv and shoreside acomms
Located in the folder M2 SIMULATE auv shoreside acomms: This mission adds a shoreside MOOSDB
communicating with the AUV using (simulated) acoustic communications using goby. Note that
compared to M1 there are now two META files (shoreside and remus) as well as two def files in
configs and two lines in the expand plugs.sh script and that the launch.sh has been replaced with
launch remus and shoreside.sh. The “virtual ocean” is implemented with the goby store server
application, which is effectively a database server, and is also launched in launch remus and shoreside.sh.
The main changes to the META remus.moos file are that the pMarineViewer application has been
removed (it is moved to the shoreside), and the new application for handling acoustic packet transmission and reception, pAcommsHandler, is included. This is a good configuration to test out new
message definitions.
Included in the distribution are 4 message definitions as protobuf files in /src/protobuf . They
are as follows:
• acoustic moospoke.proto: The listing is given below:
10
import "goby/acomms/protobuf/dccl_option_extensions.proto";
message acoustic_moospoke
{
option (dccl.msg).id
= 102;
option (dccl.msg).max_bytes = 32;
required string moos_var = 3 [(dccl.field).max_length = 10];
required string val
= 4 [(dccl.field).max_length = 19];
}
which gives the ability to pass ANY MOOS variable through acoustics by posting something
like:
ACOUSTIC_MOOSPOKE="MOOS_VAR=val"
Note in this case the var and val are cut at 10 and 19 characters respectively.
• binary moospoke.proto: The listing is given below:
import "goby/acomms/protobuf/dccl_option_extensions.proto";
message binary_moospoke
{
option (dccl.msg).id
option (dccl.msg).max_bytes
enum Var
enum Val
required
required
= 103;
= 32;
{DEPLOY = 1; MOOS_MANUAL_OVERRIDE = 2; RETURN = 3 ; RECON_ENGAGE = 4; RECON_XM
{TRUE = 1; FALSE = 2;}
Var moos_var = 1;
Val bool_val = 2;
}
This message gives a more efficient way of passing variables that are either “TRUE” or
“FALSE” than passing them as strings as with acoustic moospoke. The different variables
that can be transmitted are enumerated in Var. In the example mission, both acoustic
moospokes and binary moospokes are triggered by pMarineViewer. Pressing the buttons
initiates binary moospokes for mission variables, and right clicking on the display initiates an
acoustic moospoke that transmits the new waypoint.
• node report.proto: The listing is given below:
import "goby/acomms/protobuf/dccl_option_extensions.proto";
message node_report
{
option (dccl.msg).id
= 101;
11
option (dccl.msg).max_bytes = 32;
optional string TIME = 1 [(dccl.field).max_length=3, default="NOW"];
enum VehicleType {uuv = 1; usv = 2; ship = 3; glider = 4; }
enum VehicleName {remus=1;iver=2;}
enum VehicleMode {PARK=1;DRIVE=2;DISENGAGED=3;NOHELM=4;}
optional VehicleType TYPE = 3 [default=uuv];
required VehicleName NAME = 4;
required VehicleMode MODE = 5;
required double X = 6 [(dccl.field).max = 1000, (dccl.field).min = -1000, (dccl.field).
required double Y = 7 [(dccl.field).max = 1000, (dccl.field).min = -1000, (dccl.field).
required double SPD = 8 [(dccl.field).max = 5, (dccl.field).min = 0, (dccl.field).preci
required double HDG = 9 [(dccl.field).max = 360, (dccl.field).min = 0, (dccl.field).pre
required double DEP = 10 [(dccl.field).max = 100, (dccl.field).min = 0, (dccl.field).pr
required double LAT = 11 [(dccl.field).max = 43, (dccl.field).min = 41, (dccl.field).pr
required double LON = 12 [(dccl.field).max = -70, (dccl.field).min = -72, (dccl.field).
}
This message is sent from the vehicle back to the shoreside and automatically parsed to
generate a node report which is displayed by pMarineViewer.
• view point.proto: The listing is given below:
import "goby/acomms/protobuf/dccl_option_extensions.proto";
message view_point
{
option (dccl.msg).id
= 105;
option (dccl.msg).max_bytes = 32;
required double x = 3 [(dccl.field).max = 500, (dccl.field).min = -500, (dccl.field).pr
required double y = 4 [(dccl.field).max = 500, (dccl.field).min = -500, (dccl.field).pr
optional string label = 5 [(dccl.field).max_length = 10];
}
This message is used to send back the new waypoint confirmation so that it can be updated
on the pMarineViewer display. As a result, we should be able to infer where the vehicle is
heading (at least at the time that the last acoustic message was sent).
NB: for this mission to work correctly, the protobufs must be properly compiled.
This can be done by running:
$ ./build_proto.sh
$ ./build.sh
in the top level directory. To confirm that this has happened properly you should now
see the libremusprotobufs.so in the lib directory.
Also launched will be pAcommsHandler for both MOOSDBs. The pAcommsHandler is used in
this case to handle the queueing of messages (deciding which stuff to send) and also the encoding
12
and deconding of variables, as well as the medium access control (MAC) for determining which
nodes in get to transmit at which times. The same configuration for pAcommsHandler is used for
the shoreside and the vehicle. In the plug for pAcommsHandler, you will see a block for each of
the protobufs just described in the queue cfg and a seperate translator entry. For example, for
the node report message the translator entry block is:
translator_entry {
protobuf_name: "node_report"
trigger {
type: TRIGGER_PUBLISH
moos_var: "NODE_REPORT_LOCAL"
}
create {
technique: TECHNIQUE_COMMA_SEPARATED_KEY_EQUALS_VALUE_PAIRS
moos_var: "NODE_REPORT_LOCAL"
}
publish {
technique: TECHNIQUE_COMMA_SEPARATED_KEY_EQUALS_VALUE_PAIRS
moos_var: "NODE_REPORT"
}
}
which tells pAcommsHandler when and how to create a node report and how to publish it (in
this case using the TECHNIQUE COMMA SEPARATED KEY EQUALS VALUE PAIRS).
You can use pAcommsHandler’s visual interface to keep track of modem traffic, see Figure 3.
Note that pLogger is also configured to launch, which will log both the AUV and the shoreside
mission data.
The mission is deployed, controlled and observed throught the pMarineViewer display in the
same way as with mission m1, however in this case node report updates are much less frequent.
As the mission proceeds vehicle positions will be transmitted from the AUV every 10 seconds
and displayed by pMarineViewer as see in Figure 4.
At this point the user should launch the mission and confirm that all anticipated functionality
is working correctly through the pMarineViewer interface.
5.3
REAL auv shoreside acomms no recon
In this mission, operation will be as in previous missions — however we will utilize the REMUS
playload as well as actual acoustic modem hardware. Connect the acoustic modem to the laptop
and use a 12 volt battery to power it. Make sure to place it beside the REMUS transducer to
ensure successful transmission.
To log onto the payload computer: start the AUV by removing the magnet and make sure
that the vehicle first communicates with the Hydroid VIP program. The following are the vehicle
computer ip addresses and the login information
mitremus.csail.mit.edu (within csail)
192.168.1....
71 - vehicle frontseat
72 - sidescan
13
Figure 3: pAcommsHandler visual GUI mode: Two instances of pAcommsHandler - one for
the UUV (left) and the shoreside (right). The MAC blocks indicate that control of communication is
only from the shoreside. Other interesting blocks include (4) Decoder messages: showing messages
which have been received, decoded and publised to MOOS; (8) Outgoing: showing which message
was most recently sent and (10 & 11) I/O between the actual hardware and the application.
Figure 4: pMarineViewer during ops: This figure appears exactly as the mission would appear
in a real mission. Note the infrequent updates of the vehicle position.
14
74 - payload or RECON computer
75 - topside
Payload computer account:
username: ruser
password: usual pwd
Log onto the payload computer.
Take a look at the Micromodem configuration blocks. In this case, the laptop and the REMUS
will access a USB (ttyUSB0) and serial (ttyS1) respectively. To verify that the modems are working
properly, launch the minicom utility. You will observe the MicroModem status message every 10
seconds as follows
$ minicom -D/dev/ttyUSB0
$CAREV,085820,INIT,0.93.0.30*55
$CAREV,085820,AUV,0.93.0.30*0D
To demonstrate that the modem can transmit via the transducer, send it a polling request:
printf ’$CCMPC,1,2\r\n’ > /dev/ttyUSB0
This will result in an audible acoustic chirp from the transducer.
Having verified that the modem is operating, the next step is to launch the missions using the
respective launch scripts. After about 20 seconds you should begin to hear audible acoustic sounds
and see successful acoustic transmissions on the pAcommsHandler GUI.
You can now use pMarineViewer to deploy the REMUS to do its mission — except in this case
the message will be sent acoustically.
5.4
REAL AUV shoreside acomms, with RECON
Having competed the experiment above, almost all the pieces are in place to do an actual experiment. The final tutorial uses the actual main computer – payload computer interface as well as
simulation software on board the main computer. This gives the mission exactly the same look and
feel as a real experiment.
First it is necessary to prepare the main vehicle computer by providing it with a basic backup
mission. The basic backup mission is located in FINISH THIS BIT AND PUT THE REMUS
MISSION FILE IN THE SVN. Load this mission onto the vehicle (though it may be the defualt
mission anyway).
The VIP interface will appear as illustrated in Figure 5. IMPORTANT: Before launching this
mission however, make sure to enable the simulation mode by clicking as indicated in Figure 5
In this case, instead of using the uMarineSim and pMarinePID processes to simulate and control
the low level control of the vehicle we will use the iRecon process to communicate with the main
vehicle computer and the main vehicle computer will then simulate navigation performance.
Once more, the mission is deployed and monitored using pMarineViewer.
5.5
Actual Operation
Having competed these tutorials, no changes need to be made when transitioning from REAL AUV
shoreside acomms, with RECON to in water operation. Except for real world issues (such as boats,
shallow water, errors in deploying beacons etc.), the mission should be completed in exactly the
same manner as for the last simulation.
15
Figure 5: Hydroid’s Vehicle Interface Program (VIP): The Simulation button is located in
the lower right.
5.6
REAL shoreside listen only
This mission configuration is setup to decode REMUS ranger and status messages at the shoreside.
It could be used to run a REMUS mission in which no acoustic communication takes place. It is
documented here for completeness and is not part of the tutorial.
16
References
[1] Michael R. Benjamin. MOOS-IvP Autonomy Tools Users Manual Release 4.2.1. Technical Report MITCSAIL-TR-201136, MIT Computer Science and Artificial Intelligence Lab, July 2011.
[2] Michael R. Benjamin, Henrik Schmidt, Paul M. Newman, and John J. Leonard. An Overview of MOOSIvP and a Users Guide to the IvP Helm - Release 4.2.1. Technical Report MIT-CSAIL-TR-2010-037,
MIT Computer Science and Artificial Intelligence Lab, August 2011.
17
Figure 6: Safely deploying the REMUS from the dock
Appendix - Information on MIT Platforms and Facilities
Notes for operating the REMUS 100 in the Charles River
When preparing software and testing drivers, it is sufficient to tie the AUV to the side of the dock
or to rest it on its stand. Deploying from the dock is the most straightforward manner. Make sure
to point the AUV away from the dock as it has no concept of where the dock or river wall are —
see Figure 6.
• The depth of the river in the vicinity of the sailing pavilion is about 4m. See Figure 7.
Minimum safe altitude for operation is about 2m. The rudder of the MIT sailing boats is
about 1m.
• Range of the Wireless router: about 100m. (Has not yet been used when amplified.)
• Acoustic Communication: The Charles is a difficult environment for acoustic comms - especially with reflections from the wall behind the pavilion. LBL ranges - via the Hydroid
Ranger
List of Equipment required for operations:
• Two acoustic transponders, positioned at opposite corners of the dock. Ideally at 2m depth.
Care should be taken to place them at the locations specified in the VIP mission. TODO:
buy GPS unit to do this.
• A deck box Micromodem with a sufficiently long transducer cable to reach from the sailing
school to the water. A 12V battery (A 24V supply might give better performance)
• Hydroid wireless router, base station charging unit and the Ranger device.
• A power strip and several network cables.
• MIT REMUS Ops toolkit. TODO: make toolkit ;)
Glossary
MOOS and MOOS-IvP:
18
Figure 7: Water depth near to river: INSERT PICTURE OF SURVEY OF RIVER DEPTH.
• Main vehicle computer - the manufacturer-supplied low-level vehicle controller. Also known
as the primary controller.
• Payload computer - the user-maintained high-level vehicle controller. Communicated with
the main vehicle computer: sending commands and receiving navigation information.
• MOOS Process - an executable which carries out a modular action e.g. a sensor driver, a high
level controller, a navigation engine. Communication between processes via the MOOSDB
and TCP protocol.
• IvP Behavior - software modules for the operation of discrete tasks eg holding position,
surveying, keeping depth, trailing. Evaluated and combined using the pHelmIvP MOOS
process.
Acoustic Communications:
• Goby-Acomms - a set of open source software libraries for acoustic communication
• pAcommsHandler - a MOOS process which uses the goby libraries.
• MAC - Medium Access Control - A set of procedures for ensuring collision-free communications on a shared channel such as the marine acoustic channel.
• CCL - Compact Control Language - A language for specifying the structure of binary data
transmitted using the MicroModem. Developed at WHOI, supplemented by Goby-Acomms
as DCCL.
• topside or shoreside - a generic name for the mission control laptop and its acoustic modem.
Hydroid and REMUS:
• REMUS 100 - the name and model of the AUV sold by Hydroid
• VIP - Vehicle Interface Program - Hydroid’s program for vehicle debugging, mission planning
and operation. As shown in Figure 5.
19
Figure 8: Hydroid’s Ranger Device.
• RECON - a UDP/TCP interface between the main vehicle computer and the payload at the
frequency of 10Hz or less. Messages are plain text strings of the following format:
#S, T 11 : 09 : 21.6, LAT 33N 14.9322, LON 117W 27.0600, D − 0.02...
The iRecon MOOS process implements this interface protocol.
• Ranger - device for vehicle ranging and status updates (Figure 8). When using MOOS and
Goby-acomms the device can only provide range measurements. Additionally, mission abort
is possible independent of the WHOI MicroModem and MOOS.
Post Mission Maintenance and Data Storage
Post mission logs can be removed from the AUV and the shoreside laptop and place at this location
on the AFS:
/afs/csail.mit.edu/group/marine/data/mit_remus_100
Additional information about sensors, components and manuals is located at
/afs/csail.mit.edu/group/marine/equipment/marine
The vehicle should be washed down after operations using a hose and a cloth for about 10–15
minutes. This is of particular importance when operating in salt-water so as to avoid corrosion.
20