<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
% Include common packages, environments, counters etc
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_lab_format}
\input{common_latex/common_latex_definitions}
%===================================================================
\setcounter{tocdepth}{2}
%===================================================================

\begin{document}
\wikidoc{file=Lab.ClassHazSearch}
\wikidoc{auth=mikerb@mit.edu}
\helplevelsubsec



%===================================================================
% Build the Cover Page in an environment style easy for wiki parsing
\begin{labcover}
\labtitle{Lab 10 - Autonomous Collaborative Search Part I}
\vspace{0.1in}
\labcourse{2.680 Unmanned Marine Vehicle Autonomy, Sensing and Communications}
\vspace{0.3in}
\labdate{Spring, 2018}
\vspace{0.1in}
\labpng{0.6}{figures/collab_search_box.png}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Henrik Schmidt, henrik@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\vspace{0.2in}
\labtoc{footnotesize}
\labtocdepth{2}
\end{labcover}

%====================================================================
% Add a blank page so first body page is on the right when doubleside
\blankpage
%====================================================================
\newpage \section{Overview and Objectives}

The focus of today's lab will be on autonomous collaborative
search. The goal will be to develop a two-vehicle mission
configuration where the two vehicles are working together to locate
and identify hazards in a given region. There will be constraints on
the vehicle speed, inter-vehicle comms range, and sensor
characteristics. The end-goal is to make the best educated report on
the location and type of located objects in the search field. The
performance score will be based on a reward/penalty system applied to
correct/incorrect elements of the final report.

\pskip

\noindent
In this lab, there are three MOOS apps that are new arrivals to our labs:

\begin{packed_itemize}[2]
\item \app{uFldHazardSensor} - A simulated side-scan sonar sensor.
\item \app{uFldHazardMetric} - An automatic scorer of hazard reports
  w.r.t. ground truth.
\item \app{uFldHazardMgr} - A straw-man vehicle application for managing
  hazard information and reports.
\end{packed_itemize}

\noindent
This complements a few other utilities in the uField Toolbox introduced in 
the previous 2-3 labs. You should have at least a basic understanding of what
each does.

\begin{packed_itemize}[2]
\item \app{uFldMessageHandler} - A MOOS handler for incoming message
  from other vehicles.
\item \app{uFldNodeComms} - A MOOS shoreside arbiter of inter-vehicle
  messages.
\item \app{uFldNodeBroker} - A vehicle-side broker for configuring
  shared information to the shoreside.
\item \app{uFldShoreBroker} - A shoreside broker for configuring
  shared information to the shoreside.
\end{packed_itemize}

\noindent
A summary of today's topics:

\begin{labinfo}
\begin{packed_itemize}[2]
\item Introduction to the Autonomous Collaborative Search challenge problem 
\item Obtain, understand and modify the baseline mission
\item Assignment: Add inter-vehicle messaging to share search reports
\item Assignment (optional): Add adaptive path planning 
\item Assignment (optional): Modify search and reporting using Classification results
\end{packed_itemize}
\end{labinfo}


The goal of the Collaborative Search lab is to begin exploring the
relationship between autonomy, sensing and communications - the
primary theme of the course.  In this lab, the issue of inter-vehicle
communications is introduced, with the sole limitation being a range
dependency (any two vehicles need be within $N$ meters to be able to
communicate). Other than a range dependency, for now our inter-vehicle
messaging is uninhibited. Later we will introduce restrictions on
message frequency and message bandwidth.

\pskip

In this lab, students are encouraged to work in pairs. Let us know if you
need help in finding a lab partner.

%========================================================================
\newpage
\section{Preliminaries}
\label{prelims}

%=======================================================================
\subsection*{Make Sure You Have the Latest Updates}

Always make sure you have the latest code:

\begin{consoleverb}
 $ cd moos-ivp
 $ svn update
\end{consoleverb}

\vspace{0.1in}
\noindent
And rebuild if necessary:

\begin{consoleverb}
 $ ./build-moos.sh
 $ ./build-ivp.sh
\end{consoleverb}

%=======================================================================
\subsection*{Make Sure Key Executables are Built and In Your Path}

This lab does assume that you have a working MOOS-IvP tree checked out
and installed on your computer. To verify this make sure that the
following executables are built and findable in your shell path:

\begin{consoleverb}
 $ which MOOSDB
 /Users/you/moos-ivp/bin/MOOSDB
 $ which pHelmIvP
 /Users/you/moos-ivp/bin/pHelmIvP
\end{consoleverb}

\noindent
If unsuccessful with the above, return to the steps in Lab 1:

\pskip
\noindent
\urlxx{http://oceanai.mit.edu/ivpman/labs/machine_setup}{Lab.MachineSetup}

%=======================================================================
\subsection*{Where to Build and Store Lab Missions}

As with previous labs, we will use your version of the \var{moos-ivp-extend} tree, 
which by now you should have re-named something like \var{moos-ivp-janedoe}, where
your email may be \var{janedoe@mit.edu}. In this tree, there is a missions folder:

\begin{consoleverb}
 $ cd moos-ivp-janedoe
 $ ls
 CMakeLists.txt  bin/            build.sh*       docs/           missions/       src/
 README          build/          data/           lib/            scripts/
\end{consoleverb}

\noindent
For each distinct assignment in this lab, there should be a
corresponding subdirectory in a \var{lab\_10} sub-directory of the
\var{missions} folder, typically with both a \var{.moos} and
\var{.bhv} configuration file. See Section \ref{sec_hand_in} for the 
full requested file structure.

%=======================================================================
\subsection*{Documentation Conventions}

To help distinguish between MOOS variables, MOOS configuration
parameters, and behavior configuration parameters, we will use the
following conventions:

\begin{packed_itemize}[3]
\item MOOS variables are rendered in \mvar{green}, such as
  \mvar{IVPHELM\_STATE}, as well as postings to the \app{MOOSDB}, such
  as \mvar{DEPLOY=true}.
\item MOOS configuration parameters are rendered in \pvar{blue}, such
  as \pvar{AppTick=10} and \pvar{verbose=true}.
\item Behavior  parameters are rendered in \bvar{brown},
  such as \bvar{priority=100} and \bvar{endflag=RETURN=true}.
\end{packed_itemize}


%==========================================================================
\subsection*{More MOOS / MOOS-IvP Resources}

\begin{itemize}

\item The slides from Monday's class: \newline 
  \urlx{http://oceanai.mit.edu/2.680/docs/2.680-09-collab_search.pdf}

\item The \app{uFldHazardSensor} documentation \newline
  \urlx{http://oceanai.mit.edu/ivpman/apps/uFldHazardSensor}

\item The \app{uFldHazardMetric} documentation \newline
  \urlx{http://oceanai.mit.edu/ivpman/apps/uFldHazardMetric}

\item The \app{uFldHazardMgr} documentation \newline
  \urlx{http://oceanai.mit.edu/ivpman/apps/uFldHazardMgr}

\end{itemize}



%=========================================================================
\newpage \section{Problem Description}
%=========================================================================

This section describes the problem parameters, mission constraints and 
format for a vehicle to generate a report at the end of a mission. The 
following five points are discussed:

\begin{packed_itemize}
\item A search region
\item An object lay-down
\item Metrics of success
\item Mission and vehicle constraints
\item Reporting criteria
\end{packed_itemize}

\noindent
Values for the first four components are discussed below, but may be
altered at competition time. The idea is to have a canonical problem
to focus on for development, which will be part of the competition,
and have a to-be-determined variation of the problem also part of the
competition. The latter will help judge how general the individual
submitted solution may be.

%========================================================================
\subsection{The Search Region}

The simulated hazard region will be within a polygon with the
following four vertices:

\begin{packed_itemize}
  \item (-150, -75)
  \item (-150, -400)
  \item (400, -400)
  \item (400, -75)
\end{packed_itemize}

\noindent
The initial search region is chosen to be rectilinear to simplify a
lawnmower pattern generation for a waypoint behavior. See the
documentation for this behavior.  A pattern may be given to the
behavior simply by specifying the characteristics of the lawnmower
pattern without having to explicitly determine all the points.

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.9\textwidth]{figures/search_region.png}
  \caption{The search region is given in the local coordinates of the
    MIT Sailing Pavilion on the Charles River. The local (0,0) position
    is on the dock where vehicles are launched and recovered.}
  \label{fig_search_region}
\end{figure}

\noindent
The search region may change slightly at the time of the competition.


%========================================================================
\subsection{The Object Laydown}

The object laydown is defined in a {\em hazard file}, not known to the
vehicle at run time. It contains a set of objects, some of which are
of type hazard and some of type benign. Identifying and correctly
determining the type of these objects is the goal of the mission. For simulation
testing and development purposes, a number of hazard files are provided
in the baseline mission. A simple example, used as the default in the
baseline mission, is shown in Figure \ref{fig_search_region}.

%------------------------------------------------------------------------
\subsubsection{Example File Format}

A hazard file is simply a text file, with line for each object. An
example is below. This is discussed in greater detail in the
\app{uFldHazardSensor} documentation.

\vspace{0.1in}
\begin{fileverb}
hazard = x=165,y=-91,label=32,type=hazard
hazard = x=21,y=-88,label=85,type=hazard
hazard = x=370,y=-219,label=23,type=hazard
hazard = x=-149,y=-318,label=92,type=hazard
o o o
hazard = x=189,y=-326,label=75,type=benign
hazard = x=52,y=-164,label=8,type=benign
hazard = x=174,y=-190,label=46,type=benign
hazard = x=357,y=-177,label=40,type=benign
hazard = x=211,y=-315,label=38,type=benign
\end{fileverb}

%------------------------------------------------------------------------
\subsubsection{Generating Hazard Files}

A hazard file may be generated with a provided command line tool, to
allow the user to perform more extensive tests of their choosing. The
\app{gen\_hazards} utility is distributed with the moos-ivp code, and
an example command line invocation is below. This tool is discussed in
greater detail in the \app{uFldHazardSensor} documentation.

\vspace{0.15in}
\begin{consoleverb}
$ gen_hazards --polygon=-150,-75:-150,-400:400,-400:400,-75 --objects=5,hazard --objects=8,benign
\end{consoleverb}

%=========================================================================
\subsection{Metrics of Success}

The scoring metrics are as follows:

\begin{packed_itemize}
\item 150: Penalty for missed hazard
\item 25: Penalty for false alarm
\item 300: Penalty for being late (later than 7200 seconds)
\item 0.25: Additionaly late penalty applied to each second of lateness.
\end{packed_itemize}

%=========================================================================
\subsection{Mission and Vehicle Constraints}

There are handful of mission and vehicle constraints enforced to keep
everyone on the same playing field.

%------------------------------------------------------------------------
\subsubsection{Time}

The maximum mission time is 7200 seconds, or 2.0 hours. This value was chosen,
in part, since most computers can support a MOOS time warp of 10-20x realtime
or much higher on newer systems. A time warp of 20 allows a full mission to 
be simulated in less than ten minutes. The mission time constraint has a
variable penalty associated with it:

\begin{packed_itemize}
\item 300: Penalty for being late (1 second later than 7200 seconds), and
\item 0.25: Additional late penalty applied to each second of lateness.
\end{packed_itemize}

%------------------------------------------------------------------------
\subsubsection{Top Speed}

Vehicles will be limited to a speed of 2.0 meters per second. There is
no penalty in terms of sensor performance or comms for moving {\em at}
the top speed. Vehicles moving over the top speed will essentially
automatically disable their own sensors until the speed is reduced.

%------------------------------------------------------------------------
\subsubsection{Limits on Inter-Vehicle Communication}

Communications between vehicles will limited in range, frequency and
bandwidth.  This will need to be accounted for both during the mission
for collaboration, and at the end of the mission for fusing the two
vehicles' belief states into a single hazardset report. The
restrictions will be

\begin{packed_itemize}
\item {\bf Range:} Communications limited to 100 meters
\item {\bf Frequency:} Communications will be limited to once per 60 seconds
\item {\bf Bandwidth:} Each message will be limited to 100 characters
\end{packed_itemize}

These configurations are enforced in the \app{uFldNodeComms}
configuration. This module is on the shoreside and will be configured
by the competition organizers, and is configured with these values in
the baseline mission. You will be running your own shoreside MOOS
community during development, but you should not change this
configuration in your \app{uFldNodeComms} configuration to ensure you
are developing in an environment similar to the competition. Remember
that a message that fails to be sent, due to one of the above
criteria, will not be queued for later re-sending. You should handle
the possibility that message may be dropped.

%------------------------------------------------------------------------
\subsubsection{Sensing During Turns}

The simulated sensor will be rendered off during turns of 1.5 degrees
per second.  This is discussed in greater detail in the
\app{uFldHazardSensor} documentation.

%------------------------------------------------------------------------
\subsubsection{Sensor Configuration Options and Configuration Frequency}

Vehicles will be allowed to set their sensor configuration once at the
outset. Attempts to switch configurations after the outset will simply
be ignored. You may, however, switch the the $P_D$ setting (and
corresponding $P_{FA}$ setting) as often as you like.

\pskip
\noindent
Your sensor configuration options will be:

\prevblue
\begin{verbatim}
  sensor_config = width=5, exp=8, class=0.88, max=1
  sensor_config = width=10, exp=6, class=0.70
  sensor_config = width=25, exp=4, class=0.63
  sensor_config = width=50, exp=2, class=0.55
\end{verbatim}
\postverb

\pskip
\noindent
See the documentation for \app{uFldHazardSensor} on what this entails
in terms of the ROC curve performance of the sensor, and how the
vehicle may request a particular configuration. The first sensor
setting, with \var{width=5} may be enabled for at most one vehicle.

%-------------------------------------------------------------------------
\subsection{Dynamic Changes to the Rules}

As mentioned at the outset, baseline values are provided for the initial 
development and first phase of the competition for the following parameters:

\begin{packed_itemize}
\item A search region
\item An object lay-down
\item Metrics of success
\item Mission and vehicle constraints
\end{packed_itemize}

\noindent
Part of the competition will test exactly on the given baseline
parameters. Part of the competition will test on parameters only known
at competition time. How will those parameters be made available? They
will be set on the shoreside in the \app{uFldHazardMetric} application
and posted to the shoreside MOOSDB and shared out to the vehicles.

\prevgreen
\begin{verbatim}
UHZ_MISSION_PARAMS = "penalty_missed_hazard=150,penalty_false_alarm=25,max_time=600,
                      penalty_max_time_over=300,penalty_max_time_rate=0.5,
                      search_region=pts={-150,-75:-150,-400:400,-400:400,-75}"
\end{verbatim}
\postverb

\noindent
If you run the baseline mission and scope the MOOSDB on one of the
vehicles, you will notice that a publication similar to the above has
been made, originating in the shoreside in the \app{uFldHazardMetric}
application. For example, after launching the baseline mission, in a 
separate terminal window you should see something like:

\vspace{0.15in}
\begin{consoleverb}
 $ cd moos-ivp/ivp/missions/m10_jake
 $ uXMS targ_betty.moos UHZ_MISSION_PARAMS
 Mission File was provided: targ_betty.moos
 uXMS_630 thread spawned
 starting uXMS_630 thread
 ----------------------------------------------------
 |       This is an Asynchronous MOOS Client        |
 |       c. P. Newman U. Oxford 2001-2012           |
 ----------------------------------------------------
 
 o o o 
 
 ===================================================================
 uXMS_630 betty                                               0/0(1)
 ===================================================================
 VarName             (S)ource          (T)  (C)ommunity  VarValue (SCOPING:EVENTS)
 ------------------  ----------------  ---  ----------  -------------------------
 UHZ_MISSION_PARAMS  uFldHaz..dMetric       shoreside   "penalty_missed_hazard=150,
 penalty_false_alarm=25,max_time=600,penalty_max_time_over=300,penalty_max_time_rate=0.5,
 search_region=pts={-150,-75:-150,-400:400,-400:400,-75}"
\end{consoleverb}
\vspace{0.1in}

\noindent
Presently, in the baseline mission, this information is not being handled by 
either vehicle. If the mission were to change, the vehicle would not adjust. 
But this is why it is a baseline mission; it's not complete and is meant to 
be a competition starting point.

{\em In this competition, the only parameters that will change are the
  penalty values, and the threat lay-down, and perhaps the search area
  and communications constraints. The top vehicle speed and sensor
  properties will not be changed. You can assume the values used in
  the baseline mission.}


%==========================================================================
\newpage \input{./chap_xmiss_jake}

%=======================================================================
\section{Assignments}
%=======================================================================

%=======================================================================
\subsection{Assignment 1 (self check off) - Obtain and Run the Baseline Mission}


Our first step is to get and run the baseline mission we will be starting from
in this lab. Get a copy and put it in your new \var{lab\_10} folder.

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp/ivp/missions-2680
 $ cp -rp lab_10_jake_kasper_baseline moos-ivp-janedoe/missions/lab_10/jake_kasper_baseline
\end{consoleverb}
\vspace{0.1in}

\noindent
This mission is configured for two vehicles, \var{jake} and
\var{kasper}, each doing a simple lawnmower search with the ability to
return and station-keep at any time. It is described fully in Section
\ref{sec_xmiss_jake}. It should be launchable with

\vspace{0.1in}
\begin{consoleverb}
 $ cd jake_kasper_baseline
 $ ./launch.sh 15
\end{consoleverb}
\vspace{0.1in}

\noindent
It is our starting point for this lab, and should look something like
the video posted at:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figures/ufhz_jake_basic.png}
  \caption{{\bf The Jake Kasper Baseline mission}: Two vehicles are on
    independent lawn-mower shaped search patterns, each with a chosen
    swath width.  Each vehicle will generate a hazardset report upon
    completion of their initial search. This is a straw-man solution
    to the hazard-search problem.  Several changes or additions need
    to be made to improve the performance, but this mission
    constitutes a syntactically valid hazard-search mission.}
  \label{fig_jake_basic}
  \urlvideo{https://vimeo.com/88824022}{0:32}
\end{figure}
\vspace{0.1in}

Any time after the vehicle has been deployed, the user may request the
generation of a hazardset report. The \var{REQ\_REPORT} button sends a
\mvar{HAZARDSET\_REQUEST} message to the vehicles, each running
\app{uFldHazardMgr}. Repeated requests result in updated reports. The 
overall score of the reports tends higher as the mission progresses and 
more hazards are detected.

%=======================================================================
\subsection{Assignment 2 (self check off) - Understand the Baseline and Key Modules}

Take some time to understand the components of the baseline mission.
Read through the description of the baseline mission in Section
\ref{sec_xmiss_jake}. Read the description of the key apps in this
lab, \app{uFldHazardSensor}, \app{uFldHazardMetric}, and
\app{uFldHazardMgr}. Another suggestion is to run the baseline mission
and confirm some of the postings by looking at the alog files from the
vehicles and on the shoreside. Use \app{aloggrep} to confirm
things. You want to be familiar with this tool later on for your own
debugging.

%=======================================================================
\subsection{Assignment 3 (self check off) - Make your own uFldHazardMgr}

The baseline mission has a straw-man implementation of \app{uFldHazardMgr} which 
will run on your vehicles. You will need to improve this with your own version. 
To get your own version:

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-janedoe/src
 $ cp -rp /Users/you/moos-ivp/ivp/src/uFldHazardMgr  ./uFldHazardMgrX
\end{consoleverb}
\vspace{0.1in}

\noindent
After you have made a copy of \app{uFldHazardMgr} named
\app{uFldHazardMgrX}, add \app{uFldHazardMgrX} to your
\var{moos-ivp-janedoe/src/CMakeLists.txt} file and re-build our
code. Finally, replace the references to \app{uFldHazardManager} in
your copy of the baseline mission, with refeferences to your app
instead.  These references are at least in the
\app{meta\_vehicle.moos} file and \app{plug\_uFldHazardMgr.moos}
files. (Don't forget to put \app{uFldHazardMgrX} under your version
control, e.g., svn or git.)

%=======================================================================
\subsection{Assignment 4 (check off) - Merge Vehicle Reports}

As mentioned in the description of the baseline mission (Phase 3:
Reporting Results), each vehicle is simply surveying half the search
area, and posting its own \mvar{HAZARDSET\_REPORT}. This results in
two reports received by \app{uFldHazardMetric} on the shoreside. Both
reports are destined to be poor, since they will have missed
detections from the area being searched by the other vehicle.

\pskip

Your objective in this assignment is to merge vehicle reports. The two 
vehicles should communicate their search results to each other to create
a full report of the search area. 

\pskip
\noindent
Things to consider:

\begin{packed_itemize} 
\item Your vehicles will need to talk to each other using the
  \mvar{NODE\_MESSAGE} scheme from Lab 09. The baseline mission
  already has \app{uFldNodeComms} and \app{uFldMessageHandler} in
  place. Confirm that you can send messages, and then focus on how to
  share reports.

\item You may want to make these changes in your \app{uFldHazardMgrX}
 application from Assignment 3.
  
\item Your vehicles will need to be close enough to send messages. How will 
  you accomplish this?
\end{packed_itemize} 

\pskip
\noindent
Things you don't need to consider (for now):

\begin{packed_itemize} 
\item You can still use the simple heuristic that every detection is reported
  as a hazard. The aim here is merging reports.

\item You don't have to worry about submitting multiple reports. So for now
  both vehicles can simply submit the combined report. Later on, you may want
  it to come from just one vehicle.
\end{packed_itemize} 

%=======================================================================
\subsection{Assignment 5 (self check off, optional) - Begin to Path Plan}

Presently the vehicle paths are simple lawn-mower patterns configured
in the vehicle behavior file. You are encouraged to creat a
\app{pHazardPath} MOOS app to run on both vehicles. This module should
be where path planning is done. At the very least it should have
configuration parameters that set the operation area. Eventually it
should read the \mvar{UHZ\_MISSION\_PARAMS} variable produced on the
shoreside which contains the operation area information. It is in this
app also that you may implement something more complicated than
lawn-mower pattern, such as a tour of hazard objects that need further
sensor feedback before generating a report. This issue is optional in
this lab, but will be key in the next lab on this problem, so it's a
worthy area to get started on.

%=======================================================================
\subsection{Assignment 6 (self check off, optional) - Begin to Use the Classify Report}

In the baseline mission, classify reports are not used. They are key
to achieving high certainty in final reports. See if you can utilize
this capability in your \app{uFldHazardMgrX} application to generate
better reports. This issue is optional in this lab, but will be key in
the next lab on this problem, so it's a worthy area to get started on.



%=======================================================================
\section{Instructions for Handing In Assignments}
%=======================================================================

%=======================================================================
\subsection{Requested File Structure}
\label{sec_hand_in}

Here is the requested file structure:

\vspace{0.1in}
\begin{consoleverb}
  moos-ivp-janedoe/
    missions/
      lab_10/
        jake_kasper_baseline/       // Assignment 1 - self checkoff
        jake_kasper                 // Your own sandbox
    src/
      uFldHazardMgrX/               // Your version of the hazard manager
      pHazardPath/                  // Your implementation of path planning
\end{consoleverb}
\vspace{0.1in}


%------------------------------------------------------------------
\subsection{Due Date}

This lab should be completed prior to the next lab (Tuesday April 4th,
2017). The beginning of the next lab may be used to check off
outstanding components.


\appendix
\newpage \input{appendix_hazard_files}
%\newpage \input{appendix_hazard_resemble}
\newpage \input{appendix_gen_hazards}
\newpage \input{appendix_hazard_rendering}
\newpage \input{appendix_hazard_serialize}

\end{document}



</pre></body></html>