<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%===================================================================
\section{The Jake Kasper Baseline Mission}
%===================================================================
\wikisec{grp=xmiss}
\wikisec{file=HelmXMissJake,short=Example Jake}
\label{sec_xmiss_jake}

The {\em Jake Kasper} mission is distributed with the MOOS-IvP code
and was designed to highlight four things:

\begin{packed_itemize}
\item The \app{uFldHazardSensor} application,
\item The \app{uFldHazardMetric} application,
\item The \app{uFldHazardMgr} application, and 
\item How each of the above work together, in a straw-man solution to
  the hazard search challenge problem.
\end{packed_itemize}

\noindent
The example mission contains a default hazard field and a few other
hazard fields for testing.  Assuming the reader has downloaded the
source code available at \var{www.moos-ivp.org} and built the code
successfully, the {\em Jake Kasper Baseline} mission may be launched
by:

\vspace{0.2in} 
\begin{consoleverb}
 $ cd moos-ivp/ivp/missions-2680/lab_10_jake_kasper_baseline/
 $ ./launch.sh 12
\end{consoleverb}
\normalsize    
\vspace{0.2in} 

\noindent
The argument, 12, in the line above will launch the simulation in
\var{12x} real time.  Once this launches, \app{pMarineViewer} should
launch and the mission may be initiated by hitting the
\var{DEPLOY\_ALL} button. Shortly thereafter, two vehicles named
\var{jake} and \var{kasper} will begin simple lawnmower patterns, each
over half of the search region, as shown in the video in Figure
\ref{fig_jake_basic} below.

\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{Module Topology in the Jake Kasper Mission}
\label{sec_jake_topology}

The key components of the Jake Kasper mission are shown in Figure
\ref{fig_jake_topology} below. The \app{uFldHazardSensor} and
\app{uFldHazardMetric} apps run on the shoreside, the
\app{uFldHazardMgr} runs on the vehicle. The latter is a straw-man
implementation of a application to be implemented by individual
developers in the hazard search competition. All three applications
are described in detail in their own separate sections.

\pskip

A high-level description of operation is that
the vehicles (a) configure the hazard sensor, (b) process the sensor
information as they move through the field, and finally (c) generate
a hazardset report and send it back to the shoreside for evaluation.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.7\textwidth]{figures/xm_jake_topology.png}
  \caption{{\bf The Jake Kasper Baseline Mission Module Topology:} The three
    key modules of the Jake mission are \aapp{uFldHazardSensor},
    \aapp{uFldHazardMetric}, and \aapp{uFldHazardMgr}.}
\label{fig_jake_topology}
\end{figure}


%====================================================================
\subsection{Key MOOS Variables in the Jake Kasper Mission}
\label{sec_jake_moosvars}

To digest what is going on in this mission, familiarity with the key
MOOS variables published by each key modules is needed. We list these
here for reference in the following discussion. It's worth remembering
that this information is always available on the command-line, by
typing for example:

\begin{consoleverb}
 $ uFldHazardSensor --interface or -i
\end{consoleverb}

\noindent
The above also provides example values for the key variables, whereas below
just the variable names are listed.

%--------------------------------------------------------------------
\subsubsection*{uFldHazardSensor Interface}

\begin{packed_itemize}
\item Publications: \mvar{UHZ\_DETECTION\_REPORT},
  \mvar{UHZ\_HAZARD\_REPORT}, \mvar{UHZ\_CONFIG\_ACK},
  \mvar{UHZ\_OPTIONS\_SUMMARY}, \mvar{VIEW\_CIRCLE},
  \mvar{VIEW\_MARKER}, \mvar{VIEW\_POLYGON}.
\item Subscriptions: \mvar{NODE\_REPORT}, \mvar{UHZ\_SENSOR\_REQUEST},
  \mvar{UHZ\_CONFIG\_REQUEST},\mvar{UHZ\_CLASSIFY\_REQUEST}.
\end{packed_itemize}


%--------------------------------------------------------------------
\subsubsection*{uFldHazardMetric Interface}

\begin{packed_itemize}
\item Publications: \mvar{UHZ\_MISSION\_PARAMS}, \mvar{HAZARDSET\_EVAL}.
\item Subscriptions: \mvar{HAZARD\_SEARCH\_START}, \mvar{HAZARDSET\_REPORT}.
\end{packed_itemize}

%--------------------------------------------------------------------
\subsubsection*{uFldHazardMgr Interface}

This information, and example values for each variable, may be
obtained from the command-line by typing \var{uFldHazardMgr -i}.

\begin{packed_itemize}
\item Publications: \mvar{UHZ\_CONFIG\_REQUEST},
  \mvar{UHZ\_SENSOR\_REQUEST}, \mvar{HAZARDSET\_REPORT}.
\item Subscriptions: \mvar{HAZARDSET\_REQUEST}, \mvar{UHZ\_CONFIG\_ACK},
  \mvar{UHZ\_DETECTION\_REPORT}, \mvar{UHZ\_OPTIONS\_SUMMARY}.
\end{packed_itemize}


%========================================================================
\subsection{General Description of Events in the Jake Kasper Mission}
\label{sec_jake_events}

There are roughly three phases to the Jake Kasper example mission, (a)
initialization and startup, (b) search, and (c) reporting
results. These are described below with some reference to what
additional measures would be needed beyond the straw-man mission.

%------------------------------------------------------------------------
\subsubsection{Phase 1: Sensor Configuration and Handling of Mission Parameters}

For each vehicle, there are two steps in the initialization phase, (a)
initializing the hazard sensor, and (b) digesting the mission
parameters.

\subsubsection*{Sensor Configuration}

The hazard sensor initialization is done in three steps. First
\app{uFldHazardSensor} publishes the sensor options, with something
similar to:

\prevgreen
\begin{verbatim}
  UHZ_OPTIONS_SUMMARY = width=10,exp=6,class=0.91:width=25,exp=4,class=0.85:
                        width=50,exp=2,class=0.78    
\end{verbatim}
\postverb

\noindent
Once the vehicle knows the sensor options, it can pick one. In this
case the \app{uFldHazardMgr}, running on vehicle \var{jake} posts
something similar to:

\prevgreen
\begin{verbatim}
  UHZ_CONFIG_REQUEST = vname=jake,width=25,pd=0.9    
\end{verbatim}
\postverb

\noindent
Once the request has been received, \app{uFldHazardSensor}, will
either accept the requested swath width outright, or map it to the
closest legal option. After setting the value for $\pd$, it will
determine the $\pfa$ and $\pc$, and post a confirmation to the 
following variable:

\prevgreen
\begin{verbatim}
  UHZ_CONFIG_ACK = vname=jake,width=20,pd=0.9,pfa=0.53,pclass=0.91 
\end{verbatim}
\postverb

\noindent
Once this is done, the sensor is configured. In the Jake Kasper
mission, being a straw-man mission, some of the above steps are
over-simplified. In the Jake Kasper mission, \app{uFldHazardMgr} on
the vehicle does not handle the options summary and just blindly
requests a particular sensor setting. It also does not handle the
configuration acknowledgement. This may be something improved by a
user extending this mission.


\subsubsection*{Handling of Mission Parameters}

Upon startup, the mission parameters are published by \app{uFldHazardMetric}
on the shoreside and sent to each of the vehicles. The format of this message
may look something like:

\prevgreen
\begin{verbatim}
UHZ_MISSION_PARAMS = penalty_missed_hazard=100,               
             penalty_false_alarm=35,
             max_time=600, 
             penalty_max_time_over=200,                         
             penalty_max_time_rate=0.45,                        
             search_region = pts={-150,-75:-150,-50:40,-50:40,-75}
\end{verbatim}
\postverb

\noindent
The straw-man Jake Kasper mission however does not consume and react
to these mission parameters. The search mission pattern is hard-coded
and the penalties are disregarded, all detections are reported as
hazards. This will almost certainly need to be handled by users
wishing to improve on the baseline performance provided in the Jake
Kasper mission.


%------------------------------------------------------------------------
\subsubsection{Phase 2: Executing the Search Phase}

The activities during the search phase consist of two types of
messages originating in the vehicle, and two types of messages
originating in the hazard sensor back to the vehicle. Basic sensor
operation is turned on when the vehicle publishes the variable:

\prevgreen
\begin{verbatim}
  UHZ_SENSOR_REQUEST = vname=jake      
\end{verbatim}
\postverb

\noindent
In the Jake Kasper mission, the above message originates in
\app{uFldHazardMgr}.  This is received on the shoreside by
\app{uFldHazardSensor}. The hazard sensor regards the sensor to be on
if, for the named vehicle, it has received a sensor request
recently. If the sensor is on and the vehicle passes over an object
and produces a detection, then a detection report is posted by the
sensor and sent back to the vehicle:

\prevgreen
\begin{verbatim}
  UHZ_DETECTION_REPORT = x=51,y=11.3,label=12
\end{verbatim}
\postverb

\noindent
The vehicle may decide to request a classification report for a given 
detection and publish:

\prevgreen
\begin{verbatim}
  UHZ_CLASSIFY_REQUEST = vname=jake,label=12,priority=80
\end{verbatim}
\postverb

\noindent 
However, in the Jake Kasper mission, no classify requests are
generated. The vehicle simply interprets all detections to be hazards
and generates a report without using the classify capability of the
hazard sensor. This is another area where the user wishing to improve
on the baseline mission would focus their effort.  Classify requests
are eventually answered by the \app{uFldHazardSensor} publishing:

\prevgreen
\begin{verbatim}
  UHZ_HAZARD_REPORT = x=51,y=11.3,type=hazard,label=12 
\end{verbatim}
\postverb


%------------------------------------------------------------------------
\subsubsection{Phase 3: Reporting Results}

The final phase of the mission involves sending a report from the vehicle
to the shoreside, handled by \app{uFldHazardMetric}:

\prevgreen
\begin{verbatim}
  HAZARDSET_REPORT = source=jake#
                     x=-151,y=-217.3,label=01# 
                     x=-178.8,y=-234,label=15# 
                     x=-59.8,y=-294.1,label=13
\end{verbatim}
\postverb

\noindent
When is this report sent? In the Jake Kasper mission, this report is
sent simply after the vehicles have completed their lawnmower
pattern. Furthermore, in this mission, each vehicle sends their own
report; there is no coordination or communication. The
\app{uFldHazardMetric} evaluates a {\em single} latest report, so the
earlier report in the mission is simply dropped. This is another
obvious issue for improvement.

\pskip

After receiving and evaluating a report, the \app{uFldHazardMgr} publishes
the evaluation to the below variable, consisting partly of results, and partly
reiterating the criteria for evaluation:

\prevgreen
\begin{verbatim}
  HAZARDSET_EVAL  = vname=jake,                               
             report_name=jake_team,                            
             total_score=675,                                   
             norm_score=37.5,                                   
             score_missed_hazards=500,                          
             score_false_alarms=175,                            
             score_time_overage=0,                              
             total_objects=10,                                  
             total_time=1284.91,                                
             received_time=1314.05,                             
             start_time=29.14,                                  
             missed_hazards=5,                                  
             correct_hazards=5,                                 
             false_alarms=5,                                    
             penalty_false_alarm=35,                            
             penalty_missed_hazard=100,                         
             penalty_max_time_over=100,                         
             penalty_max_time_rate=0.05,                        
             max_time=1800                      
\end{verbatim}
\postverb

\noindent
In the Jake Kasper mission, the \app{uFldHazardMgr} also will publish
a hazardset report upon request when it receives incoming mail
\mvar{HAZARDSET\_REQUEST=true}. In this baseline mission, the
\app{pMarineViewer} GUI is configured to generate this request with
one of the custom action buttons.

%========================================================================
\subsection{Required MOOS Variable Bridges}
\label{sec_jake_shares}

The Jake Kasper mission requires MOOS variables to be be shared
between the vehicle and shoreside community depicted in Figure
\ref{fig_jake_topology}.  The variables of key processes were
described above in Section \ref{sec_jake_moosvars} and Section
\ref{sec_jake_events}. The sharing (also referred to as bridging)
between MOOS communities is done with the \app{pShare} MOOS app
distributed with MOOS. Configuration involves specifying which
variables are to be sent to which other machine (IP address) along
with the port where the other \app{MOOSDB} resides. This is configured
on the shoreside for variables shared {\em from} the shoreside {\em
  to} the vehicles. A similar configuration exists on the vehicles for
variables going in the other direction.

%-----------------------------------------------------------------------
\subsubsection{Variable Bridges from the Shoreside to the Vehicle}

Many of the variables shared from the shoreside to the vehicle were
discussed in the previously in Section \ref{sec_jake_moosvars} and
Section \ref{sec_jake_events}. The variable share configuration is
handled on the shoreside with the \app{uFldShoreBroker}
application. Below is the configuration used in the Jake Kasper
mission:

\vspace{0.1in}
\footnotesize
\begin{Verbatim}[frame=single]
ProcessConfig = uFldShoreBroker
{
  AppTick       = 1
  CommsTick     = 1

  // Note: [qbridge = FOO]  is shorthand for
  //       [bridge = src=FOO_$V,  alias=FOO] and
  //       [bridge = src=FOO_ALL, alias=FOO]

  qbridge  = DEPLOY, RETURN, NODE_REPORT, NODE_MESSAGE
  qbridge  = MOOS_MANUAL_OVERRIDE

  bridge   = src=APPCAST_REQ
  bridge   = src=UHZ_MISSION_PARAMS
  bridge   = src=UHZ_OPTIONS_SUMMARY

  bridge   = src=UHZ_CONFIG_ACK_$V,       alias=UHZ_CONFIG_ACK
  bridge   = src=UHZ_HAZARD_REPORT_$V,    alias=UHZ_HAZARD_REPORT
  bridge   = src=UHZ_DETECTION_REPORT_$V, alias=UHZ_DETECTION_REPORT
  bridge   = src=HAZARDSET_REQUEST_ALL,   alias=HAZARDSET_REQUEST
}
\end{Verbatim}
\normalsize
\vspace{0.1in}

In addition to the sensor variables discussed previously, certain
basic mission variables, e.g., \mvar{DEPLOY}, \mvar{RETURN} are shared
to allow for basic command-and-control of the vehicles.  More on
\app{uFldShoreBroker} application can be found in the documentation
for that application. In short, the application allows for
configurable automatic point-to-point sharing of information as
vehicles become known.

%-----------------------------------------------------------------------
\subsubsection{Variable Bridges from the Vehicle to the Shoreside}

Most of the variables shared from the vehicle to the shoreside were
discussed in the previous secions, \ref{sec_jake_moosvars} and
\ref{sec_jake_events}. The variable share configuration, for variables
sent fom the vehicle to the shoreside, is handled on vehicle with the
\app{uFldNodeBroker} application. Below is the configuration used in the 
Jake Kasper mission:

\vspace{0.1in}
\footnotesize
\begin{Verbatim}[frame=single]
ProcessConfig = uFldNodeBroker
{
  AppTick   = 1
  CommsTick = 1

  TRY_SHORE_HOST = pshare_route=multicast_9

  BRIDGE = src=VIEW_POLYGON
  BRIDGE = src=VIEW_POINT
  BRIDGE = src=VIEW_SEGLIST
  BRIDGE = src=APPCAST
  BRIDGE = src=UHZ_CLASSIFY_REQUEST
  BRIDGE = src=UHZ_SENSOR_REQUEST
  BRIDGE = src=UHZ_CONFIG_REQUEST
  BRIDGE = src=HAZARDSET_REPORT
  BRIDGE = src=NODE_REPORT_LOCAL,  alias=NODE_REPORT
  BRIDGE = src=NODE_MESSAGE_LOCAL, alias=NODE_MESSAGE
}
\end{Verbatim}
\normalsize
\vspace{0.1in}

In addition to the sensor variables discussed previously, a few
geometry variables, e.g., \mvar{VIEW\_POLYGON}, are shared to the shore for
rendering thing such as the vehicle search path or search region in the
shoreside display.  More on the \app{uFldNodeBroker} application can
be found in the documentation for that application. In short, the
application allows for configurable autonomatic point-to-point sharing
of information as the location of the shoreside is discovered, without
requiring changes to the misison files if the shoreside location,
i.e., IP address, changes.

%========================================================================
\subsection{Hazard Files in the Jake Kasper Mission}

There are several example hazard files included in the Jake Kasper
mission. The default file used is \var{hazards.txt}, but there
are additionally four other files:

\begin{packed_itemize}
\item \var{hazards\_01.txt}
\item \var{hazards\_02.txt}
\item \var{hazards\_03.txt}
\item \var{hazards\_04.txt}
\end{packed_itemize}

They vary in (a) number of benign objects, (b) number of hazards, and
(c) hazard resemblance of the benign objects. Each of these files was
created with the \app{gen\_hazards} utility distributed with
moos-ivp. The first line of each file contains a comment, a line
showing exactly the command-line invocation of \app{gen\_hazards} used
in making the file. You are welcome to create your own to test
situations beyond those in the handful of files included in this
mission.

\pskip

To launch the mission with a different hazard file, the \var{--hazards} 
command-line switch is supported with the provided launch script. For
example:

\begin{consoleverb}
 $ ./launch.sh --hazards=hazards_03.txt 10
\end{consoleverb}

\noindent
As before, the 10 on the command-line specifies the time warp
and individual machines may vary in the magnitude of time warp
supported, correlated to the machines raw computing capacity.



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