<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\newpage
\subsection{Behavior File Syntax Checking}
\label{sec_syncheck}
\index{Behavior Files!Syntax Checking}

When the helm is launched and the behavior file(s) are read, the helm
will perform certain syntax checking and potentially abort the launch
if problems are encountered. The syntax checking is implemented partly
in the helm and partly in the behavior implementation.  The first kind
of syntax checking is done when a behavior configuration block is
opened with a declaration of a behavior type, e.g., lines 6 and 20 in
Listing \ref{listing_bhv_file}. If the behavior is not of a known type
an error is reported. Otherwise, the behavior is instantiated, and
further syntax checking is implemented in the behavior instances at
both the superclass and subclass level as depicted in Figure
\ref{fig_syncheck}.

\vspace{0.15in}

\begin{figure}[H]
  \centering    
  \includegraphics[width=0.75\textwidth]{figs_helm/syntax-check.png}
  \caption{{\bf Behavior configuration syntax checking}: Parameter
    syntax checking is implemented in both the IvPBehavior superclass
    and individual behaviors. A parameter setting is comprised of two
    string arguments - the parameter name and the parameter
    value. Typically a behavior is implemented such that a given
    parameter setting is first tried at the superclass level, and if
    it does not succeed it is tried at the subclass level. A behavior
    author is solely responsible for implementing good syntax checking
    and where possible semantic checking on parameter values.}
  \label{fig_syncheck}
\end{figure}

\vspace{0.1in}

All parameter specifications are broken into two strings separated by
the first \var{'='} character, to be the parameter name and the
parameter value. For example, the parameter on line 24 in Listing
\ref{listing_bhv_file} is \bvar{"condition"} and the parameter value is
\bvar{"return = true"}. Once the helm has created the behavior
instance, all parameter-value pairs are handled by behavior instance
where it performs syntax checking and semantic checking where
possible. All behaviors are a subclass of the general IvPBehavior
superclass and many parameters are defined at the superclass
level. The parameter-value pair is therefore typically first sent to
the superclass for handling and if it is not handled there, it may be
handled by the parameter handling routine of the subclass. If it is
not handled by either the superclass or subclass a value of
\var{false} is returned to the helm and the helm ceases to launch and
the line number and line contents are written to the terminal window.

Syntax checking is also performed during dynamic parameter
configuration, introduced previously in Section
\ref{bhv_dynamic_config}.  The same parameter-value handling routines
are invoked as for when the start-up behavior configuration is
conducted so the idea in Figure \ref{fig_syncheck} still holds. The
action taken by the helm as a result of a faulty parameter-value
configuration is different between the start-up case and the dynamic
configuration case. While it is reasonable to cease the helm start-up
when a faulty parameter-value pair is encountered in the behavior
file, it is not reasonable to cease the helm operation upon a faulty
attempted dynamic re-configuration of a behavior parameter. Instead,
failed dynamic configuration attempts are handled by simply
disregarding the attempt, but making the failed attempt known in a
couple ways. The first way is to post a warning by writing to the
variable \mvar{BHV\_WARNING}.  For example, if the vehicle return
point configured on line 38 in Listing \ref{listing_charlie} on page
\pageref{listing_charlie} were misspelled during an attempt to
configure this parameter dynamically, the following post to the MOOSDB
by the helm may be seen:

\index{Key MOOS Variables!\var{BHV\_WARNING}}

\vspace{0.1in}

\prevgreen
\begin{verbatim}
  BHV_WARNING = "Faulty update for behavior: waypt_return. Bad parameter(s): pointss"
\end{verbatim}
\postverb

\vspace{0.1in}
\index{uHelmScope}
\noindent
Indication of the above syntax error will also appear in the output of
the \app{uHelmScope} application discussed in Section
\ref{util_uhelmscope}. In the \app{uHelmScope} output, the details of
a syntax error are not displayed, but rather a numerical summary of
how many dynamic configurations, or updates, were attempted and how
many of those were syntax error free. See the end of line 12 in
Listing \ref{uhs_outputa} for example.

A dynamic parameter configuration may consist of multiple parameters
in a single string as discussed previously in Section
\ref{bhv_dynamic_config}, and may have a syntax in error in one but
not all parameter-value pairs. For example the below string, for
reconfiguring the second waypoint behavior in Listing
\ref{listing_charlie} has a syntax error in the second of three
variable-value pairs:

\vspace{0.1in}

\prevgreen
\begin{verbatim}
  UPDATES_RETURN = "points=50,50 # speeeeed=1.5" # radius=6.5"
\end{verbatim}
\postverb

\vspace{0.1in}

\noindent
In such a case, the two parameter-value pairs that are free of errors
are accepted and the one containing the error is ignored. In terms of
tallying, the above is counted as {\em one} unsuccessful update
attempt.

It is also worth noting what kinds of errors are {\em not} detected by
the helm at start-up or run time. No checking is done to ensure that
behaviors have unique names - although this is recommended to at least
prevent confusion. No checking is done to ensure that behaviors
receive their dynamic updates (if at all) from MOOS variables with
unique names. A deliberate design consideration of the helm was to
avoid the need for global book-keeping or error-checking by the helm
across all behaviors. The helm has a generic interface to behaviors
for setting parameters and querying them for production output at
run-time on each iteration. Much of the responsibility for
implementing effective error checking lies with the individual
behavior author. To the extent that part of each behavior
implementation is comprised of the IvPBehavior superclass, some error
checking has the appearance of being provided by the helm.

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