2.S998 | Spring 2012 | Graduate

Marine Autonomy, Sensing and Communications

Labs

NOTE: The homework assignments for this class require access to the following online development tools and environments that may not be freely available to OCW users. The assignments are included here as examples of the work MIT students were expected to complete.

LAB # LAB TOPICS LAB NOTES SUPPORTING MATERIAL
1 Getting Started w/ Lab Machines None None
2 Marine Robotics Software 1 Introduction to C++ (PDF) None
3 Marine Robotics Software 2 Introduction to MOOS (PDF) Lab 3 updates
4 MOOS Middleware Introduction to MOOS Programming (PDF) Lab 4 updates
5 MOOS Application Writing Ocean Acoustic Environment (PDF) Lab 5 updates
6 Intro to Helm Autonomy Intro to Helm Autonomy (PDF)

Lab 6 updates

Lab 6 video clips:

-Modified alpha mission 1

-Modified alpha mission 2

-Bravo mission 1

-Bravo mission 2

-Bravo UUV mission 1

-Bravo UUV mission 2

7 Sim Multi-vehicle Ops Pt1 Simulation of Multi-Vehicle Operations (PDF)

Lab 7 updates

Lab 7 video clips:

-Times double loiter

-Timed double traverse 1

-Timed double traverse 2

8 Sim Multi-vehicle Ops Pt2 Multi-Machine Simulation of Multi-Vehicle Operations (PDF)

Lab 8 video clips:

-Timed double traverse with replanning

9–11 Autonomous Collab Search 1–3 Autonomous Collaborative Search (PDF)

Lab 9 updates

Lab 9 video clips:

-Vehicle loitering mission

12–13 Goby Acomms Software 1–2 Acoustic Communications and Networking (PDF) Lab 12 updates
14–17 Collab Search II / Pavilion Autonomous Collaborative Search Part 2 (PDF)

Lab 15 updates

18–21 Autonomous Front Detection Autonomous Front Detection (PDF - 1.6MB) None
22–26 Charles River Lab In-Water Autonomous Front Estimation (PDF - 1.6MB) None
  • If you’re using a Mac (OS X Lion), you’ll need to install the PL2303 driver as explained on this blog post.

  • Use “sudo bash” or “sudo tcsh” to get a root shell before following their instructions. This will allow you to use the USB-serial dongles we’ll use to connect to the modem hardware today and thursday.

Setting Behavior Priority Weight

A step is missing in the BHV_SimpleWaypoint behavior that you were asked to use as a template.

The very last line of the onRunState() function in the SimpleWaypoint behavior returns the newly built IvP function:

return(ipf);

Prior to returning the IvP function you also need to apply the behavior weight as follows:

if(ipf)     ipf->setPWT(m_priority_wt);

You can regard this as boilerplate, but here’s a couple notes in case you’re curious:

  1. the check “if(ipf)” is done in case the IvP function returned by the ZAIC tool returned null. If it were null, the second line would result in a crash.

  2. the priority weight (m_priority_wt) is a member variable of the IvPBehavior superclass and is set automatically in the IvPBehavior::setParam() function handling parameters from your .bhv file.

  3. the reason why the user applies the priority weight explicitly rather than being handled automatically, is that the behavior author may not want to just use the priority weight from the config file, but may want to instead use this as a guide in its own priority weight policy. For example the collision avoidance behavior will set its own weight between zero and m_priority_wt depending on the proximity to the contact.

One last point: to get your ZigLeg behavior to exert its influence over the vehicle trajectory, remember that it’s running alongside the waypoint behavior. You will need to give your ZigLeg bahavior a priority weight higher than the waypoint behavior (set in the .bhv file).

Fix the uMS Build

Getting uMS and FLTK to build

uMS is part of the MOOS software tree. There have been some problems in getting this to compile with the .build-moos.sh script.

Mac and Linux users both should do an “svn update” in the moos-ivp tree.

  • On Mac OS X, building uMS in the MOOS tree will require installing the FLTK package (sudo port install fltk-dev).

    It will also require augmenting your path:

bash users (add this to your .bashrc file): PATH=$PATH:~/moos-ivp/MOOS/MOOSBin/uMS.app/Contents/MacOS tcsh users: (add this to your .cshrc file) set path = ( $path ~/moos-ivp/MOOS/MOOSBin/uMS.app/Contents/MacOS )
  • In Linux:

    sudo apt-get install libfltk1.1-dev

    remove moos-ivp/MOOS/cmake_modules/FindFLTK.cmake

    (or svn update - the above file has been removed from the tree).

This page describes the use of a few methods written in C++ for parsing strings. They are defined in lib_mbutils/MBUtils.h. You can either link to this library or go to the library and copy the code snippets into your own program.

The three functions defined on this page are (from MBUtils.h):

vector<string> parseString(string, char); string         biteString(string&, char); string         stripBlankEnds(string);

Block color coding on this page:

source code snippet output

Common lines

Each of the code snippets below also have the following four lines at the top.

#include "MBUtils.h" #include <string> #include <iostream> using namespace std;

Parsing a comma-separated list

#include <vector>  string str = "apples,pears,bananas"; cout << "Initial string is: " << str << endl;  vectors<string> svector = parseString(str, ','); unsigned int i, vsize = svector.size(); for(i=0; i<vsize; i++) {    cout << "Entry[" << i << "]: " svector[i] << endl;  }
Initial string is: apples,pears,bananas Entry[0]: apples Entry[1]: pears Entry[2]: bananas

Parsing a parameter=value pair

string str = "temperature=98.6"; cout << "Initial string is: " << str << endl;  string param = biteString(str, '='); cout << "Param: " << param << endl; cout << "Value: " << str   << endl;
Param: temperature Value: 98.6

Stripping blank ends from a string

string str = "   Hello World!  "; cout << "Initial string is: [" << str << "]" << endl;  string new_str = stripBlankEnds(str); cout << "New string is: [" << new_str << "]" << endl;
Initial string is: [   Hello World!  ] New string is: [Hello World!]

Random Number Script

Below is a uTimerScript script for generating a random 15 digit number every quarter second, followed a random 9,7 and 5-digit number, and posted to the MOOSDB by the variable name RAND_NUMBER.

// Note: 2**48 = 281,474,976,710,656  ProcessConfig = uTimerScript {   AppTick   = 4   CommsTick = 4    paused     = false   event      = var=RAND_NUMBER, val=$(15), time=0.25   event      = var=RAND_NUMBER, val=$(9), time=0.50   event      = var=RAND_NUMBER, val=$(7), time=0.75   event      = var=RAND_NUMBER, val=$(5), time=1.00   reset_max  = nolimit   reset_time = all-posted }

Converting long strings to numbers:

#include <cstdlib> unsigned long int val = strtoul(str.c_str(),NULL,0);

Since 2**64 is 18,446,744,073,709,551,616, the above should work on all strings up to 19 digits.

Note: The use of $(15) in the uTimerScript event represents a new feature of uTimerScript. You will need to do an svn update in the moos-ivp tree and recompile. The forms $(1) through $(20) are supported.

$ cd moos-ivp $ svn update       // You should be at revision 4182 or higher $ ./build-ivp.sh

MOOS App Output Format

Regarding the output strings from your two MOOS apps in lab 4: the specs left some room for design in the output format, leaving it up to you to handle whatever format you chose in your first app in your tester app. The TAs would like to write a tester MOOS app suitable for testing the output for all student apps. Therefore we need to be a bit more specific:

For the pSequence app, the following format should be used:

SEQUENCE_RESULT = "values=3:63:5:21:119,output=odd"

For the pPrimeFactor app, the following format should be used:

PRIME_RESULT = "orig=30030,received=34,calculated=33,solve_time=2.03,                   primes=2:3:5:7:11:13,username=jane"

Submit Format

Lab 04 assignments should be uploaded to the course site. You should upload ONE file, using either tar, zip or equivalent. Assuming you started with a moos-ivp-extend folder, rename your folder to moos-ivp-xyz, where xyz is your mit mail prefix.

The folder format should have the naming and file organization as indicated below:

moos-ivp-yourname/    src/pPrimeFactor       /pPrimeFactorTester       /pSequence       /pSequenceTester     missions/sequence/sequence.moos            /primes/primes.moos

MOOS App Launch Alias

In order for your MOOS app to be able to connect to the MOOSDB under an alias name (using the pAntler ~ syntax), your app must handle argv[2] as an alias specification. The two lines below were omitted from the main.cpp file in the GenMOOSApp script. Make sure you have them implemented in your program.

int main(int argc, char *argv[]) {   string mission_file = "";   string run_command  = argv[0];   bool   help_requested = false;   bool   vers_requested = false;   bool   exam_requested = false;    int    i;   for(i=1; i<argc; i++) {     string argi = argv[i];     if((argi=="−v") || (argi=="−−version") || (argi=="−version"))       vers_requested = true;     else if((argi=="−e") || (argi=="−−example") || (argi=="−example"))       exam_requested = true;     else if((argi == "−−help")||(argi=="−h"))       help_requested = true;     else if(strEnds(argi, ".moos") || strEnds(argi, ".moos++"))       mission_file = argv[i];     else if(strBegins(argi, "−−alias="))       run_command = argi.substr(8);     else if(i==2)                                      // Add these      run_command = argi;                               // two lines!  }    if(vers_requested) {     cout << "${2}${1} Version 0.1" << endl;     return(0);   }    if(exam_requested) {     showExampleConfig();     return(0);   }    ${1} ${1};   ${1}.Run(run_command.c_str(), mission_file.c_str());    return(0); } 

Depth Configurations

In the Alpha example, the moos-ivp version of a Hello World program, the vehicle is a simulated surface craft. To simulated a UUV, a few modifications are required of three MOOS applications, including the helm. Once this is done, behaviors reasoning about depth may be used in the helm.

Modifications to the uSimMarine MOOS module:

More information on the uSimMarine simulator and configuration options can be found in the moos-ivp autonomy utilities documentation (PDF - 29.2MB).

     BUOYANCY_RATE        = 0.025     MAX_DEPTH_RATE       = 5     MAX_DEPTH_RATE_SPEED = 2.0     DEFAULT_WATER_DEPTH  = 400 

Modifications to the pMarinePID MOOS module:

More information on the uSimMarine simulator and configuration options can be found in the utilities moos-ivp autonomy documentation (PDF - 29.2MB).

     DEPTH_CONTROL = true        //Pitch PID controller     PITCH_PID_KP                   = 1.5     PITCH_PID_KD                   = 1.0     PITCH_PID_KI                   = 0     PITCH_PID_INTEGRAL_LIMIT       = 0        //ZPID controller     Z_TO_PITCH_PID_KP              = 0.12     Z_TO_PITCH_PID_KD              = 0     Z_TO_PITCH_PID_KI              = 0.004     Z_TO_PITCH_PID_INTEGRAL_LIMIT  = 0.05     MAXPITCH     = 15     MAXELEVATOR  = 13 

Modifications to the pHelmIvP MOOS module:

More information on configuring the IvPHelm decision domain may be found on p. 47 in the helm documentation (PDF - 29.2MB).

Domain     = depth:0:100:101

Modifications to the pNodeReporter MOOS module:

The modification below to pNodeReporter is mostly cosmetic. It changes the vehicle type to “UUV” so you see a UUV icon in your simulator diving, rather than a kayak. More information on pNodeReporter and configuration options can be found in the moos-ivp autonomy utilities documentation (PDF - 29.2MB).

VESSEL_TYPE   = UUV

In launching more than one vehicle in simulation, it starts to become more convenient to use a shell script to launch things. Here’s a very simple script, followed by a more fancy one for launching a mission consisting of a shoreside community (shoreside.moos) and a single vehicle (alpha.moos).

A Simple Launch Script

The script:

The script first checks for a numerical value in the command line arguments. If it finds one, it interprets this a request for a time warp. Then it does nothing more than launch pAntler for the two vehicles, and send a bit of output to the screen. The first line in the script is standard for shell scripts and indicates which shell is to be used for executing the script. To run the script, just type ./launch.sh 12 on the command line, to launch things with a time warp of 12.

  #!/bin/bash     WARP=1   #-------------------------------------------------------   #  Part 1: handle command-line args   #-------------------------------------------------------   for ARGI; do       if [ "${ARGI//[^0-9]/}" = "$ARGI" ]; then            WARP=$ARGI       fi   done    #-------------------------------------------------------   #  Part 2: Launch the processes   #-------------------------------------------------------    printf   "Launching ... (WARP=%s) \n" $WARP   pAntler alpha.moos --MOOSTimeWarp=$WARP >& /dev/null &   sleep 1   pAntler shoreside.moos --MOOSTimeWarp=$WARP >& /dev/null &   printf "Done Launching... \n" 

Misc. Other Updates

  • Geometry library linking: If you choose to use any of the objects in the lib_geometry library from the moos-ivp tree, e.g., the XYSegList class for waypoints, you will need to add the geometry and mbutil libraries to the list of libraries linked in your CMakeLists.txt file.

  • Launch script bug: Around line 92 of the launch.sh launch script in the baseline mission, the gilda.bhv file is mistakenly configured with START_POS=$START_POS1, and this should be START_POS2 instead.

  • Path planning start: The pGenPath MOOS module accepts a sequence of VISIT_POINT postings. There is the question of when the app should stop waiting for more postings and just begin its path calculation. Implement your app such that it interprets VISIT_POINT=“last”, as its cue to disregard future incoming mail and begin its calculation of shortest path.

Partial Solutions

Example solutions to lab exercises (TGZ) (the ones given as precursors to the hand-in assignments).

To untar:

tar xvfz filename.tgz

Example solutions to exercise in Section 3.1 in Lab 07 (TGZ).

To untar:

tar xvfz filename.tgz

Producing a Hazard Report

There is a change in the requested format of the reporting information to be produced by the vehicle. Rather than a sequence of reports such as described in the original lab:

HAZARD_REPORT = x=45,y=88,hazard=true,label=04 HAZARD_REPORT = x=15,y=18,hazard=false,label=16

You should instead produce a single report. There is a class called XYHazardSet that may be used as follows for easily constructing this report:

#include "XYHazardSet.h"   XYHazardSet my_hazard_set;   my_hazard_set.setSource("archie");  my_hazard_set.addHazard(45,88,"hazard","04");  my_hazard_set.addHazard(15,18,"benign","16");   string my_report = my_hazard_set.getSpec();   m_Comms.Notify("HAZARD_REPORT", my_report);

This will result in the post:

HAZARD_REPORT = "source=archie # x=45,y=88,type=hazard,label=04 #                  x=15,y=18,type=benign,label=16"

Note that you must include the geometry library in your build. Just add geometry to your list of link libraries in your CMakeLists.txt file, presumably in pHandleSensorData.

Knowing the Field Position of Other Vehicles

If you’d like one vehicle to know the position of another vehicle, you may want to consider using the NODE_REPORT information sent between vehicles. The NODE_REPORT is typically sent from all vehicles to the shoreside. This is what allows the pMarineViewer app to know and render the vehicle information. The node reports are also used by uFldNodeComms to know the vehicle locations to reason about what messages are allowed to be sent between vehicles. uFldNodeComms also bridges NODE_REPORT information back out to the vehicles to that vehicles may know each other’s position. The NODE_REPORT sharing is only done when “in range” of the other vehicle. The range is defined by the same ranged used for messaging. You can parse this string yourself, or use the NodeRecordUtils.h utilities found in the lib_contacts library in the moos-ivp tree. A typical node report looks like:

NODE_REPORT = NAME=alpha,TYPE=UUV,TIME=1252348077.59,X=51.71,Y=-35.50,               LAT=43.824981,LON=-70.329755,SPD=2.0,HDG=118.8,                        YAW=118.8,DEPTH=4.6,LENGTH=3.8,MODE=MODE@ACTIVE:LOITERING

Receiving uFldHazardSensor Information on the Vehicle

The uFldHazardSensor produces a sensor report, for a vehicle JAKE, in the form of UHZ_HAZARD_REPORT_JAKE, posted to the local shoreside MOOSDB. This report is bridged out to the vehicle JAKE as the variable UHZ_HAZARD_REPORT. To enable this bridging, the uFldShoreBroker needs the following configuration line (omitted from the la09two_baseline mission):

BRIDGE = src=UHZ_HAZARD_REPORT_$V, alias=UHZ_HAZARD_REPORT BRIDGE = src=UHZ_CONFIG_ACK_$V,    alias=UHZ_CONFIG_ACK

To send a NODE_MESSAGE with a string value containing a comma, surround the string value with double-quotes. This reflects a fix in the moos-ivp tree, so please do an svn update and recompile on the tree before using this fix. For example:

NODE_MESSAGE_LOCAL=src_node=alpha,dest_node=bravo,var_name=MSG, \                    string_val="foo,bar"