<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\section{The Muster Behavior}
%=====================================================================
\label{sec_bhv_convoy}

This behavior will drive the vehicle to a specified region, the {\em
  muster region}, given by a convex polygon. Upon arrival, it will use
position information about local contacts also in the region, to
adjust its own position based on a variation of Llyod's
algorithm. This algororithm is based on a Voronoi decomposition of the
muster region as shown below.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/bhv_muster_general.png}
  \caption{{\bf Four-vehicle Muster} Four vehicles approach a muster region.
    As each vehicle enters the region the Voronoi decomposition is shown.
    When the first vehicle enters, there is only one region. When the second
    vehicle enters, there are two regions, and so on. Upon each new vehicle,
    the local regions for each vehicle may change. The change in local region
    shape affects the set point toward which the vehicle is driving toward.}
  \label{fig_bhv_muster_general}
\gif{figures/muster_clip.gif}
\end{figure}
\vspace{0.1in}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.6\textwidth]{figures/bhv_muster_enter.png}
  \caption{{\bf Evolving Set Point:} (Left) As the a vehicle transits
    to the muster region, its set point is the center of the
    region. Other vehicles may already reside in the muster
    region. Their set points are the center of their Voronoi
    cells. (Right) As the vehicle enters the region, the Voronoi
    partition changes for both the entering vehicle and the vehicles
    previously in the region. The set point for each vehicle is the
    center of its cell. Vehicles that were previously at their set
    point may need to move to reaquire their set point, depending on
    the capture and activate thresholds given in the behavior
    configuration parameters.}
  \label{fig_bhv_muster_enter}
\end{figure}
\vspace{0.1in}

\noindent
Note that the arrival of the new vessel in the region will immediately
alter the overall partition and shape of cells for the vehicles that
were already in the region. And as the new vessel traverses to its
initial set point, the partition will evolve and its own and other set
points will also move.

\vspace{0.1in}
\noindent
A vehicle that had previously achieved its set point and ceased motion,
may begin to move again if its set point has moved sufficiently far
away from its present position. As mentioned in the previous section,
motion will not resume from a captured state, until the distance between
the vehicle and the set point becomes larger than the activate radius. 



\noindent
The Muster behavior may be preferred when the mission requires some
number of vehicles to proceed to a region to gather and wait (muster),
until some next phase of the mission is to begin. Although each
vehicle is typically also running a collision avoidance behavior, a
goal of the muster behavior is to move the vehicles in a manner that
achieves a degree of vehicle separation perhaps obviating the need for
the collision avoidance behavior. A further goal of the muster
behavior is that no prior location assignments are required, and the
behavior works with any number of other vehicles needing only periodic
position information from its neighbors.


%=====================================================================
\section{The OnRunState() Loop}
\label{sec_bhv_muster_runstate}

The \var{onRunState()} function is executed by the behavior on each
iteration of the helm when the behavior is not idle. In this section
the key steps of this function are reviewed. Details of certain steps
will be discussed in separate sections.

\vspace{0.1in}
\noindent
As the step 1, the behavior obtains the current positions of ownship
and all contacts also in the muster region. This set of positions is
denoted by $V$:

\vspace{0.15in}
\noindent
$V = \{x_{os}, y_{os}, \;\; x_{cn1}, y_{cn1}, \ldots, \;\; x_{cnn}, y_{cnn}\} $

\vspace{0.15in}
\noindent
The vehicle position and the muster region, given as a configuration
parameter, are sufficient for creating the Voronoi partition discussed
in step 2. The Voronoi partition, $P$, is comprised of the union of
non-overlapping Voronoi cells, for ownship and $n$ contacts in the
muster region:

\vspace{0.15in}
\noindent
$P = \{P_{os}, P_{1}, \ldots P_{n}\} $

\vspace{0.15in}
\noindent
Given the full partition, $P$, in step 3 the set point $x_{sp},
y_{sp}$ is obtained from the Voronoi cell for ownship, $P_{os}$, as
described in Section \ref{sec_bhv_muster_setpt}. Given the set point,
the muster mode is determined in step 4, based own ownship position
relative to the setpoint, and the most recent mode setting, described
in Section \ref{sec_bhv_muster_modes}.

\vspace{0.1in}
\begin{figure}[ht]
  \centering 
  \includegraphics[width=0.65\textwidth]{figures/bhv_muster_flowchart.png}
  \caption{{\bf Muster Behavior Loop Flow Chart:} Each iteration of
    the Muster behavior will proceed through the steps shown, with
    branching determined by sensed events and the behavior
    configuration. Details of each step are discuss in their own
    sections as indicated.}
  \label{fig_bhv_muster_flowchart}
\end{figure}
\vspace{0.1in}

\noindent
In step 5, if the muster mode is determined to be newly set to
\var{"captured"}, the behavior will publish any capture flags
configured for this mission, as described in Section
\ref{sec_bhv_muster_capflags}.

\vspace{0.1in}
\noindent
In step 7, the behavior configuration parameter,
\bvar{auto\_complete}, is examined. This parameter is described in
Section \ref{sec_bhv_muster_autocomp}, and is used in situations when
ownship may take a configured action when or if all collaborating
vehicles have obtained the captured state in the muster region. If
\bvar{auto\_complete} is true, in step 8, the behavior will share its
current mode with all other collaborating vehicles. This message and
the means for sharing are described in Section
\ref{sec_bhv_muster_modeshare}.  In step 9, the behavior will examine
the current modes of all other vehicles. If ownship and all vehicles
are in the \var{"captured"} state, then the ownship Muster behavior
will complete. The completed behavior will post its end flags in step
10, and the behavior will not produce an objective function, instead
returning null.

\vspace{0.1in}
\noindent
If the behavior does not have \bvar{auto\_complete} enabled, or if not
all members in the group are in the \var{"capture"} mode, in step 11
the ownship muster mode is examined. If the mode is holding or
capture, the Muster behavior will not produce an objective function,
returning null. If the mode is either transiting or activated, an
objective function will need to be produced. In step 12, the set point
heading angle, $\theta_{sp}$, is calculated as the relative bearing
from the current ownship position to the set point. In step 13, an
objective function will be created and returned, using the set point
heading angle, as described in Section \ref{sec_bhv_muster_ipf}.


%=====================================================================
\subsection*{The OnRunState() Behavior Loop Pseudocode}
\label{sec_bhv_muster_runstate}

The \var{onRunState()} flowchart in Figure \ref{fig_bhv_muster_flowchart}
is represented in pseudocode in the algorithm below.

\vspace{0.1in}
\begin{twalgorithm}{Muster Behavior Main Loop}{alg_must_onrun}
  \input{alg_must_onrun}
\end{twalgorithm}



%=====================================================================
\section{Generating the Voronoi Partition and Set Point}

The Muster behavior uses the Voronoi partion of a muster region based
on ownship position and the positions of other collaborating vehicles
in the muster region.  Motion of the vehicle is based on a policy of
movement relative to the partition. The Voronoi partition is described below
in Section \ref{sec_bhv_muster_voronoi}. The motion policy is described
in Section \ref{sec_bhv_muster_motion}, and the set point policy is
described in Section \ref{sec_bhv_muster_setpt}.


%=====================================================================
\subsection{Obtaining Vehicle Positions}
\label{sec_bhv_muster_positions}

In step one of the behavior run-loop the position of ownship and all
collaborating vehicles is obtained. Ownship position is found in the
current navigation solution in the variables \mvar{NAV\_X} and
\mvar{NAV\_Y}. Positions for other vehicles are found in the variable
\mvar{NODE\_REPORT} which contains the contact name and position among
other fields.  On each iteration, the behavior processes all new
updates for these three variables.

\vspace{0.1in}
\noindent
The Muster behavior maintains a data structure, \var{VoronoiField},
which holds (a) the muster region polygon and (b) a mapping from
vehicle name to a position in the X-Y plane. The position of ownship
is always updated. If a contact is determined to be within the muster
polygon, it is updated. Otherwise it is removed from the
\var{VoronoiField} data structure. 

Limitation: stale contacts, group names

%=====================================================================
\subsection{Voronoi Partitions}
\label{sec_bhv_muster_voronoi}

In step 2 of the behavior run-loop the Muster behavior uses the notion
of a {\em Voronoi Partition}, as shown in Figure
\ref{fig_bhv_muster_voronoi_basic}. While a Voronoi partition can be
applied in unbounded space in any dimension, in our case the partition
will always be defined in the local X-Y plane, and always be bounded
by a given convex polygon region.

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.4\textwidth]{figures/bhv_muster_voronoi_basic.png}
  \caption{{\bf Voronoi Partition:} Vehicle positions in the muster
    region form a Voronoi partition over the region. As the vehicles move,
    or exit and enter the region, the partition evolves correspondingly.}
  \label{fig_bhv_muster_voronoi_basic}
\end{figure}
\vspace{0.1in}

\noindent
In this step the behavior uses the \var{VornoiField} data structure
created in step 1 and populated with ownship and contact positions.
The Voronoi partition algorithm is a member function defined on this
structure and will produce a partition on demand. 
For each cell of the partition, an inner wall is determined by a line
in space where all points on the line are equi-distant between the two
vehicles on either side of the line. The muster region polygon will be
be denoted at $P$. The convex polygon comprising the local cell
for vehicle $i$ will be denoted as $P_i$.  The Voronoi cell for
ownship is denoted as $P_{os}$. The area of a local cell will be
denoted as $A(P_i)$

\vspace{0.1in}
\noindent
A few additional points: (a) The area of each cell may be far from
equal across cells, (b) A local cell can be calculated for ownship
with local information of neighboring vessels only, (c) The vehicle
locations determine the partition. However, the Voronoi partition can
used to guide vehicle motion by setting a policy of where a vehicle
should move with respect to its own current cell and position within
the cell. This is discussed next. 

%=====================================================================
\subsection{The Set Point and Muster Mode}
\label{sec_bhv_muster_setpt}

In step 3 of the run-loop, the Muster behavior calculates a {\em set
  point}, $(x_{sp}$, $y_{sp})$. This is a point in the X-Y plane toward
which the behavior will prefer to move. By default the set
point is the center of the orthogonal convex hull of its Voronoi cell
as shown in Figure \ref{fig_bhv_muster_setpt}. When the vehicle is
completely outside the muster region, the set point is the center of
the muster region.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.7\textwidth]{figures/bhv_muster_setpt.png}
  \caption{{\bf Muster Set Point:} The set point for a vehicle is
    typically the center of the Voronoi cell for the vehicle, as shown
    on the left, where the center is the median x-y value of the
    orthogonal convex hull. The set point policy could also be the
    centroid of the cell, or a hybrid of the two policies as shown on
    the right. }
  \label{fig_bhv_muster_setpt}
\end{figure}
\vspace{0.1in}

\noindent
Alternative set point methods include \var{centroid} and \var{hybrid}.
In the hybrid mode, the set point is the mid point between the center
and centroid points. This parameter is set with configuration parameter:

\vspace{0.1in}
\noindent
\bvar{setpt\_method = center}

\vspace{0.1in}
\noindent
Other experimental set point methods are discussed in Section \ref{sec_bhv_muster_setptx}.

%=====================================================================
\section{Muster Modes and Capture Flags}
%=====================================================================
\label{sec_bhv_muster_modescap}

The {\em muster mode} is a key distinction that determines the operation
of the behavior on each iteration of the run-loop. It determines the output
of the behavior in terms of the objective function, and the output in terms
of posted flags. 

%=====================================================================
\subsection{Muster Modes and Configured Criteria}
\label{sec_bhv_muster_modes}


In step 4 of the behavior run-loop, the behavior determines its
current {\em muster mode}. The current muster mode depends on three
state variables, (a) ownship postion, $(x_{os}$, $y{_os})$, (b) the set
point, $(x_{sp}$, $y_{sp})$, and (c) the muster mode from the previous
iteration. It also depends on three configuration parameters, the
\bvar{muster\_region}, the \bvar{capture\_radius}, and the
\bvar{activate\_radius}.

\vspace{0.1in}
\noindent
\noindent
The Muster behavior will have one of five modes. When the behavior is
idle, the mode is simply {\em off}. When it is not idle, and is
outside the muster region, the mode is {\em transiting}. Once inside
the muster region, before it has reached the capture radius, the mode
is {\em activated}. When it reaches the set point capture radius, the
mode changes to {\em captured}. If the vehicle then slips beyond the
capture radius, but is still within the active radius, the mode is
{\em holding}. In the captured and holding modes, the Muster behavior
will not produce an objective function, as discussed in Section
\ref{sec_bhv_muster_makeipf}. This is shown in Figure
\ref{fig_bhv_muster_modes_params}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.6\textwidth]{figures/bhv_muster_modes_params.png}
  \caption{{\bf Muster parameters and modes:} The vehicle is {\em
      transiting} to a given {\em muster region}. Once inside the
    region we say the behavior is {\em activated} as drives toward the
    center of the region. When it is within the {\em capture radius},
    the mode becomes {\em captured}. When or if the vehicle opens
    range beyond the capture radius, but still within the {\em
      activate radius}, we say the vehicle is the the {\em holding
      state}.}
  \label{fig_bhv_muster_modes_params}
\end{figure}
\vspace{0.1in}

\noindent
The use of the activate radius is to allow the vehicle to proceed
nearly all the way to the set point. As discussed in Section
\ref{sec_bhv_muster_makeipf}, the behavior will cease to produce an
objective function once it has reached its capture radius. Unless
there are other behaviors running, this normally means that the
vehicle stops in the water. However, the Voronoi partition, and thus
the set point can be quite fluid if the neighboring vehicles are
moving. To limit trivial starting and stopping, the activate radius
is an additional threshold, to avoid resuming motion when the vehicle
distance to the set point becomes higher than the capture radius.

%=====================================================================
\subsection{Muster Capture Flags}
\label{sec_bhv_muster_capflags}

Each time the Muster behavior transitions into the {\em captured} mode,
a set of capture flags may be posted. These flags are similar to general
behavior flags such as end flags. They are set with the configuration
parameter:

\vspace{0.1in}
\noindent
\bvar{capture\_flag = variable=value}

\vspace{0.1in}
\noindent
where the variable is any MOOS variable and the value is any string or
numerical value. Any number of capture flags, including zero, may be
configured.

\vspace{0.1in}
\noindent
The behavior supports a few macros specific to the Muster behavior, that
may be useful in conjuction with the capture flag. The \var{REGION} macro
will expand to the name of the muster region. The \var{ODO\_ACTIVE} macro
will expand to the total odometry distance while this behavior has been
in the activated state.


%=====================================================================
\section{Auto Completion}

The motivation for creating the Muster behavior was to coordinate
mustering with other vehicles, and keep them safely separated in the
region. The behavior as described so far is capable of doing this
so long as it knows the positions of the other vehicles. Sometimes
we will say that ownship has {\em arrived} when it enters the region and
reaches its set point. Sometimes it is useful to know that all other
vehicles have also arrived, perhaps transitioning into some other
activity when they have all arrived. This is the purpose of the
optional {\em auto completion} feature. 

%=====================================================================
\subsection{Enabling Auto Completion}
\label{sec_bhv_muster_autocomp}

Step 7 of the run-loop checks to see if auto completion has been enabled.
This is a configuration parameter of the behavior:

\vspace{0.1in}
\noindent
\bvar{auto\_complete = true}

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

%=====================================================================
\subsection{Sharing the Muster Mode to Other Vehicles}
\label{sec_bhv_muster_modeshare}

When auto completion is enabled, in step 8 of the run-loop, the behavior
will package up a status message to be shared with all other vehicles.

\vspace{0.1in}
\noindent
\mvar{MUSTER\_COLLAB = "vname=deb, region=alpha, state=holding"}

\vspace{0.1in}
\noindent
The first component is ownship name. The second is the name of the muster
region. As discussed in Section \ref{sec_bhv_muster_multreg}, the behavior
may be configured with multiple possible muster regions, so this component
is included. The third component is the muster mode.

\vspace{0.1in}
\noindent
When the behavior publishes this variable, it uses a built-in behavior
function to wrap this message in an outgoing inter-vehicle message.
The convention in MOOS-IvP is to wrap it in a posting to
\mvar{NODE\_MESSAGE\_LOCAL} to be shared with all other variables. So
the actual posting will look more like:

\vspace{0.1in}
\prevgreen
\begin{verbatim}
NODE_MESSAGE_LOCAL = "src_node=deb,src_app=pHelmIvP,src_bhv=muster, 
                     dest_node=all,var_name=MUSTER_COLLAB,
                     string_val="vname=deb,region=one,state=holding"
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
To accomplish this in the behavior code, this is a single line:

\begin{consoleverb}
postXMessage("MUSTER_COLLAB", "vname=deb, region=alpha, state=holding"
\end{consoleverb}

\vspace{0.1in}
\noindent
This built-in convenience function is defined for all behaviors and will
package the outgoing message in the \mvar{NODE\_MESSAGE\_LOCAL} variable.


%=====================================================================
\subsection{Checking for Completion}
\label{sec_bhv_muster_autocheck}

In step 9, with auto completion enabled, the behavior will assess the
muster mode of itself and all other vehicles sharing their muster
mode.  The behavior maintains a mapping from vehicle name to mode,
along the lines of:

\begin{packed_itemize}
\item ben: holding
\item cal: captured
\item deb: tranisting
\end{packed_itemize}

\vspace{0.1in}
\noindent
In step 9, all incoming \mvar{MUSTER\_COLLAB} messages are parsed and
the mapping is updated. If all vehicles are in either in the completed
or holding mode, then the collaborative group mustering is regarded as
completed.  The consequences of completion are the normal consequences
for a completed IvP Helm behavior. End flags will be posted and the
behavior will be removed from the helm, freeing any trace of the
behavior from the helm memory space.

\vspace{0.1in}
\noindent
Current limitations: The criteria for group completion is that the
muster mode for ownship, and all other vehicles sharing their muster
modes, are checked. This list is of other vehicles is fluid and built
from received messages. A new entry in the map is added when a new
vehicle has sent a report. If there is a member of the group that is
outside of communications range, its muster mode will be unknown to
the group. For example if the goal is to send five vehicles to a
muster region and one vehicle is very far behind, the first four
vehicles might draw the conclusion that collaborative mustering is
complete when all four arrive. Other options for defining group
completion are being considered including explicitly naming the group,
or defining a numerical groups size requirement.

\vspace{0.1in}
\noindent
Further note: It is possible that a collaborating vehicle ceases to
communicate at some point, either due to a comms range issue, or vehicle
failure. If the last muster mode of this vehicle was not holding or
completed, it could prevent the group from ever reaching a consensus
of group completion. To guard against this, the muster behavior will
check for staleness of muster mode updates. An entry in the mapping will
be dropped after 30 seconds if a new muster mode update is not received.
Currently this time value is hard-coded.

%=====================================================================
\subsection{Muster Completion}
\label{sec_bhv_muster_autocomp}

In step 10, following a positive determination of completion, the
behavior will post endflags. Endflag support is implemented generally
for all behaviors. The only unique components of this for the Muster
behavior are the macros supported for solely for the Muster behavior
described in Section \ref{se_bhv_muster_macros}.

\vspace{0.1in}
\noindent
Note also that completion, by default, will result in the deletion of
the behavior from the helm and its memory. Like all behaviors,
destruction of the behavior upon completion may be overridden with the
\bvar{perpetual=true} behavior. This allows the Muster behavior to be
configured with multiple muster regions, transiting to one after
another without destruction of the behavior. Configuration of the
Muster behavior for multiple regions is discussed in Section
\ref{sec_bhv_muster_multireg}.


%=====================================================================
\section{Implemention of the Motion Policy}
%=====================================================================
\label{sec_bhv_muster_motion}

If the Muster behavior does not auto-complete (steps 7-10), then the
behavior motion policy is invoked (steps 11-13). These steps may
produce an IvP objective function that will participate in the helm's
multi-objective optimization stage of decision making. These steps
are described next. 

%=====================================================================
\subsection{Application of the Muster Mode}
\label{sec_bhv_muster_modes}

In step 11, the muster mode is examined. If the mode is either {\em
  completed} or {\em holding}, then the Muster behavior is essentially
content with its current position relative to the set point. It will
not produce an objective function.

\vspace{0.1in}
\noindent
In step 12, the Muster behavior will post runflags and return null.
In this case the Muster behavior is said to be in the {\em running}
mode, distinct from the {\em active} mode. Recall, for IvP behaviors
generally, the {\em active} mode is a special case of the {\em
  running} mode where an objective function is actually produced. So
runflags, if they are configured for this behavior, will be posted.
Again, the only unique components of this for the Muster behavior are
the macros supported for solely for the Muster behavior described in
Section \ref{sec_bhv_muster_macros}.

%=====================================================================
\subsection{Determining the Orientation to the Set Point}
\label{sec_bhv_muster_setpt_bng}

In reaching step 13, the determination has been made that this
behavior will produce an objective function. The objective function
will drive the vehicle toward the set point. The relative bearing from
ownship's current position to the set point needs to be
determined. This value is denoted $\theta_{sp}$. For example:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.37\textwidth]{figures/bhv_muster_theta_setpt.png}
  \caption{{\bf Determination of Ownship Orientation Toward the Set
      Point:} The value $\theta_{sp}$ denotes the relative bearing from ownship
  to the set point. The set point position was determined previously in setp 3.}
  \label{fig_bhv_muster_theta_setpt}
\end{figure}
\vspace{0.1in}

\noindent
Once $\theta_{sp}$ has been set, the IvP objective function may be constructed
in the next step.

%=====================================================================
\subsection{Construction of the IvP Objective Function}
\label{sec_bhv_muster_ipf}

In step 14, the IvP objective function will be created. The behavior
will use tools from the IvPBuild toolbox, the \var{ZAIC\_PEAK},
\var{ZAIC\_SPD} and \var{OF\_Coupler} tools to create the objective
function shown on the right in Figure \ref{fig_bhv_muster_zaic_ipf}.
The \var{ZAIC} tools are used for making the two single-variable utility
functions shown on the left, which are then coupled using the \var{OF\_Coupler}
tool into the single heading-speed IvP function. 

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.81\textwidth]{figures/bhv_muster_zaic_ipf.png}
  \caption{{\bf The IvP Objective Function for the Muster Behavior:}
    The IvP function for the Muster behavior is composed from the two
    single variable utility functions, defined over speed and
    heading. These two utility functions are coupled into a single
    heading-speed utility function shown on the right.}
  \label{fig_bhv_muster_zaic_ipf}
\end{figure}
\vspace{0.1in}

\noindent
The speed utility function ingests the \bvar{speed} behavior
configuration parameter, determining the peak value of the
function. The off-peak values lower than the set speed degrade in
utility slower than the off-peak values higher than the set
speed. This generally results in a more "patient" performance when the
behavior is competing with other behaviors like collision avoidance.
The inferred patience is due to the propensity of a compromise to
simply reduce speed rather than change heading to resolve a potential
collision.

\vspace{0.1in}
\noindent
The final step of creating the IvP function is to first normalize the
function to ensure the overall function has a minimum utility of 0,
and maximum utility of 100. The behavior priority weight, set with the
general behavior parameter \bhv{priority}, will then be applied to the
IvP function. This behavior has a static priority weight policy,
unchanging regardless of circumstances. Once it is set in the mission
file, it will remain the same throughout the mission unless it is
adjusted using the general \bvar{updates} mechanism by some entity
external to the Muster behavior.

%=====================================================================
\subsection{Active Participation of the Muster Behavior}
\label{sec_bhv_muster_postipf}

In step 15, the Muster behavior will actively participate in the Helm
decision stage by producing IvP function. When a running behavior does
indeed produce an objective function, this behavior is said to be in
the active state. Both the run flags and active flags will be posted
if the user has configured any.  Again, the only unique components of
these flag postings for the Muster behavior are the macros supported
for solely for the Muster behavior described in Section
\ref{sec_bhv_muster_macros}.





%=====================================================================
\subsection*{Performance Metrics}

There are a handful of metrics that will be used in evaluating a
Voronoi partition, and the process of forming the partition:

\begin{packed_itemize}
\item {\em separation}: The minimum distance between any two vehicles
\item {\em balance}: The standard deviation on measured area for all cells
\item {\em efficiency}: The time or distance travelled before all vehicles
  require no further motion to achieve balance or separation objectives
\item {\em stability}: The number of instances where a vessel needs to resume
  motion to re-achieve objectives. 
\end{packed_itemize}

\noindent
For the Muster behavior, separation is the primary motivation. While
separation usually comes with balance, it is not necessarily
so. Separation will be measured not only as an end-state value when
all vehicles have essentially "arrived". Separation in terms of
closest point of approach (CPA), during all phases will be measured,
and evaluated for instances of breach of collision threshold. 





%=====================================================================
\section{Performance Metrics and Macros}
%=====================================================================
\label{sec_bhv_muster_metrics}

A number of performance metrics are implemented for the Muster
behavior.  The value of a metric will be held locally in the behavior
and exposed through one of the supported macros. For example, the area
of the vehicle's local Voronoi cell is measured and available for
posting in any flag with the macro \var{\$(CELL\_AREA)}. If the user
is interested in tracking this information, the mission could be configured
to post this using the runflag parameter''

\prevblue
\begin{verbatim}
  runflag = MEASURED_AREA = $(CELL_AREA)
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
Or if this information is only needed once, when all collaborating vehicles
have arrived and the behavior is about to complete (step 10), then an
end flag could be used:

\prevblue
\begin{verbatim}
  endflag = FINAL_MEASURED_AREA = $(CELL_AREA)
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
while metrics are exposed as macros, the complete list of macros
supported for the Muster behavior includes certain information that is
not considered a metric, such as the name of the muster region. This
section will first describe the supported metrics and corresponding
macros, followed by any remaining macros.

%=====================================================================
\subsection{Performance Metrics Related to the Voronoi Field}


%=====================================================================
\subsection{Performance Metrics Related to Odometry}


%=====================================================================
\subsection{Non Metrics Related Macros}


%=====================================================================
\subsection{Summary of all Macros}





Voronoi Field
=========================
Aspect ratio for cell i
Average aspect ratio
Largest aspect ratio 
Area of region
Area of cell i
Perimiter of cell i
Area Standard deviation

Min distance ownship to any other vehicle
Min distance between any two vehicles

Local
==========================
Odometry total
Odometry since running
Odometry inside region
Odometry total
Odometry total





%=====================================================================
\section{Supported Macros for the Muster Behavior}
\label{sec_bhv_muster_macros}

muster mode
setpoint policy



%=====================================================================
\section{Configuring the Muster Behavior with Multiple Muster Regions}
\label{sec_bhv_muster_multreg}



%=======================================================================
\subsection{Configuration Parameters}
\label{sec_bhv_muster_params}

Certain configuration parameters available to Muster behavior are
are unique to the Muster behavior and others are inherited one or
more base classes. Here all parameters are presented, with details
on those unique to the Muster behavior.

%\input{includes/bhv_all_params}

\subsubsection*{Parameters for the Muster Behavior}

\vspace{0.15in}
\begin{listing}{Configuration Parameters for the Muster Behavior}
\label{lst_bhv_muster}
\small
\renewcommand{\arraystretch}{1.15}
\begin{longtable}{rp{0.76\textwidth}} 

  {\bf Parameter} &amp; {\bf Description} \\  
  
  \bvar{activate\_radius}: &amp; The radius from the set point, beyond
  which the behavior will resume the production of a non-zero speed
  objective function to close range to the current set point. The
  default is 12 meters. Section \ref{sec_bhv_muster_modes}. \\

  \bvar{auto\_complete}: &amp; Enable configured action to take place when
  or if all collaborating vehicles achieve their captured state. The
  default is \var{"off"}. Section \ref{sec_bhv_muster_autocomp}. \\

  \bvar{capture\_flag}: &amp; A set of flags to be posted each time the
  behavior transitions to the {\em captured} mode. Section
  \ref{sec_bhv_muster_capflags}. \\

  \bvar{capture\_radius}: &amp; The range to the set point, within which
  the behavior will enter the {\em captured} mode.
  Section \ref{sec_bhv_muster_setpt}. \\

  \bvar{holding\_policy}: &amp; The holding policy determines what
  objective function, if any, is produced when the behavior is in the
  {\em captured} or {\em holding} mode. Section
  \ref{sec_bhv_muster_ipf}. \\

  \bvar{muster\_region}: &amp; A string representing a convex polygon,
  or a string matching the label of a previously loaded muster
  region. Section \ref{sec_bhv_convoy}. \\

  \bvar{post\_prox\_poly}: &amp; If true, post a \mvar{VIEW\_POLYGON}
  message to representing the belief of the local Voronoi cell. The
  default is false. Section \ref{sec_}. \\

  \bvar{region\_in\_flag}: &amp; A flag published when the behavior is
  active and the vehicle enters the muster region. Section \ref{sec_}. \\

  \bvar{region\_out\_flag}: &amp; A flag published when the behavior is
  active and the vehicle exits the muster reegion. Section \ref{sec_}. \\

  \bvar{setpt\_method}: &amp; One of several options for the algorithm
  determining the set point. The default is \var{center}. Other
  options are \var{centroid}, or \var{hybrid}.
  Section \ref{sec_bhv_muster_setpt}. \\

  \bvar{setpt\_viewable}: &amp; If true, a \mvar{VIEW\_POINT} method will
  be published for rendering the set point as it evolves. The default
  is true. Section \ref{sec_bhv_muster_setpt}. \\

  \bvar{speed}: &amp; The transit speed to the set point, in meters per second.
  The default is zero.  \\

  \bvar{stale\_nav\_thresh}: &amp; The number of seconds between ownship
  navigation updates before a stale warning is produced. The default is
  5 seconds. Section \ref{sec_}. \\

  \bvar{visual\_hints}: &amp; Visual hints related to the rendering of the
  set point size, set point color, and set point label color. The defaults
  are 4, yellow, and off, respectively. \\

\end{longtable}
\end{listing}
\normalsize


\vspace{0.15in}
\begin{listing}{Example Configuration Block}
\label{lst_bhv_trail_ex}

\begin{fileverb}
Behavior = BHV_MusterX
{
  // General Behavior Parameters
  name       = muster_        
  pwt        = 100                   
  condition  = MODE = MUSTERING
  updates    = MUSTER_UPDATES        

  active_flag = AVOID=true

    capture_radius = 10 
   activate_radius = 25
     auto_complete = true
      capture_flag = AVOID=false

  stale_nav_thresh = 10
      setpt_method = center
    setpt_viewable = false
    post_prox_poly = false

    region_in_flag = MUSTER=true
   region_out_flag = MUSTER=false

    holding_policy = curr_hdg

      visual_hints = setpt_size = 5
      visual_hints = setpt_color = blue
      visual_hints = setpt_label_color = off
}
\end{fileverb}
\end{listing}



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