<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.ClassDistTSP}
\wikidoc{auth=mikerb@mit.edu}
\helplevelsubsec

%===================================================================
% Build the Cover Page in an environment style easy for wiki parsing
\begin{labcover}
\labtitle{Lab 7 - Distributed Traveling Salesman}
\vspace{0.1in}
\labcourse{2.680 Unmanned Marine Vehicle Autonomy, Sensing and Communications}
\vspace{0.15in}
\labpng{0.55}{figures/tsp_cover.png}
\vspace{0.15in}
\labdate{March 6th, 2025}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labsrc{project-pavlab/labdocs/lab\_class\_07\_distributed\_tsp}
\labtoc{small}
\end{labcover}

%===================================================================
% Add a blank page so first body page is on the right when doubleside
\blankpage

%===================================================================
% Begin the body of the text
%===================================================================
\newpage 
\section{Overview and Objectives}
%===================================================================

In today's lab we will continue our shift in focus to autonomy
configurations involving multiple vehicles. Our lab exercise will
involve a version of the Traveling Salesman Problem (TSP), in this
case distributed over multiple vehicles. TSP is the problem of
finding a path to visit a set of cities, with known distances between
any two cities, in such a way as to visit every city at least once and
to minimize the total distance traveled. We use the TSP problem to
exercise our new skills in deploying multiple vehicles to handle a
version of the TSP problem - the Distributed TSP problem. Given a set
of points to visit, assign the points to a set of vehicles to visit
those points. Since optimal TSP algorithms can be quite involved, we
simplify things a bit and allow for non-optimal shortest tour
distances while focusing on the mechanics of getting multiple
cooperating vehicles running.

\vspace{0.1in}
\noindent
Gaining familiarity with this mode of operation will be essential for later
labs and operation of vehicles on the water. In this lab: 

\begin{labinfo}
%\labinfoheader{Topics:}
\begin{packed_itemize}[2]
\item The \app{uTimerScript} utility will generate random sets of tour
  points on the Shoreside.
\item A new MOOS app, \app{pPointAssign}, will be written by you and
  run on the Shoreside to distribute points to vehicles.
\item Vehicles will be configured to receive visit point assignments from
  the Shoreside.
\item A new MOOS app, \app{pGenPath}, will be written by you and run
  on the simulated robot to generate a tour of waypoints.
\item Autonomy missions will be constructed to tour the points and return
  periodically for refueling.
\item Resumed missions will finish any incomplete tour portion until the
  total tour is done.
\end{packed_itemize}
\end{labinfo}



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

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

It is possible we will be making changes to the MOOS-IvP tree during
the semester.  Always make sure you have the latest code:

\begin{consoleverb}
 $ cd moos-ivp
 $ git pull
 Already up to date.
\end{consoleverb}

\vspace{0.1in}
\noindent
If you see see a response similar to the one above, indicating that no
changes were pulled in from the GitHub server, then you shouldn't need
to re-build the software.

\vspace{0.1in}
\noindent
Otherwise you will need to rebuild:

\begin{consoleverb}
 $ ./build.sh
\end{consoleverb}

\vspace{0.1in}
\noindent
Do the same for the \var{moos-ivp-2680} tree.

%=======================================================================
\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}

\vspace{0.1in}
\noindent
If unsuccessful with the above, return to the steps in Lab 1:

\urlxx{http://oceanai.mit.edu/ivpman/labs/machine_setup}{Lab.ClassSetup}

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

As with previous labs, we will use your version of the \var{moos-ivp-extend} tree.
In this tree, there is a missions folder:

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

\noindent
You will create a \var{lab\_07} folder/directory in 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}.
\item MOOS-IvP applications are rendered in \app{magenta}, such as
  \app{pShare}, or \app{pHelmIvP}.
\item General GNU/Linux commands are represented in \cmd{dark purple},
  such as \cmd{wget}, \cmd{mkdir}, or \cmd{cd}.
\end{packed_itemize}

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

A few further resources are worth mentioning for following up this lab
with your own exploration.

\begin{packed_itemize}[2]
\item The IvP Helm and Utilities documentation:
  \urlx{http://oceanai.mit.edu/ivpman}
\item The moos-ivp.org website:
  \urlx{http://www.moos-ivp.org}
\end{packed_itemize}

%==========================================================================
\subsection*{The Shoreside (Topside) / Vehicle Topology}
%==========================================================================

The layout of interconnected MOOS communities used in this lab is 
depicted in the figure below. This layout will be used 
for the remainder of the course, including during operations on the
river.

\vspace{0.15in}

\begin{figure}[H]
  \centering
  \includegraphics[width=0.75\textwidth]{figures/ufield_overview_v2.png}
  \caption{{\bf Shoreside to Multi-Vehicle Topology:} A number of
    vehicles are deployed with each vehicle maintaining some level of
    connectivity to a shoreside command and control computer. Each
    node (vehicles and the shoreside) are comprised of a dedicated
    MOOS community. Modes and limits of communication may vary.}
\label{ufld_overview}
\end{figure}

%=======================================================================
\section{Distributed Traveling Salesman - Preparing the Shoreside}
%=======================================================================

The Traveling Salesman Problem (TSP) is the problem of finding a path to visit
a set of cities, with known distances between any two cities, in such a way as to
visit every city at least once and to minimize the total distance traveled.

\vspace{0.1in}
\noindent
\urlx{https://en.wikipedia.org/wiki/Travelling_salesman_problem}

\vspace{0.1in}
\noindent
In this section we use the TSP problem to exercise our new skills in
deploying multiple vehicles to handle a version of the TSP problem -
the Distributed TSP problem. Given a set of points to visit, assign
the points to a set of vehicles to visit those points. Since optimal
TSP algorithms can be quite involved, we simplify things a bit and
allow for non-optimal shortest tour distances while focusing on the
mechanics of getting multiple cooperating vehicles running.

\vspace{0.1in}
\noindent
In this part we will:
\begin{packed_itemize}
  \item Create a \app{uTimerScript} script to generate 100 random points in
    a specified region.
  \item Create a \app{pPointAssign} MOOS App on the shoreside to
    send half the points to one vehicle and half to the other.
  \item Ensure our \app{pShare} communications is configured to share points
    out to the vehicles.
  \item Confirm it works by verifying that visit points are received on
    a pair of vehicles.
\end{packed_itemize}

\vspace{0.1in}
\noindent
To create new apps, use the \cmd{GenMOOSApp\_AppCasting} utility. For example:

\vspace{0.1in}
\begin{consoleverb}
  $ cd moos-ivp-extend/src
  $ GenMOOSApp_AppCasting PointAssign p "Chris Jones"
  pPointAssign generated
\end{consoleverb}

\vspace{0.1in}
\noindent
Recall that the \cmd{GenMOOSApp\_AppCasting} script is in the
\var{moos-ivp/scripts/} folder, and this needs to be in your shell
path if it isn't already.  Also don't forget that you'll need to add
the new app to the \var{CMakeLists.txt} file in the
\var{moos-ivp-extend/src} folder.


%=======================================================================
\subsection{Creating a Baseline Mission}
\label{sec_baseline}

We will call the TSP mission \var{distributed\_tsp}. A good place to
start as a template is the last mission from the previous lab. If your
file structure from Lab 6 followed the lab guidance, this should be
\var{henry\_gilda\_auto\_refuel}. We'll make a copy of that in our
newly created \var{lab\_07} folder.

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-extend/missions
 $ mkdir lab_07
 $ cd lab_07
 $ cp -rp ~/moos-ivp-extend/missions/lab_06/henry_gilda_auto_refuel  distributed_tsp
\end{consoleverb}
\vspace{0.1in}

\noindent
The file structure for this lab is shown in Section \ref{sec_hand_in}.

%=======================================================================
\subsection{Create a Script for Generating Visit Points}
\label{sec_visit_script}

Configure a \app{uTimerScript} script running on the shoreside
community, to generate a random sequence of points within a region of
the operation area. The four corners of this region should be:

\vspace{0.03in}
\footnotesize
\begin{verbatim}
  -25,-25
  -25,-175
  200,-25
  200,-175
\end{verbatim}
\normalsize
\vspace{0.03in}

\noindent
The script should generate 100 postings to the \app{MOOSDB} of the form:

\prevgreen
\begin{verbatim}
  VISIT_POINT = "firstpoint"
  VISIT_POINT = "x=8, y=9, id=1"
  ...
  VISIT_POINT = "x=-11, y=-9, id=100"
  VISIT_POINT = "lastpoint"
\end{verbatim}
\postverb

\noindent
The first posting in the script should be
\msvar{VISIT\_POINT="firstpoint"}.  The last posting in the script
should be \msvar{VISIT\_POINT="lastpoint"}.  These are the cues to
recipients to indicate completeness of the set of points posted. The
id values don't need to be perfectly in order, but should just be
unique.

\vspace{0.1in}
\noindent
HINT: Consult the example script in the \app{uTimerScript}
documentation in the example "A Script for Generating 100 Random
Numbers" in the "Examples" section. The \app{uTimerScript}
documentation is found:

\vspace{0.1in}
\noindent
\urlx{http://oceanai.mit.edu/ivpman/apps/uTimerScript}

\vspace{0.1in}
\noindent
Or, from the command line:

\vspace{0.1in}
\begin{consoleverb}
$ uTimerScript --web  (or -w)
\end{consoleverb}
\vspace{0.1in}

\vspace{0.1in}
\noindent
How do we know this is working? There are a few options:

\begin{packed_itemize}
\item Check the output of the \app{uTimerScript} appcasting
  window. 
\item After quitting the mission, after the script has run, use the
  \app{aloggrep} tool, on the alog file created in the shoreside log
  file, grepping on \mvar{VISIT\_POINT}.
\item After quitting the mission, launch \app{alogview} on the
  shoreside alog file and use the \var{VarHist} pull-down menu,
  selecting \mvar{VISIT\_POINT}.
\end{packed_itemize}

\vspace{0.1in}
\noindent
Note: In the last two options, we are relying on the contents of the
alog file to confirm desired results. See the Section
\ref{sec_plogger} below for an extra configuration of \app{pLogger}
required in this mission. This is due to the fact that all our
\var{VISIT\_POINT} publications occur in a single burst.


%=======================================================================
\subsection{Create Shoreside pPointAssign MOOS App for Distributing Points}

Create a new \app{pPointAssign} MOOS application on the shoreside to
send half the points to one vehicle and half to the other. The app
should have the following capabilities:

\begin{packed_itemize}[1]

\item The app should subscribe to the \msvar{VISIT\_POINT} output of
  the timer script described in Section \ref{sec_visit_script} and
  produce output along the lines of:

\prevgreen
\begin{verbatim}
  VISIT_POINT_HENRY = "firstpoint"
  VISIT_POINT_HENRY = "x=8, y=9, id=1"
  ...
  VISIT_POINT_HENRY = "x=33, y=29,  id=50"
  VISIT_POINT_HENRY = "lastpoint"

  VISIT_POINT_GILDA = "firstpoint"
  VISIT_POINT_GILDA = "x=19, y=111, id=51"
  ...
  VISIT_POINT_GILDA = "x=-11, y=-9,  id=100"
  VISIT_POINT_GILDA = "lastpoint"
\end{verbatim}
\postverb

\noindent
Your app should follow the above format exactly. In a later lab we will want
to combine one person's shoreside community, connected to another person's
vehicle commmunity. The above format will be important in this regard.

\item The first and last postings made by \app{pPointAssign}, shared
  to each of the vehicles, should be
  \msvar{VISIT\_POINT\_VNAME="firstpoint"} and
  \msvar{VISIT\_POINT\_VNAME="lastpoint"}.  These are the indicators
  usable on the vehicle that confirm that the complete set of visit
  points have been sent and received.  The component \var{VNAME} above
  should be replaced by the vehicle name and there should be one such
  posting per vehicle.

\item The app should have a configuration parameter, \pvar{vname},
  which adds a known vehicle to the list of vehicles to which points
  will be distributed. In other words, the names \var{henry} and
  \var{gilda} shouldn't be hard-coded into the C++ code of
  \app{pPointAssign}, but should be parameters read in from a
  configuration file. 

\item Your app should support the assignment of points in one of two
  manners.  In the first manner, points are assigned in an alternating
  fashion. The first point to the first vehicle, second point to the
  second vehicle, third point to the first vehicle and so on. In the
  second manner, points are assigned according to region, e.g.,
  east-west.  The app should be configurable to either way with a
  configuration parameter \pvar{assign\_by\_region} set to either true
  or false. You can see the difference in the two videos shown in
  Section \ref{sec_tsp_runs}.

\item The east-west regions are simply the east and west halves of the
  region given earlier, with the four corners of \var{(-25,-25),
    (-25,-175), (200,-25), (200,-175)}.
  
\item {\bf NOTE:} When distributing points by East/West region, it is
  {\em not} necessary to have an exactly even amount sent to each
  vehicle. Just split the region in half and distribute
  accordingly. Given the uniform distribution of the random points,
  they should be close to 50-50 on each side, but no guarantee.

\end{packed_itemize}

%===============================================================
\subsection{Sharing Visit Points to Your Vehicles}

You need to share \app{pPointAssign} postings out to their respective
vehicles. For example you may want to share
\msvar{VISIT\_POINT\_HENRY} out to vehicle {\em henry} with the
arrival name \msvar{VISIT\_POINT}. Remember that you should handle the
share configuration with \app{uFldShoreBroker} now - not \app{pShare}.

%===============================================================
\subsection{Visual Output of Visit Points}

It would be helpful to have your \app{pPointAssign} app also produce
some visual output for \app{pMarineViewer}. This way you can verify
that your \app{pPointAssign} app is (a) receiving points, and (b)
grouping/handling them properly. Here is a suggested utility function
for accomplishing this:

\vspace{0.1in}

\begin{fileverb}
#include "XYPoint.h"    // Include this somewhere near the top of your file

...

void PointAssign::postViewPoint(double x, double y, string label, string color)
{
  XYPoint point(x, y);
  point.set_label(label);
  point.set_color("vertex", color);  // yellow is handy on dark screen 
  point.set_param("vertex_size", "4");

  string spec = point.get_spec();    // gets the string representation of a point
  Notify("VIEW_POINT", spec);
}
\end{fileverb}

\vspace{0.1in}
\noindent
The label should be unique for each point, otherwise
\app{pMarineViewer} will overwrite one point after another. A good
label would just be the ID associated with the visit point. Another
suggestion is to use a different color for each vehicle.

\vspace{0.1in}
\noindent
NOTE: The above code segment makes use of the \var{XYPoint} class,
which is part of the \var{lib\_geometry} library. To make use of this
class (and others like it, such as \var{XYSegList}, \var{XYPolygon}
etc.)  you will need to {\em link} against the \var{geometry}
library. To link against this library, just add \var{geometry} to list
of libraries that your app links to. This is found in the
\var{CMakeLists.txt} file for your \app{pPointAssign} application.

\vspace{0.1in}

\begin{consoleverb}
  $ cd moos-ivp-you/src/pPointAssign
  $ emacs CMakeLists.txt                 (or whatever text editor you use)
\end{consoleverb}


\vspace{0.1in}
\noindent
Then add the line as below:

\begin{fileverb}
TARGET_LINK_LIBRARIES(pPointAssign
   ${MOOS_LIBRARIES}
   geometry           &lt;--- Add this line
   mbutil
   m
   pthread)
\end{fileverb}

\vspace{0.1in}
\noindent
Further note: In Linux the order of the libraries is important. And
it's important to link against \var{geometry} first, before
\var{mbutil} as above. For some reason the MacOS compiler is resilient
to the order.


%===============================================================
\subsection{Issues to be Aware of - Gotchas}

%---------------------------------------------------------------
\subsubsection{Handshaking}

Recall that the MOOSDB only keeps track of the {\em most recent} value
of a variable. When a new app connects and registers for mail, it will
get only the latest value, not the entire history. Keep in mind that
your \app{pPointAssign} app needs {\em all} the output of your timer
script producing points. For this reason you will want to ensure that
the script starts {\em after} \app{pPointAssign} has connected to the
MOOSDB.  Consider launching the timer script in a paused mode, where
it gets automatically un-paused by the actions of
\app{pPointAssign}. See the \pvar{pause\_var} and \pvar{paused}
configuration parameters for \app{uTimerScript}.

\vspace{0.1in}
\noindent
Likewise, eventually your \app{pPointAssign} app will send
\mvar{VISIT\_POINT} messages to your vehicles, to be handled in your
\app{pGenPath} app. You will want to hold those outgoing messages from
\app{pPointAssign}, until \app{pPointAssign} has received an
indication that \app{pGenPath} app on the vehicle is ready to receive
them.

%---------------------------------------------------------------
\subsubsection{Logging Initial Bursts of Data}
\label{sec_plogger}

The \app{pLogger} app is typically configured to "log everything" via the
configuration parameter:

\vspace{0.1in}
\begin{fileverb}
 WildCardLogging = true
\end{fileverb}

\vspace{0.1in}
\noindent
However, the way this is implemented in the logger is to monitor the
list of variables known to the MOOSDB, published in the MOOS variable
\mvar{DB\_VAR\_SUMMARY}. Once the logger has seen a new variable known
to the MOOSDB, it will register for the variable. {\em However}, if
the first time a variable is published to the MOOSDB, it is published
in a burst of say 100 publications essentially at the same time, then
the logger may not log all publications. This is because, by the time
\app{pLogger} notices the new variable on the \var{DB\_VAR\_SUMMARY}
list, and then registers for subsequent publications, the initial burst
has finished and the logger was not able to register for them in time.

\vspace{0.1in}
\noindent
The way to avert this problem is to configure the logger to register for
such variables at the outset. We can still configure wildcard logging, but
we can also tell the logger to register for certain variables without
waiting for them to be seen on the \var{DB\_VAR\_SUMMARY} list. This can
be done with the following configuration line:

\vspace{0.1in}
\begin{fileverb}
 Log = VISIT_POINT @ 0 nosync
\end{fileverb}
\vspace{0.1in}

\noindent
The logger can be configured with as many of this lines as desired.

%=======================================================================
\subsection{Assignment 1 (check off) - Point Assignment and Communication}

Demonstrate the successful implementation of your \app{pPointAssign}
app, and the configuration of communications to your vehicles.

\begin{packed_itemize}
\item Demonstrate that your \app{pPointAssign} app is receiving and
  processing (grouping) all points by rendering the groups in different
  colors in \app{pMarineViewer}. An example would be the image on the
  cover page of this lab.

\item Demonstrate that your \app{pPointAssign} app is sending a proper
  group of points to one vehicle and the other part to the other
  vehicle.  This is simply to confirm that the share configuration is
  properly configured. 
\end{packed_itemize}

\vspace{0.1in}
\noindent
To demonstrate things are working, you have two options. The first is the
method traditionally used, before RealmCasting was available. Still works,
but probably harder and more cumbersome:

\begin{packed_itemize}

\item First method of demonstration: open two terminal windows, one for each
  vehicle, running \app{uXMS} with the \var{--history} option scoping
  on \mvar{VISIT\_POINT}.

\item Second method of demonstration: Add \app{pRealm} to the set of apps
  running on the shoreside and vehicle communities. In the vehicles, in the
  \app{pRealm} config block, add the configuration line:
  \pvar{hist\_var = VISIT\_POINT}. When the mission is launched, in
  \app{pMarineViewer}, you can toggle between AppCasting and RealmCasting
  by using the \var{'a'} key. Then you can select the vehicle and the history
  variable.
  
\end{packed_itemize}
  




%=======================================================================
\newpage
\section{Distributed Traveling Salesman - Preparing the Vehicle}
%=======================================================================

The vehicles in this lab will be sent a set of visit points from
the Shoreside, as described in the previous section. On the vehicle
a new MOOS app is needed to ingest those points, wait until all have
been received, and generate a path for visiting all points. That is
is the focus of this part of the lab.

\vspace{0.1in}
\noindent
In this part we will:
\begin{packed_itemize}
\item Create \app{pGenPath} MOOS App to be run on the vehicle side. It
  should subscribe for the points coming from \app{pPointAssign} on
  the shoreside, generate a sequence of waypoints, and then publish
  them to the helm as an update to a waypoint behavior.
    
\item Configure an autonomy mission on the vehicle to traverse the
  points while periodically returning to home. We will simulate a
  vehicle with limited energy for surveying, by mandating that it
  return home for refueling after some amount of time being under way.
\end{packed_itemize}



%=======================================================================
\subsection{Create a Vehicle pGenPath MOOS App for traversing points }

Create a new \app{pGenPath} MOOS module for running on the vehicle,
that takes as input a series of \msvar{VISIT\_POINT} messages from the
shoreside, and generates a waypoint list suitable for consumption by
the waypoint behavior.

\pskip

\noindent
In your behavior configuration, use a Waypoint behavior with an
\bvar{updates} parameter specifying the MOOS variable used for
incoming dynamic parameter configuration. In this case, the primary
incoming configuration will be the list of waypoints from your
\app{pGenPath} module. To make things a bit easier, {\em your shortest
  path algorithm may simply be a greedy shortest path} with an
imaginary virtual initial point being the vehicle's present position.

\pskip

\noindent
In your \app{pGenPath} module you can use the following pseudo code as
guidance for how to build a proper list of waypoints recognized by the
waypoint behavior:

\vspace{0.1in}
\footnotesize
\begin{verbatim}
  XYSegList my_seglist;
  my_seglist.add_vertex(3, 8);
  my_seglist.add_vertex(43, 99);
  my_seglist.add_vertex(44, -111);
  
  string update_str = "points = ";
  update_str      += my_seglist.get_spec();
  Notify("UPDATES_VAR", update_str);  // UPDATES_VAR depends on your config
\end{verbatim}
\normalsize

\vspace{0.1in}
\noindent
If your application uses the \var{XYSegList} class (recommended), your
app must link against the {\em geometry} library.  You will need to
edit the \var{CMakeLists.txt} file in your \app{pGenPath} application
folder.  In this file, simply add \var{geometry} in the
\var{TARGET\_LINK\_LIBRARIES} block. Similar to what you probably also needed
to do for the \app{pPointAssign} app in the previous part of the lab.

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

\begin{packed_itemize}
\item {\em Maximum vehicle speed}: The vehicle may go no faster than
  1.2 meters/sec.
\item {\em Tour Duration}: The vehicle may be underway no longer than
  10 minutes (600 seconds) before re-fueling will be required. To
  simplify things, you need not include the time required to return to
  home in this time limit.
\item {\em Refuel Duration}: Once the vehicle has returned home, it
  must wait at least 60 seconds before resuming its mission.
\end{packed_itemize}


%=======================================================================
\subsection{Handling and Re-visiting Missed Points}

You may find that the tour generated by a greedy algorithm has turns
that the vehicle simply cannot make quickly enough, causing the
vehicle to "miss" a point on the tour. You should use the
\bvar{slip\_radius} parameter (in the Waypoint behavior) with a high
enough number, e.g., 15, such that the vehicle does {\em not} come
back around for missed points.  For our lab, a visit to a point is
satisfied if the vehicle comes within three meters of the point.

\vspace{0.1in}
\noindent
In the {\em next} lab, we will re-design this mission such that,
upon completion of the tour, the \app{pGenPath} app makes a new tour
of all points missed on the previous tour. The \app{pGenPath} app can
keep track of visited points by simply noting the present vehicle
position on each iteration, and comparing it to known points in the
tour.  Upon each completion of a tour, or modified tour, the vehicle
should return home for re-fueling regardless of how long it has been
deployed since the previous re-fueling.

\vspace{0.1in}
\noindent
For now, we won't worry about "missed" points or re-visiting points on
a second tour. We mention this now in case you want to keep in mind
this upcoming challenge in building your \app{pGenPath} application.

%=======================================================================
\subsection{Practical Suggestions}

\subsubsection*{Make pGenPath an AppCastingMOOSApp}

In your \app{pGenPath} module, keep records of various state values, e.g., 
number of points received, visited, unvisited etc. Below is the appcast
output of my own implementation. Store and report whatever helps you 
debug your application.

\vspace{0.1in}
\begin{consoleverb}
===================================================================
pGenPath henry                                            0/0(6011)
===================================================================
Visit Radius:            3
Total Points Received:   55
Invalid Points Received: 0
First Point Received:    true
Last Point Received:     true
NAV_X/Y Received:        true

Tour Status              
------------------------ 
   Points Visited:       55
   Points Unvisited:     0
\end{consoleverb}
\vspace{0.1in}

\subsubsection*{Make pPointAssign an AppCastingMOOSApp}

For the same reasons as above, you may find good appcasting output for
\app{pPointAssign} will help you debug.


%=======================================================================
\subsection{Assignment 2 (check off) - Confirm your mission runs}
\label{sec_tsp_runs}

When your \app{pPointAssign} application is configured to assign
points in an alternating manner as they come in, your mission may look
something similar to the video posted below. Note that in this mission
the vehicle returns to visit points missed on the first tour. You
don't need to be concerned with this aspect of the mission until the
next stage, in the next lab.

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{educlips/lab_07_distributed_tsp_one.png}
  \caption{In the First Distributed TSP mission two vehicles are
    assigned randomly chosen points in the region to visit on a
    first-come basis.  Therefore their paths overlap and the mission
    is somewhat inefficient, but at least the same amount of points
    are assigned to each vehicle.}
  \label{fig_distributed_tsp_one}
  \urlvideo{https://vimeo.com/88013053}{1:52}
\end{figure}

\pskip
\noindent
When \app{pPointAssign} is configured to assign points by region, your
mission may look something like the video posted below.  Note that in
this mission the vehicle returns to visit points missed on the first
tour. You don't need to be concerned with this aspect of the mission
until the next lab.

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{educlips/lab_07_distributed_tsp_two.png}
  \caption{In the Distributed TSP Two mission two vehicles are
    assigned randomly chosen points in the region based on the section
    of the region.  Therefore their paths do not overlap and the
    mission is somewhat more efficient.}
  \label{fig_distributed_tsp_two}
  \urlvideo{https://vimeo.com/88017560}{2:03}
\end{figure}


%=======================================================================
\section{Suggestions for File Organization of Assignments}
%=======================================================================

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

You are encouraged to continue to upload all mission files.  Here is
the requested file structure:

\vspace{0.1in}
\begin{consoleverb}
  moos-ivp-extend/
    missions/
      lab_07/
        distributed_tsp/       
    src/
      pPointAssign/
      pGenPath/
\end{consoleverb}
\vspace{0.1in}

%=======================================================================
\subsection{Due Date}

Assignment 1 of this lab should be finished by the beginning of lab, Thursday, March
13th, 2025.

\vspace{0.1in}
\noindent
Assignment 2 of this lab is due by the end of lab, Thursday March 13th,
2025.

\end{document}



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