<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
% Include common packages, environments, counters etc
\input{../common_latex_packages}
\input{../common_latex_lab_format}
\input{../common_latex_definitions}
%===================================================================
\setcounter{tocdepth}{2}
%===================================================================

\begin{document}
\wikidoc{file=Lab.ClassWriteBehaviors}
\wikidoc{auth=mikerb@mit.edu}
\helplevelsubsec


%===================================================================
% Build the Cover Page in an environment style easy for wiki parsing
\begin{labcover}
\labtitle{Lab 16 - Introduction to Writing Behaviors for }
\vspace{0.1in}
\labtitle{the IvP Helm}
\vspace{0.1in}
\labcourse{2.680 Unmanned Marine Vehicle Autonomy, Sensing and Communications}
\vspace{0.3in}
\labpng{0.45}{figures/lab15_cover.png}
\vspace{0.3in}
\labdate{Spring 2018}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Henrik Schmidt, henrik@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\vspace{0.2in}
\labtoc{footnotesize}
\labtocdepth{2}
\end{labcover}

%====================================================================
% Add a blank page so first body page is on the right when doubleside
\blankpage
%====================================================================
\newpage \section{Overview and Objectives}

The goal of this lab is to develop an understanding of how to write
MOOS-IvP behaviors. Here we will build two intermediate simple
behaviors. The first behavior, the \var{Pulse} behavior, simply
generates a visual artifact viewable in \app{pMarineViewer} to confirm
the behavior operation. The second behavior, the \var{ZigLeg}
behavior, builds on the first behavior to periodically influence the
heading of the vehicle in a partial zig-zag leg.

\vspace{0.1in}
\noindent
In the end, your two behaviors should be runnable with output similar to 
the two clips below:

\vspace{0.1in}

  \urlx{https://vimeo.com/91971985} 

  \urlx{https://vimeo.com/91975349} 

\vspace{0.1in}
\noindent
A summary of today's topics:

\begin{labinfo}
%\labinfoheader{Topics:}
\begin{packed_itemize}[2]
\item Adding a New Behavior with the GenBehavior Script
\item Adding a New Behavior to your Third-party Build System
\item Building your First Behavior - The Alpha Range Pulse Mission
\item Building your Second Behavior - The Alpha ZigLeg Mission
\end{packed_itemize}
\end{labinfo}

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

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

Always make sure you have the latest code:

\begin{consoleverb}
 $ cd moos-ivp
 $ svn update
\end{consoleverb}

\vspace{0.1in}
\noindent
And rebuild if necessary:

\begin{consoleverb}
 $ ./build-moos.sh
 $ ./build-ivp.sh
\end{consoleverb}

%=======================================================================
\subsection*{Make Sure Key Executables are Built and In Your Path}

This lab does assume that you have a working MOOS-IvP tree checked out
and installed on your computer. To verify this make sure that the
following executables are built and findable in your shell path:

\begin{consoleverb}
 $ which MOOSDB
 /Users/you/moos-ivp/bin/MOOSDB
 $ which pHelmIvP
 /Users/you/moos-ivp/bin/pHelmIvP
\end{consoleverb}

\noindent
If unsuccessful with the above, return to the steps in Lab 1:

\pskip
\noindent
\urlxx{http://oceanai.mit.edu/ivpman/labs/machine_setup}{Lab.MachineSetup}

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

As with previous labs, we will use your version of the \var{moos-ivp-extend} tree, 
which by now you should have re-named something like \var{moos-ivp-janedoe}, where
your email may be \var{janedoe@mit.edu}. In this tree, there is a missions folder:

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

\noindent
For each distinct assignment in this lab, there should be a
corresponding subdirectory in a \var{lab\_15} sub-directory of the
\var{missions} folder, typically with both a \var{.moos} and
\var{.bhv} configuration file. See Section \ref{sec_hand_in} for the 
full requested file structure.

%=======================================================================
\subsection*{Documentation Conventions}

To help distinguish between MOOS variables, MOOS configuration
parameters, and behavior configuration parameters, we will use the
following conventions:

\begin{packed_itemize}[3]
\item MOOS variables are rendered in \mvar{green}, such as
  \mvar{IVPHELM\_STATE}, as well as postings to the \app{MOOSDB}, such
  as \mvar{DEPLOY=true}.
\item MOOS configuration parameters are rendered in \pvar{blue}, such
  as \pvar{AppTick=10} and \pvar{verbose=true}.
\item Behavior  parameters are rendered in \bvar{brown},
  such as \bvar{priority=100} and \bvar{endflag=RETURN=true}.
\end{packed_itemize}


%==========================================================================
\subsection*{More Resources}

\begin{itemize}

\item The slides from lecture "Writing Behaviors": \newline 
  \urlx{http://oceanai.mit.edu/2.680/docs/2.680-14-writing-behaviors.pdf}

\item The IvP Behavior Utility Functions \newline
  \urlx{http://oceanai.mit.edu/ivpman/help/bhv_functions}

\item The IvPBuild Toolbox ZAIC documentation \newline
  \urlx{http://oceanai.mit.edu/ivpman/chap/ivpbuild_zaics}

\end{itemize}




%======================================================================
\section{Generating a New Behavior and Adding it to the Helm}
%======================================================================
\label{sec_new_bhv}

The goals of this section are to gain familiarity with:

\begin{packed_itemize}
  \item Generation of a new behavior class,
  \item Adding a behavior to the build system,
  \item Ensuring a new behavior is findable and runnable by the helm.
\end{packed_itemize}

%======================================================================
\subsection{Generating a New Behavior with the GenBehavior Script}
\label{sec_gen_bhv}

One way to begin writing a new behavior is to copy an existing behavior's
source code files:

\vspace{0.1in}
\begin{consoleverb}
 $ cp BHV_SimpleWaypoint.h    BHV_Pulse.h
 $ cp BHV_SimpleWaypoint.cpp  BHV_Pulse.cpp
\end{consoleverb}
\vspace{0.1in}

\noindent 
Sometimes this is the most reasonable way to begin, especially if the new
behavior is very similar to the one being copied. 

\pskip

Another way to begin is by creating a new behavior is to use the
\cmd{GenBehavior} script in the \var{moos-ivp/bin} folder. This script
should already be in your path. To use it, just provide the name of
the behavior and your full name in double-quotes:

\vspace{0.1in}
\begin{consoleverb}
 $ GenBehavior FooBar "Jane Doe"
\end{consoleverb}
\vspace{0.1in}

\noindent
Note that the script automatically pre-pends the \var{BHV\_} to the
beginning of your behavior name to help reinforce the convention where
all behavior classes begin their names this way. The header file
produced will look something like that below. A good way to begin
working with this file is to tidy up the indenting loose ends and add
a date to the file. Note that it has all the overloadable virtual functions
defined, and placeholders for protected utility functions. It also
has a placeholder for configuration and state variables. The latter
is just a recommended convention for grouping instances variables. It
is often helpful to see immediatedly what variables represent the state
of the behavior, and what variables are potentially configurable in a 
\var{.bhv} mission file.  

\small
\vspace{0.1in}
\begin{fileverb}
/************************************************************/
/*    NAME: Jane Doe                                              */
/*    ORGN: MIT                                             */
/*    FILE: BHV_FooBar.h                                          */
/*    DATE:                                                 */
/************************************************************/

#ifndef FooBar_HEADER
#define FooBar_HEADER

#include &lt;string&gt;
#include "IvPBehavior.h"

class BHV_FooBar : public IvPBehavior {
public:
  BHV_FooBar(IvPDomain);
  ~BHV_FooBar() {};

  bool         setParam(std::string, std::string);
  void         onSetParamComplete();
  void         onCompleteState();
  void         onIdleState();
  void         onHelmStart();
  void         postConfigStatus();
  void         onRunToIdleState();
  void         onIdleToRunState();
  IvPFunction* onRunState();

protected: // Local Utility functions           

protected: // Configuration parameters       

protected: // State variables             
};

#define IVP_EXPORT_FUNCTION

extern "C" {
  IVP_EXPORT_FUNCTION IvPBehavior * createBehavior(std::string name, IvPDomain domain)
  {return new BHV_FooBar(domain);}
}
#endif
  
\end{fileverb}
\vspace{0.1in}
\normalsize

%======================================================================
\subsection{Add a New Behavior to the Build System}
\label{sec_aug_build}

After a new behavior has been created, it needs to be added to the build system. 
This is done in likely just one of two ways: Either (a) you have added it to 
an existing library where other behaviors are already being built, or (b) you
are creating a new \var{lib\_behaviors-janedoe} library from scratch. 

%----------------------------------------------------------------------
\subsubsection*{Adding a New Behavior to an Existing Library}

If the new behavior was created in an existing behvior library, e.g.,
\var{lib\_behaviors-test} in the \var{moos-ivp-extend} tree, then the
only thing that needs to be done is to edit the \var{CMakeLists.txt}
file in that library. A block similar to the below should exist for
each behavior:

\vspace{0.1in}
\begin{fileverb}
#--------------------------------------------------------
#                                      BHV_SimpleWaypoint
#--------------------------------------------------------
ADD_LIBRARY(BHV_SimpleWaypoint SHARED 
   BHV_SimpleWaypoint.cpp AOF_SimpleWaypoint.cpp)
TARGET_LINK_LIBRARIES(BHV_SimpleWaypoint
   helmivp
   behaviors 
   ivpbuild 
   logic 
   ivpcore 
   bhvutil 
   mbutil 
   geometry 
   ${SYSTEM_LIBS} )
\end{fileverb}
\vspace{0.1in}

\noindent
Just copy this block and replace all occurrences of the above behavior
with the new behavior instead. Also add any other \var{.cpp} files
needed for building this behavior. In the above example, the file
\var{AOF\_SimpleWaypoint.cpp} was needed, but often just the
\var{BHV\_*} files are the only file needed for specifying here. The
same holds true for the link libraries in the example above. The
libraries for the newly added behavior may be different. All the
above libraries, \var{helmivp, behaviors, ivpbuild, logic, ivpcore, bhvutil,
and mbutil} will almost certainly be required. The \var{geometry} library
will be needed if the behavior involves any of the classes like 
\var{XYPolygon} or \var{XYSegList}. 


%----------------------------------------------------------------------
\subsubsection*{Adding a New Behavior by Creating a New Behavior Library}

If the new behavior is being added as part of new library (folder or
directory), such as \var{lib\_behaviors-janedoe}, then an additional
step is needed to add \var{lib\_behaviors-janedoe} to the
\var{/src/CMakeLists.txt} file. There should already be a block in
this file similar to the one below, taken from the file:

\vspace{0.1in}
\noindent
\var{moos-ivp-extend/src/CMakeLists.txt}

\vspace{0.1in}
\begin{fileverb}
 #========================================================================
 # List the subdirectories to build...
 #========================================================================
 ADD_SUBDIRECTORY(lib_behaviors-test)
 ADD_SUBDIRECTORY(pXRelayTest)
 ADD_SUBDIRECTORY(pExampleApp)
\end{fileverb}
\vspace{0.1in}

\noindent 
Just add the new behavior library to this list.


%======================================================================
\subsection{Make the New Behavior Accessible to the Helm}
\label{sec_helm_env}

When the behavior is built, it generates a new shared library, typically
in the \var{moos-ivp-janedoe/lib} directory if one starts with the 
\var{moos-ivp-extend} template. When the helm launches, it needs to know
the location of this \var{lib/} directory so it can load all behaviors
found there. There are two ways to do this:

\vspace{0.1in}
\begin{itemize}
\item Augment the \var{IVP\_BEHAVIOR\_DIRS} shell environment variable by 
adding a line such as the one below in your shell configuration file. Here's
the example for \var{bash} users:

\vspace{0.1in}
\begin{fileverb}
  export IVP_BEHAVIOR_DIRS=/Users/janedoe/moos-ivp-janedoe/lib
\end{fileverb}
\vspace{0.1in}


\noindent
Here's the example for \var{tcsh} users:

\vspace{0.1in}
\begin{fileverb}
 setenv IVP_BEHAVIOR_DIRS '/Users/janedoe/moos-ivp-janedoe/lib'
\end{fileverb}
\vspace{0.1in}


\item Or, add the following line in your \app{pHelmIvP} configuration
  block in your \var{.moos} mission file:

\vspace{0.1in}
\begin{fileverb}
 ivp_behavior_dir = /Users/janedoe/moos-ivp-janedoe/lib
\end{fileverb}
\vspace{0.1in}

\noindent
Specifying the library location may also be done relative to the mission file, 
e.g., 

\vspace{0.1in}
\begin{fileverb}
 ivp_behavior_dir = ../../lib
\end{fileverb}
\vspace{0.1in}

\end{itemize}


%======================================================================
\newpage \section{A First Behavior - the Pulse Behavior}
%======================================================================
\label{sec_pulse_bhv}

Although the primary purpose of writing a behavior is to generate
output (IvP functions) to influence the trajectory of a vehicle, our
first behavior will simply post a visual artifact to the \app{MOOSDB}
at certain points in time.  
The goals of this exercise are to gain
familiarity with:


\begin{packed_itemize}
  \item Generation of a new behavior class
  \item Adding a behavior to the build system
  \item Obtaining information from the information buffer into your behavior
  \item Overloading general behavior functions to suit your needs
  \item Handling the setting of behavior parameters set by the user
\end{packed_itemize}


%=======================================================================
\subsection*{General Description of the Pulse Behavior}

The simple idea behind the \var{Pulse} behavior is for the behavior to
post a visual artifact to the \app{MOOSDB} five seconds after the
behavior notices that the vehicle reaches a waypoint achieved by a
sister behavior; the waypoint behavior. The idea is shown in the
Figure \ref{fig_rpulse} below.

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.55\textwidth]{figures/bhv_rpulse.png}
  \caption{{\bf The Pulse Behavior:} The behavior simply generates a 
    range pulse after it observes that a waypoint has been achieved.
    The range pulse is a posting to the variable \mvar{RANGE\_PULSE}.}
\label{fig_rpulse}
\end{figure}
\vspace{0.1in}

\noindent
The \var{Pulse} behavior is not configured with waypoints itself, but
uses information published by the waypoint behavior to detect a change
in waypoint status. Each time the "next" waypoint changes, the
behavior posts a range pulse. Nothing more.

%=======================================================================
\subsection{Make a New Pulse Behavior that Does Nothing for Now}
\label{pulse_step1}

The first step is to create a new behavior. Each behavior is a class
with a corresponding \var{.h} and \var{.cpp} file. Use the
\var{GenBehavior} script described in Section \ref{sec_gen_bhv}:

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-jsmith/src/lib_behaviors-test
 $ GenBehavior Pulse "Jane Doe"
\end{consoleverb}
\vspace{0.1in}

\noindent
Once the behavior is generated, follow the instructions in Section
\ref{sec_aug_build} for augmenting your build system to build the new
behavior. Confirm that the behavior is built by looking for a \var{Pulse}
behavior in \var{moos-ivp-janedoe/lib}. Finally, follow the instructions
in Section \ref{sec_helm_env} for making your new behavior findable by
the helm when it is launched.

%=======================================================================
\subsection{Assignment 1 (self check off): Confirm Your Behavior is Runnable}
\label{pulse_step2}

This newly created \var{Pulse} behavior, as empty as it is, should be
ready for use by the helm. Here we confirm this:


%------------------------------------------------------------------------
\subsubsection*{Create the Alpha Range Pulse Mission}

If you haven't done so already, make a new mission folder,
\var{alpha\_range\_pulse}, by making a copy of the \var{s1\_alpha}
mission from the moos-ivp tree.

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-janedoe/missions/
 $ mkdir lab_15
 $ cd lab_15
 $ cp -rp moos-ivp/ivp/missions/s1_alpha alpha_range_pulse
\end{consoleverb}
\vspace{0.1in}

%------------------------------------------------------------------------
\subsubsection*{Add the Pulse Behavior to the Alpha Range Pulse Mission}

Add the Pulse behavior to the \var{alpha.bhv} file by adding the following
lines before or after the other behaviors:

\vspace{0.1in}
\begin{fileverb}
 Behavior=BHV_Pulse
 {
   name       = pulse
   pwt        = 100
 }
\end{fileverb}
\vspace{0.1in}

\noindent
This configuration doesn't really do much, but it's enough to load the behavior
alongside the other behaviors and confirm that the behavior works.

%------------------------------------------------------------------------
\subsubsection*{Verify the Pulse Behavior is Loaded and Running}

Once the \var{Pulse} behavior is added to the mission file, launch the mission:

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-janedoe/missions/lab_15/alpha_range_pulse
 $ ./launch.sh 10
\end{consoleverb}
\vspace{0.1in}

\noindent
You should see the vehicle doing its normal home-plate pattern of the 
alpha mission. To confirm the \var{Pulse} behavior is loaded and running, 
check the AppCast output of the \app{pHelmIvP} application. It should 
look something like that below:

\vspace{0.1in}
\begin{consoleverb}

===================================================================
pHelmIvP alpha                                            0/0(1307)
===================================================================
Helm Iteration: 1202
  IvP Functions:  1
  Mode(s):        
  SolveTime:   0.00   (max=0.01)
  CreateTime:  0.01   (max=0.01)
  LoopTime:    0.01   (max=0.01)
  Halted:         false   (0 warnings)
Helm Decision: [speed,0,4,21] [course,0,359,360]
  speed = 2
  course = 180
Behaviors Active: ---------- (1)
  waypt_survey [298.87] (pwt=100) (pcs=20) (cpu=0.52) (upd=0/0)
Behaviors Running: --------- (1)
  pulse [298.87]
Behaviors Idle: ------------ (1)
  waypt_return[298.87]
Behaviors Completed: ------- (0)

\end{consoleverb}
\vspace{0.1in}

\noindent
Note the presence of the \var{Pulse} behavior under the \var{"Behaviors Running:"}
section. It's not doing anything yet, but at least it's running. The next step
is to get it to start doing something.

%=======================================================================
\subsection{Edit Your Behavior to Get Needed Info from the InfoBuffer}
\label{pulse_step3}

There are three key pieces of information your behavior will need to
know and update frequently. The vehicle's own x,y position, and the
waypoint index to which the waypoint behavior is currently transiting
toward.  The latter information is published to the \app{MOOSDB} by
the waypoint behavior in a simple report of the form:

\prevgreen
\begin{verbatim}
  WPT_INDEX = 2
\end{verbatim}
\postverb

\noindent
To ensure the above MOOS variable is subscribed for by the helm and
thus in the helm info buffer, you will need to explicitly declare that
your behavior needs it by using the \func{addInfoVars()} function in
the behavior constructor as described in the lecture notes.

\vspace{0.1in}
\noindent
You will need also to get the current time from the information buffer. Use the
\func{getBufferCurrTime()} function as described in the lecture notes.

\vspace{0.1in}
\noindent
You will need the waypoint index to know and note when it has
changed. You need the time so you can mark the time when it changed
and generate the pulse five seconds later. And you will need the
vehicle x,y position for creating the range pulse when the time
comes. You may or may not want to store these as member variables of
your behavior class. By storing them as member variables, you then
have the option of having a separate little class function for
updating information from the info buffer on each behavior
iteration. This is just a style suggestion.

%=======================================================================
\subsection{Overload the onRunState() Function}
\label{pulse_step4}

Implement your behavior's \func{onRunState()} function to produce a
range pulse each time the behavior notes that the waypoint index has
incremented. Remember, the waypoint index is information posted by a
separate behavior, the waypoint behavior, in a posting to the
\app{MOOSDB}. Have your behavior make its posting five seconds after
hitting each waypoint.

\pskip
The range pulse is a particular message that the \app{pMarineViewer}
application knows how to parse and render. A typical posting looks
like:

\prevgreen
\begin{verbatim}
  VIEW_RANGE_PULSE  =  x=15,y=-45,radius=40,duration=4,label=pulse,
                       edge_color=yellow,fill_color=yellow,time=16010.31,edge_size=1
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
Try poking the above to the \app{MOOSDB} with \app{uPokeDB}
while \app{pMarineViewer} is running, to get an idea of how it works
and what it looks like.

\vspace{0.1in}
\begin{consoleverb}
 $ uPokeDB VIEW_RANGE_PULSE=x=15,y=-45,radius=40,duration=4,label=pulse,edge_color=yellow,
fill_color=yellow,time=@MOOSTIME,edge_size=1 alpha.moos++
\end{consoleverb}


\vspace{0.1in}
\noindent
Note the inclusion of \var{alpha.moos++} on the \app{uPokeDB} invocation above.
This is to ensure that the poke time warp is consistent with the overall
mission time warp.

\vspace{0.1in}
\noindent
The pulse is essentially a ring with expanding radius that expands to
a specified value (\bvar{radius}), over a specified time
(\bvar{duration}). It is centered at a given x,y position and specified
edge color, fill color, and edge width.  In our behavior we want the
center to be the vehicle's current position.

\vspace{0.1in}
\noindent
It is recommended that a \mvar{VIEW\_RANGE\_PULSE} message be generated by 
first creating a \var{XYRangePulse} instance, setting its parameters, and 
getting a serialized string version, as below: 

\vspace{0.1in}
\begin{fileverb}
 // Presumably inside your behavior implementation
 #include "XYRangePulse.h"

 XYRangePulse pulse;
 pulse.set_x(m_osx);
 pulse.set_y(m_osy);
 pulse.set_label("bhv_pulse");
 pulse.set_rad(m_range);
 pulse.set_duration(m_pulse_duration);
 pulse.set_time(m_curr_time);
 pulse.set_color("edge", "yellow");
 pulse.set_color("fill", "yellow");

 string spec = pulse.get_spec();
 postMessage("VIEW_RANGE_PULSE", spec);
\end{fileverb}

%=======================================================================
\subsection{Handle Behavior User Preferences}
\label{pulse_step5}

Although not strictly essential in this simple behavior, almost all
behaviors need to handle parameter preferences specified by the user
in the \var{.bhv} file. In the \var{Pulse} behavior, you should handle
two particular parameters: the radius of the range pulse and the
duration of the range pulse. Your behavior should be able to handle
the below configuration (namely lines 5 and 6):

\vspace{0.1in}
\begin{fileverb}
 1  Behavior=BHV_Pulse
 2  {
 3    name = pulse
 4  
 5    pulse_range    = 20
 6    pulse_duration = 4
 7  }
\end{fileverb}

\vspace{0.1in}
\noindent
To do this, overload the \func{setParam()} function in your
behavior. You should be able to just follow the example of the
\var{BHV\_SimpleWaypoint} behavior in your tree.

%=======================================================================
\subsection{Assignment 2 (check off) - The Alpha Range Pulse Mission}
\label{sec_assgn_two}

To demonstrate your behavior, run the Alpha Range Pulse mission with
the Pulse behavior.  Part of the demonstration involves showing that
your behavior can accept a different \bvar{pulse\_range} or
\bvar{pulse\_duration} specified at the time of the demo.  Your end
result should look something like the video posted at:

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{educlips/lab_15_alpha_range_pulse.png}
  \caption{The Pulse behavior simply posts a rendering of a range pulse a few 
    seconds after each waypoint is hit.}
  \label{fig_alpha_range_pulse}
  \urlvideo{http://vimeo.com/91971985}{0:23}
\end{figure}

%=======================================================================
\newpage \section{A Second Behavior - the ZigLeg Behavior}
%=======================================================================
\label{sec_zigleg_bhv}

The \var{ZigLeg} behavior is an extension of the \var{Pulse}
behavior. Rather than post a range pulse after hitting a
waypoint, the \var{ZigLeg} behavior will briefly produce an objective
function to influence the vehicle trajectory. Like the \var{Pulse}
behavior, the \var{ZigLeg} behavior looks for the point in time where a
sister waypoint behavior has reached a waypoint. Five seconds after
hitting a waypoint, the \var{ZigLeg} behavior will produce an objective
function with a heading preference some number of degrees (by default
45) from the vehicle's present heading. It will do this only for a
brief period of time (by default 10 seconds). The idea is shown in the
Figure \ref{fig_zleg} below.

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.55\textwidth]{figures/bhv_zleg.png}
  \caption{{\bf The ZigLeg Behavior:} The behavior generates a 
    brief heading preference (in the form of an IvP objective function)
    shortly after noticing the arrival at a waypoint.}
\label{fig_zleg}
\end{figure}
\vspace{0.1in}

\noindent
As with the \var{Pulse} behavior, the \var{ZigLeg} behavior is not
configured with waypoints itself, but uses information published by
the waypoint behavior to detect a change in waypoint status. Each time
the "next" waypoint changes, the behavior posts a range pulse and
briefly generates an objective function. The idea is shown in the 
video in Figure \ref{fig_alpha_zigleg}.

\vspace{0.1in}

%=======================================================================
\subsection{Make a New ZigLeg Behavior that Does Nothing for Now}

In the case of the \var{ZigLeg} behavior, there are features that will
be similar to the \var{Pulse} behavior, namely that it will do its
thing a few seconds after the vehicle otherwise hits a waypoint. For this
reason you may find it more convenient to build your new \var{ZigLeg}
behavior by copying the \var{Pulse} behavior:

\vspace{0.1in}
\begin{consoleverb}
 $ cd moos-ivp-jsmith/src/lib_behaviors-test
 $ cp BHV_Pulse.h    BHV_ZigLeg.h
 $ cp BHV_Pulse.cpp  BHV_ZigLeg.cpp
\end{consoleverb}
\vspace{0.1in}

\noindent
Of course you'll need to do a find-replace in both files, replacing
all the \var{BHV\_Pulse} references with \var{BHV\_ZigLeg}.  Augment
your build system to handle the new behavior. If you want, you can
replicate the assignment in Section \ref{pulse_step2} to confirm your
\var{ZigLeg} behavior is runnable at this point, but that's up to you.

%=======================================================================
\subsection{Edit the ZigLeg Behavior to Get Needed Info from the InfoBuffer}

Same as with the \var{Pulse} behavior, Section \ref{pulse_step3}, except you will
also need the vehicle's present heading. When the behavior {\em does} produce
an objective function over heading, it will be as an offset to the present 
heading.

%=======================================================================
\subsection{Overload the onRunState() Function}

Same as with the \var{Pulse} behavior, Section \ref{pulse_step4},
except in this behavior you will additionally produce an objective
function over vehicle heading, at the very moment the range pulse
would have been generated. Whereas the \var{Pulse} behavior generated
the pulse only once, the IvP function will be generated continuously
once it has started, continuing for some number of seconds.  The
number of seconds and the heading offset should by default be 10
seconds and 45 degrees respectively. But these values should be
configurable in the behavior file and thus handled in your behavior's
\func{setParam()} function as described below.

\pskip
Regarding the syntax needed to create an objective function, most likely you
will be using the \var{ZAIC\_PEAK} tool to do this. For more information, see
the lecture class notes, and consult the \var{BHV\_SimpleWaypoint} behavior
for an example.

\pskip
\noindent
Two additional important notes: 

\begin{itemize}

\item Before returning the objective function in the
  \func{onRunState()} function, you will need to set its priority
  weight. This step may be missing in the \var{BHV\_SimpleWaypoint}
  behavior. If you built your behavior with the \var{GenBehavior}
  script it should already be there. You can do this with the
  following two lines:

\begin{fileverb}
  if(ipf)
     ipf-&gt;setPWT(m_priority_wt);
\end{fileverb}

\item Your \var{ZigLeg} behavior will be running alongside the \var{Waypoint}
behavior. For the \var{ZigLeg} behavior to exert its influence, you will need
to give it a higher priority weight in the \var{.bhv} configuration file.

\end{itemize}

%=======================================================================
\subsection{Handle User Behavior Preferences}
\label{zleg_step5}

Your \var{ZigLeg} behavior should handle two parameters: the heading
offset, and the duration for which the behavior produces the objective
function on each waypoint arrival event.

\vspace{0.1in}
\noindent
Your behavior should be able to handle the below configuration (namely
lines 5-6)

\vspace{0.1in}
\begin{fileverb}
  Behavior=BHV_ZigLeg
  {
    name = zigleg
   
    zig_duration   = 10
    zig_angle      = 45
  }
\end{fileverb}

\vspace{0.1in}
\noindent
As before, do this by overloading the \func{setParam()} function in your
behavior. 

%=======================================================================
\subsection{Assignment 3 (check off) - The Alpha ZigLeg Mission}

To demonstrate your behavior, run the Alpha ZigLeg mission with the
ZigLeg behavior. Part of the demonstration involves showing that your
behavior can accept a different \bvar{zig\_angle} or
\bvar{zig\_duration} specified at the time of the demo.  Your end
result should look something like the video posted at:

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{educlips/lab_15_alpha_zigleg.png}
  \caption{The ZigLeg behavior influences the heading of the vehicle
    briefly a few seconds after each waypoint is hit.}
  \label{fig_alpha_zigleg}
  \urlvideo{https://vimeo.com/91975349}{0:21}
\end{figure}


%=======================================================================
\newpage \section{Instructions for Handing In Assignments}
%=======================================================================

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

The assignment for this lab is to (a) demonstrate your two working
behaviors to a TA or instructor, and (b) demonstrate that your two
behaviors accept parameter modifications as described in Section
\ref{pulse_step5} and Section \ref{zleg_step5}. There isn't any
requirement to hand in code, but the below is the requested file
structure:

\vspace{0.1in}
\begin{consoleverb}
  moos-ivp-janedoe/
    missions/
      lab_16/
        alpha_range_pulse/      // Assignment 2 - check off
        alpha_zigleg/           // Assignment 3 - check off
\end{consoleverb}
\vspace{0.1in}


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

This lab should be completed by the end of day next Tuesday. (April
25th, 2017). 

\end{document}
</pre></body></html>