<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}

%====================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%====================================================================

\begin{document}

\begin{labcover}
\labtitle{The Rescue Manager App: uFldRescueMgr}
\vspace{0.1in}
\labdate{May 2024}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labtoc{small}
\end{labcover}

\wikidoc{file=IvPTools.UFldRescueMgr}
\wikidoc{auth=mikerb@mit.edu}

%====================================================================
\section{Overview}
%====================================================================
\label{sec_ufrm}

The \app{uFldRescueMgr} app, a.k.a. "rescue manager", was developed to
support the MIT 2.680 Autonomous Rescue Lab. This lab is a multi-week
lab in both simulation and in the water with four autonomus
robots. The rescue manager is the central course-provided software to
enable this lab sequence. 

\vspace{0.1in}
\noindent
The \app{uFldRescueMgr} app is the shoreside arbiter for the
Autonomous Rescue Lab sequence and competition. It holds the ground
truth information of swimmer locations and rescue status. Ground truth
locations are read in from a swim file, o may be added dynamically on
the shoreside by an operator. The status of the swimmers
(rescued/unrescued, found/unfound) are maintained by the rescue
manager but change status based on locations of the rescue vehicles or
scout vehicles. The rescue manager manages the games state in terms of
team tallies and declaration of a winning team.  The rescue manager is
available to participants when running test simulations, but will be
run on a shoreside computer by a competition manager (class TA) during
an competition, simulated or in-water.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.75\textwidth]{figures/ufrm_overview.png}
  \caption{{\bf The uFldRescueMgr}: is run in the shoreside community.
    It loads the ground truth of swimmers and locations from an swim
    file, and will convey this information to the vehicles when or if
    they are close enough to the swimmer. The resecue mananger will
    also grant or denie rescue requests from vehicles, and keep track
    of the rescue state for each swimmer, and tally of total swimmers
    rescued by each vehicle. The \app{pGenRescue} app is typically
    provided by competitors as the policy for visiting swimmers and
    attempting rescues.}
\label{fig_ufrm_overview}
\end{figure}
\vspace{0.1in}

%====================================================================
\section{Configuring a Mission to Use the Rescue Manager}
%====================================================================

To use the rescue manager, \app{uFldRescueMgr}, three steps are
required:

\begin{packed_itemize}
\item The \app{uFldRescueMgr} app must be added to the list of apps
  running on the shoreside.
\item The key variables needed by the rescue manager from the
  vehicles, and the variables published out to the vehicles, must be
  configured for sharing.
\item The rescue manager configuration block must be added to the
  shoreside mission file with desired parameter values if they differ
  from the default values. The name of the {\em swim file} must also
  be declared in this configuration block.
\end{packed_itemize}

\vspace{0.1in}
\noindent
These steps are described below. However, if using the rescue baseline
mission folder as part of MIT 2.680, many of these steps are already
in place in that folder. Users are welcome to change things during
simulation testing and development, but the shoreside settings will
largely be controlled by a competition administrator in a head-head
competition and the settings will not be changeable by the
participants fielding vehicles.

%====================================================================
\subsection{Running the Rescue Manager}

The rescue manager is run on the shoreside MOOS community. If using the
rescue baseline mission folder, this rescue manager is already present
in the shoreside mission file (\var{meta\_shoreside.moos}). It is
present in the Antler configuration block with a line:

\vspace{0.1in}
\begin{fileverb}
   Run = uFldRescueMgr  @ NewConsole = false
\end{fileverb}
\vspace{0.1in}

\noindent
In addition, the rescue manager will have a configuration block in the
same mission file. Publications of the rescue manager sent to the
vehicles, in the form of MOOS variables over \app{pShare}, must all be
configured in the \app{uFldShoreBroker} configuration block in the
shoreside mission file. More is said about these latter two steps in
the following sections below. Altogether, these three steps are all
that is needed to use the rescue manager. Just to reiterate, if using
the rescue baseline mission, these three steps are already implemented
in the shoreside mission file. Their description here is solely for
reference and in case any of the parameters may need to be changed in
the future.

%====================================================================
\subsection{Required MOOS Variable Shares to Vehicles}

Using \app{uFldRescueMgr} requires certain information flowing between
the shoreside and vehicles communities as shown in Figure
\ref{fig_ufrm_overview}. The sharing is done by \app{pShare}, but the
\app{pShare} configuration is handled dynamically using the
\app{uFldNodeBroker} and \app{uFldShoreBroker} applications, we
discuss here the necessary configuration entries for these two
applications.  From the vehicle to the shoreside, three key variables
need to be shared. The below lines should appear in the
\app{uFldNodeBroker} configuration block on all vehicles.

\prevblue
\begin{verbatim}
  // In uFldNodeBroker configuration
  // Shares from Vehicle to Shoreside specific to uFldRescueMgr

  bridge =  src=NODE_REPORT_LOCAL, alias=NODE_REPORT   // likely have already
  bridge =  src=RESCUE_REQUEST
  bridge =  src=SCOUT_REQUEST
\end{verbatim}
\postverb

\noindent
The first line, for sharing the \mvar{NODE\_REPORT}, would likely
already be present due to their use in other applications. The rescue
manager needs to know vehicle locations to enable it to determine
whether rescue attempts are granted.  The latter two variables are
generated by vehicles participating in the competition. They could
originate in a user MOOS app, or simply in a timer script on the
vehicle.

\vspace{0.1in}
\noindent
The below four lines should appear in the \app{uFldShoreBroker}
configuration block in the shoreside MOOS community (along with likely
several other lines). See \app{uFldShoreBroker} documentation for a
discussion on the syntax.

\prevblue
\begin{verbatim}
  // Shares from Shoreside to Vehicle - in uFldShoreBroker config

  bridge =  src=RESCUED_SWIMMER
  bridge =  src=SCOUTED_SWIMMER_$V,    alias=SCOUTED_SWIMMER
  bridge =  src=SWIMMER_ALERT_$V,      alias=SWIMMER_ALERT
  bridge =  src=NODE_COLOR_CHANGE_$V,  alias=NODE_COLOR_CHANGE_REQUEST
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
The lines that have a source component ending \var{\$V} configure MOOS
variables intended to be shared to a particular vehicle. For example,
a post to \mvar{SCOUTED\_SWIMMER\_ABE} by \app{uFldRescueMgr} on the
shoreside will be shared only to vehicle abe, and it will arrive on
abe as the variable \mvar{SCOUTED\_SWIMMER}. On the other hand, a post
to \mvar{RESCUED\_SWIMMER} will be shared to all vehicles. This is by
design since a swimmer rescue is meant to be known by everyone when it
happens, whereas the information about a previously unknown swimmer is
meant to be shared only to the scout vehicle that came across the new
swimmer. For more information on bridging, see the documentation for
\app{uFldShoreBroker}. (Type \var{uFldShoreBroker -w} on the command
line.)

%====================================================================
\subsection{Configuring the Rescue Manger}
\label{sec_ufrm_config}

The rescue manager has a number of configuration parameters dictating
both the performance of the app as well as preferences for visual
rendering of state. The set of configuration options is listed
thouroughly in Section \ref{sec_ufrm_config_params}, with default
values. It should be noted that the configuration for this app in the
rescue baseline mission may occasionally have different parameter
values.

\vspace{0.1in}
\noindent
A key configuration parameter for \app{uFldRescueMgr} is the
specification of the {\em swim file}. This file contains the ground
truth of swimmers and their locations, and is typically found in the
mission folder where the shoreside MOOS community is launched. This
is described next.

%====================================================================
\section{Swimmers and Swim Files}
%====================================================================

The rescue manager reasons over {\em swimmers}. A {\em swim file} is
a plain text file specifying a collection of swimmers. 

%====================================================================
\subsection{Swimmers}
\label{sec_ufrm_swimmers}

A {\em swimmer} has the following characteristics:

\begin{packed_itemize}
\item The \var{(x,y)} location.
\item The swimmer \var{name}.
\item The swimmer \var{type}.
\end{packed_itemize}

\vspace{0.1in}
\noindent
The swimmer location will reside in prescribed search region given by
a convex polygon. The name is unique to each swimmer. The type is
either \var{registered} or \var{unregistered}.  In a swim file, a
particular swimmer entry will be described in a single line, e.g.,

\vspace{0.1in}
\begin{fileverb}
  swimmer = type=reg, name=p03, x=34, y=98
\end{fileverb}
\vspace{0.1in}

\noindent

During the course of a competition, a swimmer will also have the
following state:

\begin{packed_itemize}
\item The swimmer \var{state}: either rescued or unrescued.
\item The vehicle \var{savior}: a vehicle name that rescued the
  swimmer, or an empty string if unrescued.
\item The UTC \var{time} of rescue or -1 if unrescued.
\item The swimmer ID: an alias for the swimmer name. 
\item The set of scouted vehicles: Vehicles that know about the
  swimmer, in the case of unregistered swimmers only.
\end{packed_itemize}

\vspace{0.1in}
\noindent
At the outset of the mission, the ID and position of registered swimmers
are sent to all vehicles with \mvar{SWIMMER\_ALERT} message:

\vspace{0.1in}
\noindent
\mvar{SWIMMER\_ALERT\_ABE = id=38, x=45,y=98}

\vspace{0.1in}
\noindent
Alerts are sent individually to each vehicle. 


%====================================================================
\subsection{Registered vs. Unregistered Swimmers}

The optional use of unregistered swimmers supports a mission variation
where scout vehicles work in collaboration with rescue vehicles. It is
this feature of \app{uFldRescueMgr} that enables the "collaborative"
autonomy aspect of this rescue lab. Without unregistered swimmers,
there would be no use for a scout vehicle. 

\vspace{0.1in}
\noindent
Registered and unregistered swimmers differ primarily in that the
former are broadcast to all vehicles at launch time and continuously
throughout a mission. Unregistered swimers are known to the rescue
manager at mission start time and only become known to a vehicle if
the a {\em scout vehicle} discovers the unregistered swimmer. An
unregistered swimmer may be known to no vehicles, one vehicle, or
multiple vehicles.

\vspace{0.1in}
\noindent
At the outset, registered swimmers are rendered in a single neutral
colored triangle. In the rescue baseline mission this is set to lime.
Unregistered swimmers are rendered initially as two half-circles, with
both halfs initially transparent. Two transparent halves means the
unregisered swimmer is not known to either team. If half the circle is
colored, say yellow, this indicates the yellow team knows about the
swimmer. If both halfs are colored, say yellow and red, then both the
red team and yellow team know about the swimmer, as in Figure
\ref{fig_unreg_markers} below.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.55\textwidth]{figures/unreg_markers.png}
  \caption{{\bf Unregistered Swimmers}: An unregistered swimmer known
    to neither team is rendered with two colorless half circles
    (left). An unregistered swimmer known only to the yellow team
    (center). An unregistered swimmer known to both the red and yellow
    teams (right).}
\label{fig_unreg_markers}
\end{figure}
\vspace{0.1in}

\noindent
The renderings are just for the sake of awareness for the user looking
at the GUI. Vehicles on one team are not aware about what knowledge
the other vehicles on the other team have.

\noindent
If a vehicle from say the yellow team later rescues this swimmer, the
swimmer will be rendered with a yellow triangle. See Figure
\ref{fig_scout_and_tell}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.90\textwidth]{figures/scout_and_tell.png}
  \caption{{\bf Scout and Tell}: In this game snippet, first the
    yellow scout vehicle discovers the swimmer \var{x23}. After
    discovery, the scout vehicle immediately sends a message to the
    yellow rescue vehicle with the location of the newly found
    swimmer.  A short time later, the red scout vehicle discovers the
    same swimmer and also informs its rescue vehicle teammate. At this
    point the unregisted swimmer is rendered as half red, half
    yellow. Finally the yellow rescue vehicle swoops in and rescues
    this unregistered swimmer after which it is rendered simply as a
    yellow triangle.}
  \label{fig_scout_and_tell}
  \gif{figures/scout_and_tell.gif}
\end{figure}
\vspace{0.1in}

%====================================================================
\subsection{Swim Files}
\label{sec_ufrm_swim_files}

Swim files are used for seeding the rescue mission with a number of
swimmers and their locations. They are plain text files usually
generated from a command line utility called \cmd{gen\_swimmers}
discussed in a following seciton. The utility is provided with a
polygon region from which to choose random locations, and a constraint
on the minimum distance between swimmers. 

\vspace{0.1in}
\noindent
Below is an example file. Note the first line is a comment, showing
the exact command line argument used in creating the file. The
second line is also a comment showing the actual minimum distance
between any two swimmers. In this example the requested min distance
was 10 meters, and the resulting file satisfies this constraint.
The third line is the polygon region from which the random swimmer
locations were selected. 

\vspace{0.1in}
\begin{fileverb}
// gen_swimmers --pav60 --swimmers=5 --sep=10
// Lowest dist between swimmers: 11.40
poly = pts={60,10:-30.3602,-32.8374:-4.6578,-87.0535:85.7024,-44.2161}
swimmer = name=p01, x=57, y=-1
swimmer = name=p02, x=54, y=-12
swimmer = name=p03, x=-12, y=-33
swimmer = name=p04, x=-9, y=-66
swimmer = name=p05, x=-11, y=-49
\end{fileverb}
\vspace{0.1in}

\noindent
The swim file is read as a coniguration parmeter in the configuration
block of \app{uFldRescueMgr}. The polygon is read in by
\app{uFldRescueMgr} as well as the swimmers. The polygon region is also
broadcast to all vehicles. Vehicles may use this polygon region as in
input parameter for the OpRegion helm behavior.

\vspace{0.1in}
\noindent
In the example above, each swimmer is assumed to be a registered swimmer
since the type was not specified. For swim files containing unregistered
swimmers, like the example below, each swimmer line will be explicit
in declaring the swimmer type.

\vspace{0.1in}
\begin{fileverb}
// gen_swimmers --pav60 --swimmers=5 --unreg=4
// Lowest dist between swimmers: 15.00
poly = pts={60,10:-30.3602,-32.8374:-4.6578,-87.0535:85.7024,-44.2161}
swimmer = type=reg, name=p01, x=66, y=-12
swimmer = type=reg, name=p02, x=53, y=-49
swimmer = type=reg, name=p03, x=12, y=-37
swimmer = type=reg, name=p04, x=35, y=-22
swimmer = type=reg, name=p05, x=59, y=-26
swimmer = type=unreg, name=x01, x=30, y=-53
swimmer = type=unreg, name=x02, x=2, y=-82
swimmer = type=unreg, name=x03, x=44, y=-37
swimmer = type=unreg, name=x04, x=69, y=-42
\end{fileverb}
\vspace{0.1in}

\noindent
Note that registered swimmers are names \var{p01}, \var{p02} up to say
\var{p45} for 45 registered swimmers. Unregistered swimmers use the
labelling \var{x01}, \var{x02} and so on. The swimmer {\em name} is
only showed on the GUI. Vehicles receive a scrambled ID number so the
vehicles are not able to infer the total number of swimmers of any
type.

\vspace{0.1in}
\noindent
{\bf Note:} The swim file is logged along with the shoreside alog file
and shoreside mission file, to be clear later if there is any doubt
about the actual swim file used in a mission. This is ensured by the
rescue manager by posting

\vspace{0.1in}
\noindent
\mvar{PLOGGER\_CMD = COPY\_FILE\_REQUEST=swim\_file.txt}
    
\vspace{0.1in}
\noindent
The \mvar{PLOGGER\_CMD} is read by \app{pLogger} and is useful
feature baked into logger that comes with MOOS. The file
\var{swim\_file.\_txt} will be found in the log folder.

%====================================================================
\subsection{Generating Swim Files}

\noindent
Swim files are created using the \app{gen\_swimmers} command-line utility.
This utility generates output to the terminal. A swim file can be
created by re-directing the output to a file. For example:

\vspace{0.1in}
\begin{consoleverb}
$ gen_swimmers --pav60 --swimmers=15 --unreg=5 --buf=10 &gt; swim_file.txt
\end{consoleverb}
\vspace{0.1in}

\noindent
The result is just a plain text file and can simply be edited. But the
command-line utility ensures (a) all swimmer locations are within the
given polygon rescue region, and (b) the minimum distance between
swimmers is respected if it is specified. The utility is passed a
convex polygon command line argument describing the region from which
to randomly pick swimmer locations. For example:

\vspace{0.1in}
\begin{consoleverb}
$ gen_swimmers --poly=60,10:-30.4,-32.84:-4.7,-87.1:85.7,-44.2 --swimmers=10
\end{consoleverb}
\vspace{0.1in}

\noindent
Or the options \var{--pav60} or \var{--pav90} can be used as shortcuts
for the two common operation areas at the MIT Sailing Pavilion and
used in the rescue baseline mission.

\vspace{0.1in}
\noindent
To see more complete documentation of this utility, run:

\vspace{0.1in}
\begin{consoleverb}
$ gen_swimmers --web
\end{consoleverb}
\vspace{0.1in}

\noindent
The \app{gen\_swimmers} utility is in \var{moos-ivp-2680} tree.

%====================================================================
\subsection{Viewing a Swim File}
\label{sec_ufrm_swimview}

The \app{swimview} command-line utility enables a user to visually
preview the swim file with a visual background of the rescue region
polylgon. Without this utility, the only other option for visualizing
the layout of swimmers for a give swim file would be to launch a
simulation utilizing this swim file. This utility allows the visualization
without all the simulation, and the user can toggle between several
choices for quick comparison. 

Launching from the command-line:

\vspace{0.1in}
\begin{consoleverb}
$ swimview swim_file1.txt swim_file2.txt swim_file3.txt ...
\end{consoleverb}
\vspace{0.1in}

\noindent
The viewer will allow for toggling through different swim files with
the \var{[} and \var{]} keys. Figure \ref{fig_swimview} conveys the
idea. 

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.80\textwidth]{figures/swimview.png}
  \caption{{\bf The swimview Utility}: Multiple swimfiles can be loaded
    for quick visualization and comparison between swimmer layouts.}
  \label{fig_swimview}
\end{figure}
\vspace{0.1in}



%====================================================================
\section{Operation of the Rescue Manager}
\label{sec_ufrm_operation}
%====================================================================

A mission involving the rescue manager is mission constituting an
adversarial head-to-head competition. The rescue manager needs to
(a) know the ground truth in terms of swimmer and vehicle locations,
(b) handle interactions with the vehicle including rescue attempts
and scout/sensor requests, and (c) manage and convey game state to
both the set of vehicles as well as in the shoreside operational
display.

%====================================================================
\subsection{Rescuing Swimmers}
\label{sec_ufrm_rescue}

The core interaction with a vehicle comes when a vehicle attempts to
rescue a swimmer. In short, a vehicle will score a successful rescue
when (a) it is sufficiently close to an un-rescued swimmer and (b) the
vehicle generates a rescue request message received on the shoreside
by the rescue manager.

\vspace{0.1in}
\noindent
A rescue request coming from a vehicle will look like:

\vspace{0.1in}
\noindent
\mvar{RESCUE\_REQUEST   = vname=abe}

\vspace{0.1in}
\noindent
The vehicle name is all the information needed by the rescue manager.
If there is a yet-to-be rescued swimmer sufficiently closs to the
named vehicle, the rescue manager will respond by posting a message
like the one below. This message will be sent to {\em all} vehicles.

\vspace{0.1in}
\noindent
\mvar{RESCUED\_SWIMMER  = id=07,finder=abe}  \var{(From shoreside to all vehicles)}

\vspace{0.1in}
\noindent
The reason it is sent to all vehicles is to allow other vehicles to
adjust their plans accordingly, presumably removing that swimmer from
any tour of waypoints currently being traversed. The ID component
makes clear which swimmer has been rescued. All swimmers announced to
the vehicles at the outset have the same ID values for the same
swimmers.  The \var{finder} field is also conveyed to a vehicle
attempting a rescue can be sure that their rescue attempt was
successful and not perhaps another nearby vehicle.

%====================================================================
\subsection{Rescue Criteria}
\label{sec_ufrm_rescue_rng}

A rescue request is granted if (a) a rescue request is received from
a vehicle as discussed above, (b) the swimmer has not already been
rescued, (c) the rescue vehicle is sufficiently close to the swimmer.
The rescue range (meters) is determined by two configuration parameters:

\begin{packed_itemize}
\item \pvar{rescue\_rng\_min}: Range within which a rescue
  request is has a probability of \pvar{rescue\_rng\_pd}.
\item \pvar{rescue\_rng\_max}: Range beyond which a rescue
  request has a probability of 0.
\item \pvar{rescue\_rng\_pd}: Maximum rescue probability for a
  rescue request.
\end{packed_itemize}

\vspace{0.1in}
\noindent
The probability, $p$, of a given request being granted is:

\vspace{0.08in}
\begin{twequation}
  \input{eq_rescue_pd}
\end{twequation}

\vspace{0.1in}
\noindent
The two ranges can be rendered with two conenctric circles, as
depicted in Figure \ref{fig_good_rescue}. The posting of these circle
can be disabled by setting \pvar{show\_rescue\_range=false}. The
default value is true. Furthermore, the transparency of the circles
can be altered by setting \pvar{rescue\_range\_transparency=N} where N
is in the range \var{[0,1]}, where $1$ is completely opaque and $0$ is
completely transparent. The default value is \var{0.1} .

%====================================================================
\subsection{Rescuing Swimmers Visuals}
\label{sec_ufrm_visuals}

When a swimmer has been rescued, this will be apparent in couple ways
visually through \app{pMarineViewer}. First, the appcasting output of
the \app{uFldRescueMgr} app will change in three ways. (1) the total
number of swimmers rescued for each vehicle is displayed, (2) the
status of each swimmer is shown in an table with the name of the
rescuing vehicle if it has been rescued, and (3) the recent-event
portion at the bottom of the appcasting window will show/confirm the
most recently rescued swimmer. See Section \ref{sec_ufrm_appcast} for
more on the appcasting output of the rescue manager.

\vspace{0.1in}
\noindent
The other apparent change is more readily visible: the swimmer will
change color. It should take on the color of the vehicle that was
granted the rescue. For this reason, the designer of the mission
needs to take a little care to choose a color for unrescued swimmers
that is different for any colors that will be used by vehicles. In
the \var{rescue\_baseline} mission, the unrescued color is set to
\var{"lime"}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.90\textwidth]{figures/good_rescue.png}
  \caption{A the yellow vehicle rescues swimmers, the swimmer marker
    changes from the neutral color (lime) to the color of the vehicle
    that achieved the rescue.}
\label{fig_good_rescue}
\gif{figures/good_rescue.gif}
\end{figure}
\vspace{0.1in}

\noindent
As discussed further in Section \ref{sec_ufrm_game_state}, the color
of the marker may take on a bright or dim color. If bright, then the
marker represents a differential over the scores made by a
competitor. For example if a red team has made three rescues, and the
yellow team five, then there will be shown three dimly colored red
markers, three dimly lit yellow markers, and two bright yellow
markers.  And where there is a tie, all markers will have a dim color.


%====================================================================
\subsection{Finding (Scouting) Unregistered Swimmers}
\label{sec_ufrm_scout}

The rescue manager knows about two types of vehicle roles, {\em rescue}
and {\em scout}. The goal of a scout vehicle is to look for, discover
and report the existence and location of unregistered swimmers. An
unregistered swimmer is initially unknown to both teams, and eventually
may be known either or both teams. 

A scout vehicle may generate a scout request in the form of a message
similar to:

\vspace{0.1in}
\noindent
\mvar{SCOUT\_REQUEST = vname=cal, tmate=abe}

\vspace{0.1in}
\noindent
If the scout request is "fresh", e.g., received within the last five
seconds, the rescue manager on each iteration will examine the vehicle
location relative to each swimmer. Each examination will essentially
involve a dice-roll. A successful dice-roll will generate a message
back to the scouting vehicle of the form:

\vspace{0.1in}
\noindent
\mvar{SCOUTED\_SWIMMER\_CAL = id=34, x=90, y=-2}

\vspace{0.1in}
\noindent
The \var{\_CAL} portion of the above posted MOOS variable matches the
\var{vname} component of the scout request in the example above. It is
sent only to this vehicle.  Presumably the scout vehicle is then free
to send a message to its rescue vehicle teammate about the presence of
a new swimmer. The success or failure of the dice roll depends on the
three parameters described in Section \ref{sec_ufrm_rescue_rng}.

\vspace{0.1in}
\noindent
If a rescue vehicle comes across an unregistered swimmer that has not
yet been rescued, it can be rescued by the rescue vehicle. It does not
need to have been informed by its scout vehicle teammate.

%====================================================================
\subsection{Tracking Game State, and Game State Notifications}
\label{sec_ufrm_game_state}

The rescue manager also keeps score. It keeps a running tally of
total swimmers rescued by each vehicle. Every time there is a leader
change, the rescue manager posts:

\vspace{0.1in}
\noindent
\mvar{UFRM\_LEADER = vname}

\vspace{0.1in}
\noindent
The \var{vname} is the name of the rescue vehicle, or the word
\var{"tie"} if the game is tied. The first such posting during a
competition will be for the first vehicle that makes a rescue. There
will be no initial posting \mvar{UFRM\_LEADER=tie} at the outset.

\vspace{0.1in}
\noindent
\noindent
As discussed previously in Section \ref{sec_ufrm_visuals}, the color
of the marker for a rescued swimmer may take on a bright or dim
color. If bright, then the marker represents a differential over the
scores made by a competitor. For example, as in Figure
\ref{fig_leader_bright} below, if a yellow team has made three
rescues, and the red team two, then there will be shown two
dimly colored red markers, two dimly lit yellow markers, and one
bright yellow marker. And Where there is a tie, all markers will
have a dim color.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.75\textwidth]{figures/leader_bright.png}
  \caption{As the vehicles rescue swimmers, the swim marker turns the
    color of the vehicle making the rescue. The team that has rescued
    more swimmers will render the markers representing the differential
    with brighter colors. In this example, The yellow team has scored
    three, and the red team two. There for there is one bright yellow
    marker shown.}
\label{fig_leader_bright}
\gif{figures/leader_bright.gif}
\end{figure}
\vspace{0.1in}

\noindent
The rescue manager can be configured to post one or more MOOS flags at
the moment the leader changes value, set in the \pvar{leader\_flag}
configuration parameters. For example:

\vspace{0.1in}
\noindent
\pvar{leader\_flag = SAY\_MOOS = \$LEADER is the current leader}

\vspace{0.1in}
\noindent
With the above, if the \app{iSay} app is also running on the
shoreside, the mission could be configured to make an audible
declaration of a leader change.

\noindent
The game state, with further details of totals for each team, can be
gleaned from the appcasting output of the rescue manager app, as
discussed in Section \ref{sec_ufrm_appcast}.





%====================================================================
\subsection{End of Game Criteria}
\label{sec_ufrm_end_game}

\subsubsection*{Winning and Finishing}

There are two end-game notions: when the game has been {\em won}, and
when the game is {\em finished}. A game is won when the winning
vehicle team has been cemented. A game is finished when all known
swimmers have been rescued.  The reason for continuing after a game
has been won is to allow the winning team to establish the dominance
of their win. There are two reasons for this: (a) in certain
circumstances an overall competition may be defined as the cumulative
score across individual competitions, (b) one way of measuring the
effect of an algorithm improvement may be to measure the improved
dominance over a baseline opponent. It may be convenient normalize
the winning score in the range of the total number of swimmers. 

\vspace{0.1in}
\noindent
The competition can be configured to finish when a winner has been
cemented with the configuration parameter:

\vspace{0.1in}
\noindent
\pvar{finish\_upon\_win = true}

\vspace{0.1in}
\noindent
The default is false. 


\subsubsection*{Winning in the Rescue-Rescue Mission}

A game is won when one team's rescue vehicle has rescued the majority
of swimmers known to either team at that time.  In the case of the
one-on-one rescue-rescue variation, with no unregistered swimmers,
this is pretty unambiguous. For these missions a swim file with an
odd number of swimmers is always preferred. 

\subsubsection*{Winning in the Rescue-Scout2 Mission}

In the two-on-two rescue-scout2, a.k.a. "rs2" mission, further
clarification is warranted: the rescue manager knows, at any given
point in time, the count of registered, scouted unregistered vehicles,
and unscouted registered vehicles. The sum of the first two groups is
the total of presently "known" vehicles. As the scout vehicle from
either team proceeds, more unscouted unregistered swimmers may move
onto the list of scouted unregistered swimmers. An unregistered
swimmer is considered a {\em scouted} when at least one vehicle has
scouted the swimmer.

\vspace{0.1in}
\noindent
So in the rs2 mission the game is won at the first point in time when
the majority of the currently known swimmers has been rescued by one
team. Of course at that point there still may be undiscovered,
unscouted unregistered swimmers, and the losing vehicle may in theory
be able to still rescue more swimmers. For this reason, in the rs2
mission, the competion is finished when one team has won, even if
the \pvar{finish\_upon\_win} parameter is set otherwise.

\subsubsection*{Tie-Breakers in the Rescue-Scout2 Mission}

In the rs2 mission the number of presently known swimmers may be an
even number. If the competition ends with each team having rescued the
same amount of swimmers, the tie break comes down to the timestamp of
the final swimmer rescue. The losing team would then be the one that
was last to discover its final swimmer.

\subsubsection*{Win Flags and Finished Flags}

The rescue manager can be configured to post one or more MOOS flags at
the moment the competition has been won, or the has finished, set in
the \pvar{winner\_flag} or \pvar{finish\_flag} configuration
parameters. For example:

\vspace{0.1in}
\noindent
\pvar{winner\_flag = SAY\_MOOS = \$WINNER has won}

\vspace{0.1in}
\noindent
With the above, if the \app{iSay} app is also running on the
shoreside, the mission could be configured to make an audible
declaration of the winner.

\vspace{0.1in}
\noindent
Another example:

\vspace{0.1in}
\noindent
\pvar{finish\_flag = RETURN\_ALL = true}

\vspace{0.1in}
\noindent
With the above, all vehicles will automatically transition to return home
after the competition has finished. The leader, winner and finish flags
support the two macros \var{\$WINNER} and \var{\$LEADER} expanded to
the name of the vehicle winning or leading at the time of the posting.

%====================================================================
\subsection{Dynamic New Swimmers and Rescues - For Testing}
\label{sec_ufrm_xevent}

It is possible to inject {\em dynamic} swimmers during the course of a mission,
after \app{uFldRescueMrg} has been started and loaded with a swim file. The
reason for supporting this is to allow a user to simulate (a) the discovery of
new swimmers (alerts), and (b) the message indicating that someone else
has rescued a known swimmer. This is to simplify testing of these events
during development.

\vspace{0.1in}
\noindent
A new swimmer is added when the rescue manager receives a message like:

\vspace{0.1in}
\noindent
\mvar{XSWIMMER\_ALERT = type=reg, x=31, y=193}

\vspace{0.1in}
\noindent
Unregistered swimmers can also be added with:

\vspace{0.1in}
\noindent
\mvar{XSWIMMER\_ALERT = type=unreg, x=139, y=-73}  \var{(Note type=unreg)}

\vspace{0.1in}
\noindent
In the rescue baseline mission, \app{pMarineViewer} is configured to
allow mouse clicks adding registered and unregistered swimmers. Doing
so may looks something like:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.90\textwidth]{figures/dynamic_add.png}
  \caption{{\bf Dynamic Swimmers}: In this simulation snippet, the
    viewer is configured to allow the user to add registered or
    unregistered swimmers at the location of the left or right mouse
    click. This allows the user to test either of these events in
    isolation.}
  \label{fig_dynamic_add}
  \gif{figures/dynamic_add.gif}
\end{figure}
\vspace{0.1in}


\noindent
Similar to adding new swimmers, the rescue manager allows for the simulation of a
rescue made by "another" vehicle. This is done by posting a message such as:

\vspace{0.1in}
\noindent
\mvar{XFOUND\_SWIMMER = x=31, y=193}

\vspace{0.1in}
\noindent
This will result in the rescue of the nearest currently-unrescued
swimmer, as long as it is within 10 meters of the x-y point
specified. The savior, or credit, rather than going to any named
vehicle, is listed simply as "nature". This feature is a handy tool,
when configured as in the rescue baseline mission, with the \app{pMarineViewer}
configuration, to test how the path of the rescue vehicle is updated
when a previously unrescued swimmer has become rescued. An example of this
user intervention is shown in Figure \ref{fig_dynamic_found}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.90\textwidth]{figures/dynamic_found.png}
  \caption{{\bf Dynamic Rescue}: In this simulation snippet, the viewer
    is configured to add registered or unregistered swimmers at the location
    of the left or right mouse click. This allows the user to test either
    of these events in isolation.}
  \label{fig_dynamic_found}
  \gif{figures/dynamic_found.gif}
\end{figure}
\vspace{0.1in}





%====================================================================
\section{Configuration Parameters of uFldRescueMgr}
\label{sec_ufrm_config_params}
%====================================================================

The following parameters are defined for \app{uFldRescueMgr}. A more
detailed description is provided in other parts of this
section. Parameters having default values are indicated so.

\vspace{0.15in}
\begin{listing}{Configuration Parameters for \app{uFldRescueMgr}}
\label{lst_uhma_params}
\renewcommand{\arraystretch}{1.1}
\begin{longtable}{rp{0.69\textwidth}} 

  \pvar{swim\_file}: &amp; The file with ground truth information on
  swimmer location, ID and swimmer type. Section
  \ref{sec_ufrm_swimmers} and Section \ref{sec_ufrm_swim_files}. \\

  \pvar{swimmer\_color}: &amp; The default color of markers representing
  known swimmers, before they are rescued. The default is
  \var{dodger\_blue}. In the rescue baseline mission it is set
  to \var{lime}. Section \ref{sec_ufrm_visuals}. \\

  \pvar{show\_rescue\_range}: &amp; If true, visual range circles are
  generated to be displayed around the moving vehicle to indicate the
  range within which a rescue will be made of a nearby swimmer. The
  default is true. Section \ref{sec_ufrm_rescue_rng}. \\

  \pvar{rescue\_range\_transparency}: &amp; The transparency of the rescue
  range circles if they are rendered. The default is \var{0.1}, where
  \var{0} is completely transparent, and \var{1} is completely
  opaque. Section \ref{sec_ufrm_rescue_rng}. \\

  \pvar{rescue\_range\_min}: &amp; The range between swimmer and vessel,
  within which a rescue request is guaranteed to be successful. The
  default is 25 meters. However, in the rescue baseline mission, it is
  set to 3 meters. Section \ref{sec_ufrm_rescue_rng}. \\

  \pvar{rescue\_range\_max}: &amp; The range between swimmer and vessel,
  beyond which a rescue request is guaranteed to be unsuccessful. The
  default is 40 meters. However, in the rescue baseline mission, it is
  set to 5 meters. Section \ref{sec_ufrm_rescue_rng}. \\
  
  \pvar{rescue\_range\_pd}: &amp; The probability success for a rescue
  request when the range between the simmer and the vessel is at or
  less than the \pvar{rescue\_range\_min}. The probability decrease to
  zero between \pvar{rescue\_range\_min} out to
  \pvar{rescue\_range\_max}, beyond which the probability is
  zero. Legal settings are in the range \var{(0,1]}. The default value
    is 1.0. Section \ref{sec_ufrm_rescue_rng}. \\

  \pvar{leader\_flag}: &amp; A flag posted when there is a change in the
  leader. Section \ref{sec_ufrm_game_state}. \\

  \pvar{finish\_flag}: &amp; A flag posted when the competition has
  finished. Section \ref{sec_ufrm_end_game}. \\

  \pvar{winner\_flag}: &amp; A flag posted when a winner has been
  cemented. Section \ref{sec_ufrm_end_game}. \\

  \pvar{finish\_upon\_win}: &amp; If true, the competition is declared
  finished when a winner has been declared (no change of leadership
  possible). The default is false. See
  Section\ref{sec_ufrm_end_game}. \\ 

\end{longtable}
\end{listing}

%====================================================================
\subsection*{An Example MOOS Configuration Block}

To see an example MOOS configuration block, enter the following from
the command-line:

\vspace{0.1in}
\begin{consoleverb}
 $ uFldRescueMgr --example or -e
\end{consoleverb}
\vspace{0.1in}

\noindent
This will show the output shown in Listing \ref{lst_ufrm_econfig} below.

\vspace{0.25in}
\begin{listing}{Example configuration of the uFldRescueMgr application}
\label{lst_ufrm_econfig}
\footnotesize
\begin{verbatim}
  1  =============================================================== 
  2  uFldRescueMgr Example MOOS Configuration                   
  3  =============================================================== 
  4                                                                  
  5  ProcessConfig = uFldRescueMgr                                   
  6  {                                                               
  7    AppTick   = 4                                                 
  8    CommsTick = 4                                                 
  9                                                                  
 10    // Common to all appcasting MOOSApps                          
 11    term_report_interval = 0.4                  // default        
 12    max_appcast_events   = 8                    // default        
 13    max_appcast_run_warnings = 10               // default        
 14                                                                  
 15    swim_file     = file.txt                                      
 16    swimmer_color = dodger_blue                                   
 18                                                                  
 19    // Configuring visual preferences                             
 20    show_rescue_rng = true                      // default        
 21    rescue_rng_transparency = 0.2               // default        
 22                                                                  
 23    // Sensor Config                                              
 24    rescue_rng_min   = 25                       // default        
 25    rescue_rng_max   = 40                       // default        
 26    rescue_rng_pd    = 0.5                      // default        
 27                                                                  
 28    // Event Flags                                                
 29    leader_flag = NEW_LEADER=$[LEADER]                            
 30    winner_flag = NEW_WINNER=$[WINNER]                            
 31    finish_flag = MISSION_COMPLETE=true                           
 32    finish_flag = RETURN_ALL=true                                 
 33                                                                  
 34    finish_upon_win = false                     // default        
 35  } 
\end{verbatim}
\end{listing}
\normalsize
 
%====================================================================
\section{Publications and Subscriptions for uFldRescueMgr}
%====================================================================
\label{sec_ufrm_interface}

The interface for \app{uFldRescueMgr}, in terms of publications and
subscriptions, is described below. This same information may also be
obtained from the terminal with:

\vspace{0.1in}
\begin{consoleverb}
 $ uFldRescueMgr --interface or -i
\end{consoleverb}
\vspace{0.05in}

%====================================================================
\subsection{Variables Published by uFldRescueMgr}
\label{sec_ufrm_pubs}

The primary output of \app{uFldRescueMgr} to the MOOSDB is the posting
of requests for sensor information and the generation of results back
to the vehicles.

\begin{packed_itemize}[2]
\item \mvar{APPCAST}: Contains an appcast report identical to the
  terminal output. Appcasts are posted only after an appcast request
  is received from an appcast viewing utility. Section
  \ref{sec_ufrm_appcast}

\item \mvar{NODE\_COLOR\_CHANGE\_ABE}: A message. Section

\item \mvar{PLOGGER\_CMD}: A message. Section \ref{sec_ufrm_swim_files}.

\item \mvar{RESCUE\_REGION}: A convex polygon within which all
  swimmers are located. Section \ref{sec_ufrm_swim_files}.

\item \mvar{RESCUED\_SWIMMER}: A message. Section
  \ref{sec_ufrm_rescue}.

\item \mvar{SCOUTED\_SWIMMER\_ABE}: A message. Section
  \ref{sec_ufrm_scout}.

\item \mvar{SWIMMER\_ALERT\_ABE}: A message. Section
  \ref{sec_ufrm_swimmers}.

\item \mvar{VIEW\_MARKER}: A marker representing the swimmer
  location. Section \ref{sec_ufrm_visuals}.

\item \mvar{VIEW\_CIRCLE}: A marker for conveying the sensor range
  around each vehicle. Section \ref{sec_ufrm_visuals}.

\item \mvar{VIEW\_POLYGON}: A polygon conveying the region of
  operation. Section \ref{sec_ufrm_visuals}.

\item \mvar{UFRM\_WINNER}: A message conveying the winner of the
  competition. Section \ref{sec_ufrm_end_game}.

\item \mvar{UFRM\_LEADER}: A message conveying the current leader
  of the competition. Section \ref{sec_ufrm_game_state}.

\item \mvar{UFRM\_FINISHED}: A message conveying whether or not the
  mission has been finished. Section \ref{sec_ufrm_end_game}.

\end{packed_itemize}

%====================================================================
\subsection{Variables Subscribed for by uFldRescueMgr}
\label{sec_uhma_subs}

The \app{uFldRescueMgr} application will subscribe for the following
four MOOS variables:

\begin{packed_itemize}
\item \mvar{APPCAST\_REQ}: A request to generate and post a new
  apppcast report, with reporting criteria, and expiration.

\item \mvar{NODE\_REPORT}: Node reports are received for each vehicle
  in the mission, simulation or otherwise. They provide the name, type
  and location of the vehicle. They are published by
  \app{pNodeReporter} and are otherwise generally published by the
  vehicles and shared to the shoreside.

\item \mvar{RESCUE\_REQUEST}: Section \ref{sec_ufrm_rescue}.

\item \mvar{SCOUT\_REQUEST}: Section \ref{sec_ufrm_scout}.

\item \mvar{XSWIMMER\_ALERT}: This message enables the dynamic
  addition of a new swimmer, in mid-mission. Section
  \ref{sec_ufrm_xevent}.

\item \mvar{XFOUND\_SWIMMER}: This message simulates the rescue
  of a swimmer, mid-mission. Section \ref{sec_ufrm_xevent}.

\end{packed_itemize}

%====================================================================
\subsection*{Command Line Usage of uFldRescueMgr}
\label{sec_ufrm_cmdline}

The \app{uFldRescueMgr} application is typically launched as a part
of a batch of processes by pAntler, but may also be launched from the
command line by the user.  To see command-line options enter the
following from the command-line:

\vspace{0.1in}
\begin{consoleverb}
 $ uFldRescueMgr --help or -h
\end{consoleverb}
\vspace{0.1in}

\noindent
This will show the output shown in Listing \ref{lst_uhma_usage} below.

\vspace{0.1in}
\begin{listing}{Command line usage for \app{uFldRescueMgr}}
\label{lst_uhma_usage}
\footnotesize
\begin{verbatim}
  1  ==========================================================
  2  Usage: uFldRescueMgr file.moos [OPTIONS]               
  3  ==========================================================
  4                                                            
  5  Options:                                                  
  6    --alias=&lt;ProcessName&gt;                                
  7        Launch uFldRescueMgr with the given process name. 
  8    --example, -e                                           
  9        Display example MOOS configuration block.           
 10    --help, -h                                              
 11        Display this help message.                          
 12    --interface, -i                                         
 13        Display MOOS publications and subscriptions.        
 14    --version,-v                                            
 15        Display release version of uFldRescueMgr.        
\end{verbatim}
\end{listing}
\normalsize
 
%====================================================================
\section{Terminal and AppCast Output}
%====================================================================
\label{sec_ufrm_appcast}

The \app{uFldRescueMgr} application produces some useful information
to the terminal and identical content through appcasting. An example
is shown in Listing \ref{lst_ufrm_appcast} below.  On line 2, the name
of the app and the MOOS community  is listed on the left. On the
right, \var{"0/0(1414)} indicates there are no configuration or run
warnings, and the current iteration of \app{uFldRescueMgr} is 783.
Lines 4-12 convey the requested and prevailing rescue manager
configuration settings.

\vspace{0.1in}
\noindent
In lines 13-19, the high level status of the mission is shown: the
number of vehicles, leader (if any), and winner (if any). Lines 18 and
19 are often viewed as the defininitive indication of whether the
competition has been completed.

\vspace{0.1in}
\noindent
In lines 22-28, the stats {\em per vehicle} are shown. Since \var{abe}
and \var{ben} are rescue vehicles, the may have a non-zero values in
the \pvar{Swimmers Rescued} column. Likewise since \var{cal} and
\var{deb} are the sole two scout vehicles, they will have non-zero
totals for the \pvar{Scout Request} and \pvar{Scout Ties} columns and
the \pvar{Swimmers Scouted} column. A scout request is the receipt
of the \mvar{SCOUT\_REQUEST} message. Some of these may be rejected
by the rescue manager for arriving too soon after the previous request.
Those that are not rejects are considered to be a "try". 

\vspace{0.1in}
\begin{listing}{Example \app{uFldRescueMgr} console output}
\label{lst_ufrm_appcast}
\footnotesize
\begin{verbatim}
 1 ===================================================================
 2 uFldRescueMgr shoreside                                    0/0(783)
 3 ===================================================================
 4 ======================================
 5 RescueMgr Configuration 
 6 ======================================
 7 rescue_rng_min: 3
 8 rescue_rng_max: 5
 9 rescue_rng_pd:  1
10 rescue_rng_show: true
11 transparency:   0.10
12 swim_file:      mit_rand.txt
13 
14 ======================================
15 Vehicle Rescue Summary 
16 ======================================
17 Total vehicles: 4
18 Leader vehicle: ben
19 Winner vehicle: ben
20 Mission Finished: true (0 remaining)
21 
22 Vehi  Rescue  Rescue  Swimmers  Scout  Scout  Swimmers
23 Name  Reqs    Tries   Rescued   Reqs   Tries  Scouted
24 ----  ------  ------  --------  -----  -----  --------
25 abe   310     257     1         0      0      0
26 ben   309     257     8         0      0      0
27 cal   0       0       0         310    171    0
28 deb   0       0       0         310    171    3
29 
30 ======================================
31 Swimmer Summary 
32 ======================================
33 Name  ID    Type   Pos      State     Savior  Tries  Scouts  Time
34 ----  ----  -----  -------  --------  ------  -----  ------  -----
35 p01   id92  reg    48,-36   rescued   ben     1              0
36 p02   id45  reg    32,-24   rescued   abe     2              0
37 p03   id97  reg    34,-61   rescued   ben     2              0
38 p04   id08  reg    -14,-99  rescued   ben     1              0
39 p05   id62  reg    -1,-81   rescued   ben     2              0
40 x01   id48  unreg  -9,-23   swimming  -       0              441.7
41 x02   id43  unreg  43,-90   swimming  -       0              441.7
42 x03   id75  unreg  -12,-49  swimming  -       0              441.7
43 x04   id34  unreg  6,-20    rescued   ben     2      deb     0
44 x05   id25  unreg  53,-66   rescued   ben     1      deb     0
45 x06   id06  unreg  76,-39   rescued   ben     1      deb     0
46 x07   id28  unreg  -32,-78  swimming  -       0              441.7
47 x08   id63  unreg  87,-52   swimming  -       0              441.7
48 x09   id68  unreg  42,-77   rescued   ben     1              0
49   
50 ===================================================================
51 Most Recent Events (12):
52 ===================================================================
53 [296.18]: Swimmer x04 has been rescued by ben!
54 [236.07]: Swimmer x06 has been rescued by ben!
55 [206.02]: Swimmer x05 has been rescued by ben!
56 [195.69]: Swimmer x09 has been rescued by ben!
57 [184.17]: Swimmer x06 has been scouted by deb!
58 [146.00]: Swimmer p04 has been rescued by ben!
59 [135.56]: Swimmer x05 has been scouted by deb!
60 [129.74]: Swimmer p05 has been rescued by ben!
61 [96.23]: Swimmer p03 has been rescued by ben!
62 [72.01]: Swimmer p01 has been rescued by ben!
63 [56.89]: Swimmer p02 has been rescued by abe!
64 [43.55]: Swimmer x04 has been scouted by deb!
\end{verbatim}
\end{listing}
\normalsize

\vspace{0.1in}
\noindent
In lines 30-48, the stats {\em per swimmer} are shown. Recall that
registered swimmers have a name beginning with \var{'p'} and
unregistered with \var{'x'}.  the \pvar{ID} column shows the randomly
generated ID alias presented to the vehicles, to hide any hints about
the total number of unregistered swimmers. The \pvar{Type} column
shows the type. The \pvar{Pos} column shows the x-y position. The
\pvar{State} of a swimmer is either \var{swimming} or
\var{rescued}. If rescued, the vehicle that made the rescue is shown
in the \pvar{Savior} column. The \pvar{Tries} column shows how many
swimmer \mvar{RESCUE\_REQUEST} messages were needed before a rescue
was granted.  If an unregistered swimmer was scouted, it be shown in
the \pvar{Scouts} column. In this example unregistered swimmer
\var{x09} was rescued but not scouted. It can be inferred that the
rescue vehicle \var{ben} came across this swimmer by coincident. The
\pvar{Time} column indicates how long an unrescued swimmer has been
unrescued.

\vspace{0.1in}
\noindent
Finally, in lines 50-64, recent events of the rescue manager are
shown. These are typically successful rescues or scouts, showing the
swimmer name and the vehicle responsible.

%\noindent 
%  relationship of publishing rescue region and the
%  OpRegionV22 behavior of the helm


\end{document}

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