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

\index{Berta Example Mission}
\index{Example Missions!Mission M2: The Berta Mission}
\label{exmissions_m2}

The Berta mission involves two vehicles repeatedly performing
collision avoidance with one another. The primary capabilities 
highlighted are the helm's collision avoidance behavior, the basic
contact manager, \app{pBasicContactMgr}, and the dynamic spawning
and removal of behaviors related to contacts from the helm.

%====================================================================
\subsection{Overview of the Berta Mission Components and Topics}

\vspace{0.05in}
\noindent
Here is a bit of what the Berta mission should look like:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figs_exam/Berta.png}
  \caption{The Berta mission.}
  \label{fig_berta}
  \urlvideo{https://vimeo.com/84492574}{0:43}
\end{figure}

\vspace{0.1in}

\footnotesize
\begin{longtable}{|r|p{0.78\textwidth}|} \hline 

  \bsvar{Behaviors:} &amp; Loiter, AvoidCollision \\ \hline
  
  \bsvar{Vehicles:} &amp; {\em henry} and {\em gilda} \\ \hline

  \bsvar{MOOS Apps:} &amp; \app{pHelmIvP}, \app{pLogger},
  \app{uSimMarine}, \app{pBasicContactMgr}, \app{pMarinePID},
  \app{pNodeReporter}, \app{pMarineViewer}, \app{uTimerScript},
  \app{pShare} \\ \hline
  
  \bsvar{Primary Topics:} &amp;
  (1) The IvP Helm AvoidCollision behavior / Dynamic behavior spawning. \newline
  (2) Contact management with the \app{pBasicContactMgr} application. \\ \hline


  \bsvar{Side Topics:} &amp;
  (1) \app{uTimerScript} is used in a command and control role for random 
           permuting of vehicle loiter assignments. \newline
  (2) \app{pShare} is used for connecting one shoreside command and control
           community to two simulated vehicle communities. \newline
  (3) The Loiter behavior is configured to receive dynamic updates
           on its loiter position. \\ \hline

\end{longtable}
\normalsize

%==================================================================
\subsection{Launching the Berta Mission}

The {\em Berta} mission may be launched from the command line:

\vspace{0.15in}
\noindent
\begin{consoleverb}
 $ cd moos-ivp/missions/m2_berta/
 $ ./launch.sh --warp=10
\end{consoleverb}
\vspace{0.15in}


\index{IvP Behaviors Implemented!\var{BHV\_AvoidCollision}}
\index{IvP Behaviors Implemented!\var{BHV\_Loiter}}

\noindent
This should bring up a \app{pMarineViewer} window like that shown in
Figure \ref{fig_berta_one}, with two vehicles, {\em henry} and
{\em gilda}, each initially in the \var{"PARK"} state. After hitting
the \var{DEPLOY} button in the lower right corner, the vehicle enters
the \var{"LOITERING"} mode and begins to proceed along the loiter
pattern as shown. The example mission is configured to periodically
alter the position of each vehicle's loiter pattern, alternating
between a random point in Region-A and Region-B shown in Figure
\ref{fig_berta_one}. The user may click the \var{PERMUTE-NOW} button
to immediately cause a new permutation and command sent to the
vehicle, which otherwise happens automatically every three minutes.

%=====================================================================
\subsection{Topic \#1: The AvoidCollision Behavior and Dynamic Behavior Spawning}

The AvoidCollision behavior runs on both vehicles and is configured
identically on each vehicle in this mission. Its configuration is
shown in Listing \ref{lst_berta_one}. When the helm first launches on
each vehicle this behavior is not present. It is configured to be a
dynamically spawned behavior - one for each known contact within a
certain range of the vehicle. In this regard it depends on alerts from
a contact manager running separately on each vehicle that posts the
MOOS variable \mvar{CONTACT\_INFO}, with the name of the new contact
for which to spawn a new behavior. 

\pskip

The \mvar{CONTACT\_INFO} variable is the variable for which the
behavior is configured to receive dynamic updates, on line 6. The
behavior is configured to allow dynamic instantiations on line 8 with
\bvar{templating = spawn}. The choice of \bvar{spawn} (vs. \bvar{clone})
means that a behavior of this configuration is not initially present
unless cued via the \bvar{updates} interface. See the discussion on
dynamic behavior spawning in Section \ref{sec_bhv_templates}.

\index{Dynamic Behavior Spawning}

\vspace{0.1in}
\begin{listing}{Configuration of the AvoidCollision behavior in the Berta example mission}
\label{lst_berta_one}
\footnotesize
\begin{verbatim}
  1  Behavior = BHV_AvoidCollision
  2  {
  3    name       = avd_collision
  4    pwt        = 200
  5    condition  = AVOID=true
  6    updates    = CONTACT_INFO
  7    endflag    = CONTACT_RESOLVED = $[CONTACT]
  8    templating = spawn
  9 
 10                contact = to-be-set
 11       on_no_contact_ok = true
 12            extrapolate = true
 13                  decay = 30,60
 14    
 15         pwt_outer_dist = 50
 16         pwt_inner_dist = 20
 17              pwt_grade = linear
 18         completed_dist = 75
 19      min_util_cpa_dist = 8
 20      max_util_cpa_dist = 25
 21    bearing_line_config = white:0, green:0.65, yellow:0.8, red:1.0
 22  }
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.1in}

The parameters in lines 15-17 determine the level of activity of the
behavior based on the range to the contact. The parameters in lines
15 and 16 refer to the priority weight of the behavior. Beyond 50 meters
in range, the weight will be 0\% of its static weight of 200 assigned
on line 4. (A weight of zero means that no objective function will be
produced and the behavior is in the running state, but not the active
state.) At 20 meters range, it will be at 100\% of its static
priority weight. The grade in priority between outer and inner
distances is linear, due to the setting on line 17. The
\bvar{min\_util\_cpa\_dist}, and \bvar{max\_util\_cpa\_dist} on lines
19 and 20 refer to the utilities assigned to candidate maneuvers in
the objective function output by the behavior. Any candidate maneuver
whose CPA is less than 8 meters will be given the lowest utility
rating, equivalent to an actual collision. Likewise, any candidate
maneuver whose CPA is greater than 25 will be given the highest
utility rating, equivalent to missing the contact by infinite
distance.

\pskip 

The \bvar{completed\_dist}, on line 18, refers to the range to the
contact beyond which the behavior will declare itself to be complete.
Once completed, the behavior will post its end flags (none in this
case), and will remove itself from the helm. In this regard, some
coordination with the contact manager is needed. At the very least,
the contact manager must be configured to post alerts to the mutually
configured MOOS variable, \mvar{CONTACT\_INFO}, on line 6 in Listing
\ref{lst_berta_one} and on line 16 in Listing \ref{lst_berta_two}.
Note also that the \bvar{completed\_dist} is set to 75 meters,
which is higher than the 55 meters set for the \bvar{alert\_range}
in the contact manager. This means that, after the avoid collision
behavior dies, the contact must come back within 55 meters before
the contact manager generates another alert, triggering the helm to
once again spawn a behavior for the contact. 

\pskip

Once a contact has gone out of range to the point where the
AvoidCollision behavior dies, it typically never returns, in practice.
There is no guarantee of this however, since the future maneuvers of
either the contact or ownship may once again put them on a collision
course. The Berta mission tests this scenario repeatedly. The two
vehicles are configured to loiter in a loiter pattern that keeps them
out range from each other in terms of triggering an AvoidCollision
behavior in each of their helms (as in Figure \ref{fig_berta_one}).
In this mission, a \app{uTimerScript} script is running in the
shoreside community that periodically picks a new loiter location
within one of the two regions shown in Figure \ref{fig_berta_one}.  It
picks a new location once every three minutes, alternating between the
two regions for each vehicle each time. This ensures that there will
be a reasonably unpredictable collision avoidance situation each time
the vehicles transit to their new loiter locations. The permutations
happen automatically once every three minutes, but the user may jump
to the next permutation by clicking on the \var{PERMUTE-NOW} button.

\pskip

In Figure \ref{fig_berta_two}, note the line segment rendered between
the two vehicles. This line segment is posted to the MOOSDB by the IvP
Helm on behalf of the AvoidCollision behavior. A white line is drawn
between the two vehicles as soon as the AvoidCollision behavior is
spawned.  The line turns a non-white color as soon as the behavior
begins to generate an objective function, thus actively influencing
the helm to prefer maneuvers with a lower expected CPA. The line is
initially green to indicate a lower behavior priority. As the priority
grows, the line turns yellow and finally red when it is at the higher
priorities. The behavior posting of these line segments is optional
and configurable. The configuration on line 21 in Listing
\ref{lst_berta_one} is responsible for the postings in this mission.

\pskip

In this example, the \bvar{extrapolate} option is turned on for the
AvoidCollision behavior (line 12 in Listing \ref{lst_berta_one}).
Extrapolation is typically enabled when long durations are experienced
between updates on contact position (which is not the case here in
simulation). The behavior will automatically use the linear
extrapolated position given the contact's last known position,
trajectory and time-stamp. The linear extrapolation will decay down to
a zero speed (stationary solution) beginning at 30 seconds and coming
to a complete stop at 60 seconds, due to the decay specification on
line 13 of Listing \ref{lst_berta_one}. 

%==================================================================
\subsection{Topic \#2: Contact Management with pBasicContactMgr}
\index{Contact Management}

In the Berta mission, the \app{pBasicContactMgr} is running on both
simulated vehicles, configured identically with the configuration
block shown in Listing \ref{lst_berta_two}. Both the contact manager
and the helm are receiving \mvar{NODE\_REPORT} messages containing
information about contacts. The helm stores this information in its
information buffer for any behavior that requests it during normal
operation. The contact manager uses contact information to generate
alerts, which potentially cues the helm to spawn new contact-related
behaviors.

\pskip

The contact manager may be configured to generate more than one alert.
However, in the Berta mission, a single alert, on line 15 in Listing
\ref{lst_berta_two} is sufficient for spawning collision avoidance
behaviors. Note the alert specifies a variable name, and variable
value. The variable name, (\mvar{CONTACT\_INFO}), is set to be the
variable used for updates in the AvoidCollision behavior, on line 6 in
Listing \ref{lst_berta_one}. The variable value is configured to be
\#-separated list of parameter-value pairs suitable as input to any
behavior receiving updates. (See Section \ref{sec_updates} on behavior
updates.) In this case, the alert is configured to "update" the
AvoidCollision behavior parameters \bvar{name}, and \bvar{contact}.
Both parameter values are comprised, in part, of the name of the
contact, \var{\$[VNAME]}. In the case of the behavior name, this is to
ensure that the behavior name is unique, a condition for spawning a
new behavior. It also ensures that multiple AvoidCollision behaviors
will not be spawned for the same contact. In the case of the contact
name, the behavior simply must know the name of the contact for which
it avoiding a collision.

\pskip

In the unlikely event that two distinct contacts are present in the
field, and reporting the same vehicle name, it would be up to the
contact manager to discern that these are indeed two contacts and not
one. Currently this is beyond the algorithms implemented in
\app{pBasicContactMgr}.


\vspace{0.2in}
\begin{listing}{Configuration of the \app{pBasicContactMgr} application in the Berta example mission}
\label{lst_berta_two}
\footnotesize
\begin{verbatim}
  1  // pBasicContactMgr MOOS Configuration Block
  2  
  3  ProcessConfig = pBasicContactMgr
  4  {
  5    AppTick   = 2
  6    CommsTick = 2
  7  
  8    alert_range     = 55
  9    alert_cpa_range = 70
 10    alert_cpa_time  = 30
 11    contact_max_age = 3600
 12    display_raddii  = false
 13    verbose         = true
 14
 15    alert = var=CONTACT_INFO, val="name=avd_$[VNAME] # contact=$[VNAME]"
 16  }
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.1in}

In the Berta example mission, the contact manager is configured to
generate alerts when a known contact comes within 55 meters of the
vehicle (line 8 of Listing \ref{lst_berta_two}). The contact manager
also is configured to generate alerts when a contact comes within 70
meters (line 9) {\em and} its calculated CPA over next 30 seconds
(line 10) falls within the alert range (again line 8). See the
\app{pBasicContactMgr} documentation, \cite{url_pbcm}, for more on the
relationship between these two ranges.

\pskip

The contact manager is capable of optionally posting to the MOOSDB two
circles rendering the two ranges, the \bvar{alert\_range} and
\bvar{alert\_cpa\_range}. The rendering is turned off and on with the
setting on line 12. The circles are posted under the variable
\mvar{VIEW\_POLYGON} in the local MOOSDBs on each vehicle, and each
vehicle is configured to bridge this variable (via \app{pShare})
to the shoreside community running the \app{pMarineViewer}.

%========================================================================
\subsection{Suggestions for Tinkering in the Berta Mission}

\begin{itemize}
\item Alter the alert ranges in the contact manager, and enable the
displaying of range radii (line 8 in Listing \ref{lst_berta_two}) and notice
when the AvoidCollision behavior is spawned, by the presence of the bearing
lines between the two contacts.

\item Alter the \bsvar{pwt\_*\_dist} parameters in the AvoidCollision
behavior (lines 15-16 in Listing \ref{lst_berta_one}) and check how this 
affects the ranges between the vehicles as they avoid collisions.
\end{itemize}

\newpage
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.935\textwidth]{figs_exam/berta_one.png}
  \caption{{\bf The Berta Mission (1):} The two vehicles,
    {\em henry} and {\em gilda}, initially transit to their
    respective loiter stations and await further random location
    changes between the shown boxes.}
\label{fig_berta_one}
\end{figure}

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.935\textwidth]{figs_exam/berta_two.png}
  \caption{{\bf The Berta Mission (2):} The vehicles have changed
    their loiter stations and this puts them at risk for
    collision. The green bearing line between the vehicle indicates
    the presence of the AvoidCollision behavior.}
\label{fig_berta_two}
\end{figure}


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