<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%========================================================================
\section{Design Considerations of MOOS-IvP}
%========================================================================
\wikisec{grp=moosivp,file=HelmDesignIntro,short=Design Overview}
\label{sec_design}


The primary motivation in the design of MOOS-IvP is to build highly
capable autonomous systems. Part of this picture includes doing so at
a reduced short and long-term cost and a reduced time line. By
"design" we mean both the choice in architectures and algorithms as
well as the choice to make key modules for infrastructure, basic
autonomy and advanced tools available to the public under an Open
Source license. The MOOS-IvP software design is based on three
architecture philosophies, (a) the backseat driver paradigm, (b)
publish and subscribe autonomy middleware, and (c) behavior based
autonomy.  The common thread is the ability to separate the
development of software for an overall system into distinct modules
coordinated by infrastructure software made available to the public
domain. 

%================================================================
\subsection{Public Infrastructure - Layered Capabilities}

The central architecture idea of both MOOS and IvP is the separation
of overall capability into separate and distinct modules. The unique
contributions of MOOS and IvP are the methods used to {\em coordinate}
those modules. A second central idea is the decision to make
algorithms and software modules for infrastructure, basic autonomy and
advanced tools available to the public under an Open Source
license. The idea is pictured in Figure \ref{wheel-one}. There are
three things in this picture - (a) modules that actually perform a
function (the wedges), (b) modules that coordinate other modules (the
center of the wheel), and (c) standard wrapper software use by each
module to allow it to be coordinated (the spokes).

\vspace{0.1in}

\begin{figure}[htp]
  \centering 
  \includegraphics[width=.95\linewidth]{figures/pie-wheel.png}
  \caption{{\bf Public Infrastructure - Layered Capabilities:} The
    center of the wheel represents MOOS-IvP Core. For MOOS this means
    the MOOSDB and the message passing and scheduling algorithms. For
    IvP this means the IvP helm behavior management and the
    multi-objective optimization solver. The wedges on the wheel
    represent individual modules - either MOOS processes or IvP
    behaviors. The spokes of the wheel represent the idea that each
    module inherits from a superclass to grab functionality key to
    plugging into the core.  Each wedge or module contains a wrapper
    defined by the superclass that augments the function of the
    individual module. The darker wedges indicate publicly available
    modules and the lighter ones are modules added by users to augment
    the public set to comprise a particular fielded autonomy system.}
\label{wheel-one}
\end{figure}

The darker wedges in Figure \ref{wheel-one} represent application
modules (not infrastructure) that provide basic functionality and are
publicly available.  However, they do not hold any special immutable
status. They can be replaced with a better version, or, since the
source code is available, the code of the existing module can be
changed or augmented to provide a better or different version
(hopefully with a different name - see the section on branching
below).  Later sections provide an overview of about 40 or so
particular modules that are currently available. By modules we mean
MOOS applications and IvP behaviors and the above comments hold in
either case. The yellow wedges in Figure \ref{wheel-one} represent the
imaginable unimplemented modules or functionality.  A particular
fielded MOOS-IvP autonomy system typically is comprised of (a) the
MOOS-IvP core modules, (b) {\em some} of the publicly available MOOS
applications and IvP behaviors, and (c) additional perhaps non-public
MOOS applications and IvP behaviors provided by one or more third
party developers.

\pskip

The objective of the public-infrastructure/layered-capabilities idea
is to strike an important balance - the balance between effective code
re-use and the need for users to retain privacy regarding how they
choose to augment the public codebase with modules of their own to
realize a particular autonomy system. The benefits of code re-use are
an important motivation in fundamental architecture decisions in both
MOOS and IvP.  The modules that comprise the public MOOS-IvP codebase
described in this document represent over twenty work-years of
development effort. Furthermore, certain core components of the
codebase have had hundreds if not thousands of hours of usage on a
dozen or so fielded platform types in a variety of situations. The
issue of code re-use is discussed next.

\subsection{Code Re-Use}

Code re-use is critical, and starts with the ability to have a system
comprised of separate but coordinated modules. They key technical
hurdle is to achieve module separation without invoking a substantial
hit on performance.  In short, MOOS middleware is a way of
coordinating separate processes running on a single computer or over
several networked computers. IvP is a way of coordinating several
autonomy behaviors running within a single MOOS process.

\vspace{0.1in}

\noindent
Factors Contributing to Code Re-use:

\begin{itemize}
\item {\em Freedom from proprietary issues}. Software serving as
  infrastructure shared by all components (MOOS processes and IvP
  behaviors) are available under an Open Source license. In addition
  many mature MOOS and IvP modules providing commonly needed
  capabilities are also publicly available.  Proprietary or
  non-publicly released code may certainly co-exist with
  non-proprietary public code to comprise a larger autonomy
  system. Such a system would retain a strategic edge over competitors
  if desired, but have a subset of components common with other users.

\item {\em Module independence}. Maintaining or augmenting a system
  comprised of a set of distinct modules can begin to break down if
  modules are not independent with simple easy-to-augment
  interfaces. Compile dependencies between modules need to be
  minimized or eliminated. The maintenance of core software libraries
  and application code should be decoupled completely from the issues
  of 3rd party additional code.

\item {\em Simple well-documented interfaces}.  The effort required to
  add modules to the code base should be minimized. Documentation is
  needed for both (a) using the publicly available applications and
  libraries, and (b) guiding users in adding their own modules.

\item {\em Freedom to innovate}. The infrastructure does not put undue
  restrictions on how basic problems can be solved. The infrastructure
  remains agnostic to techniques and algorithms used in the
  modules. No module is sacred and any module may be replaced.
\end{itemize}

\noindent
Benefits of Code Re-Use:

\begin{itemize}
\item {\em Diversity of contributors}. Increasingly, an autonomy
  system contains many components that touch many areas of
  expertise. This would be true even for a vanilla use of a vehicle,
  but is compounded when considering the variety of sensors and
  missions and ways of exploiting sensors in achieving mission
  objectives. A system that allows for wide code re-use is also a
  system that allows module contributions from a wide set of
  developers or experts. This has a substantial impact on the issues
  mentioned below of lower cost, higher quality and reliability, and
  reduced development time line.

\item {\em Lower cost}. One immediate benefit of code re-use is the
  avoidance of repeatedly re-inventing modules. A group can build
  capabilities incrementally and experts are free to concentrate on
  their area and develop only the modules that reflect their skill set
  and interests. Perhaps more important, code re-use gives the systems
  integrator {\em choices} in building a complete system from
  individual modules. Having choices leads to increased leverage in
  bargaining for favorable licensing terms or even non-proprietary
  terms for a new module. Favorable licensing terms arranged at the
  outset can lead to substantially lower long-term costs for future
  code maintenance or augmentation of software.

\item {\em Higher performance capability}. Code re-use enhances
  performance capability in two ways. First, since experts are free to
  be experts without re-inventing the modules outside their expertise
  and provided by others, their own work is more likely to be more
  focused and efficient. They are likely to achieve a higher
  capability for a given a finite investment and given finite
  performance time. Second, since code re-use gives a systems
  integrator {\em choices}, this creates a meritocracy based on
  optimal performance-cost ratio of candidate software modules. The
  under-capable, more expensive module is less likely to diminish the
  overall autonomy capability if an alternative module is developed to
  offer a competitive choice. Survival of the fittest.

\item {\em Higher performance reliability}. An important part of
  system reliability is testing. The more testing time and the greater
  diversity of testing scenarios the better. And of course the more
  time spent testing on physical vehicles versus simulation the
  better. By making core components of a codebase public and
  permitting re-use by a community of users, that community provides
  back an enormous service by simply using the software and
  complaining when or if something goes wrong. Certain core components
  of the MOOS-IvP codebase have had hundreds if not thousands of hours
  of usage on a dozen or so platform types in a variety of
  situations. And many more hours in simulation. Testing doesn't
  replace good coding practice or formal methods for testing and
  verifying correctness, but it complements those two aspects and is
  enhanced by code re-use.

\item {\em Reduced development time line}. Code re-use means less code
  is being re-developed which leads to quicker overall system
  development. More subtly, since code re-use can provide a systems
  integrator choices and competition on individual modules,
  development time can be reduced as a consequent. An integrator may
  simply accept the module developed the quickest, or the competition
  itself may speed up development. If choices and competition result
  in more favorable license agreements between the integrator and
  developer, this in itself may streamline agreements for code
  maintenance and augmentation in the long term. Finally, as discussed
  above, if code re-use leads to an element of community-driven bug
  testing, this will also quicken the pace in the evolution toward a
  mature and reliable autonomy system.
\end{itemize}


%\subsubsection{Development Time Versus Usage Time}
%Two types of work-year measurements - the time it has taken to build the
%software, and the amount of usage of the software
%
%Usage Time can be further broken down into Simulation Time, Deployment Time.

%================================================================
\subsection{The Backseat Driver Design Philosophy}
\label{sec_backseat}

The key idea in the backseat driver paradigm is the separation between
{\em vehicle control} and {\em vehicle autonomy}. The vehicle control
system runs on a platform's main vehicle computer and the autonomy
system runs on a separate payload computer. This separation is also
referred to as the {\em mission controller - vehicle controller}
interface.  A primary benefit is the decoupling of the platform
autonomy system from the actual vehicle hardware. The vehicle
manufacturer provides a navigation and control system capable of
streaming vehicle position and trajectory information from the main
vehicle computer, and accepting a stream of autonomy decisions such as
heading, speed and depth in return from the payload computer. Exactly how the vehicle navigates
and implements control is largely unspecified to the autonomy system
running in the payload. The relationship is depicted in Figure
\ref{fig_backseat}.

\vspace{0.15in}

\begin{figure}[htp]
  \centering 
  \includegraphics[width=.72\linewidth]{figures/backseat_ppt.png}
  \caption{{\bf The backseat driver paradigm}: The key idea is the
    separation of vehicle autonomy from vehicle control. The autonomy
    system provides heading, speed and depth commands to the vehicle
    control system. The vehicle control system executes the control
    and passes navigation information, e.g., position, heading and
    speed, to the autonomy system. The backseat paradigm is agnostic
    regarding how the autonomy system implemented, but in this figure
    the MOOS-IvP autonomy architecture is depicted.}
\label{fig_backseat}
\end{figure}

\vspace{0.15in}

The autonomy system on the payload computer consists of a set of
distinct processes communicating through a publish-subscribe database
called the MOOSDB (Mission Oriented Operating Suite - Database). One
such process is an interface to the main vehicle computer, and another
key process is the IvP Helm implementing the behavior-based autonomy
system.  The MOOS community is referred to as the "larger autonomy"
system, or the "autonomy system as a whole" since MOOS itself is
middleware, and actual autonomous decision making, sensor processing,
contact management etc., are implemented as individual MOOS processes.

%================================================================
\subsection{The Publish-Subscribe Middleware Design Philosophy and MOOS }

MOOS provides a middleware capability based on the publish-subscribe
architecture and protocol. Each process communicates with each other
through a single database process in a star topology (Figure
\ref{fig_moos}).  The interface of a particular process is described
by what messages it produces (publications) and what messages it
consumes (subscriptions). Each message is a simple variable-value pair
where the values are typically either string or numerical values such
as (\msvar{STATE}, \var{"DEPLOY"}), or (\msvar{NAV\_SPEED},
\var{2.2}). MOOS messages may also contain raw binary data for passing
images for example.

\vspace{0.15in}

\begin{figure}[htp]
  \centering 
  \includegraphics[width=.72\linewidth]{figures/moos_arch_ppt.png}
  \caption{{\bf A MOOS community}: is a collection of MOOS
    applications typically running on a single machine each with a
    separate process ID. Each process communicates through a single
    MOOS database process (the MOOSDB) in a publish-subscribe
    manner. Each process may be executing its inner-loop at a
    frequency independent from one another and set by the
    user. Processes may be all run on the same computer or distributed
    across a network.}
\label{fig_moos}
\end{figure}

\vspace{0.1in}

The key idea with respect to facilitating code re-use is that
applications are largely independent, defined only by their interface,
and any application is easily replaceable with an improved version
with a matching interface. Since MOOS Core and many common
applications are publicly available along with source code under an
Open Source GPL license, a user may develop an improved module by
altering existing source code and introduce a new version under a
different name. With MOOS-IvP 13.2 which includes MOOS V10, the MOOS
libraries are distributed under an LGPL license, to allow the
development and use of commercial MOOS applications alongside open
source applications. The MOOSDB and MOOS applications remain under an
GPL license. The term MOOS Core refers to (a) the MOOSDB application,
and (b) the MOOS Application superclass that each individual MOOS
application inherits from to allow connectivity to a running MOOSDB.
Holding the MOOS Core part of the codebase constant between MOOS
developers enables the plug-and-play nature of applications.


%================================================================
\subsection{The Behavior-Based Control Design Philosophy and IvP Helm}
\label{sec_helm_design}

The IvP Helm runs as a single MOOS application and uses a
behavior-based architecture for implementing autonomy. Behaviors are
distinct software modules that can be described as self-contained mini
expert systems dedicated to a particular aspect of overall vehicle
autonomy. The helm implementation and each behavior implementation
exposes an interface for configuration by the user for a particular
set of missions. This configuration often contains particulars such as
a certain set of waypoints, search area, vehicle speed, and so on. It
also contains a specification of state spaces that determine which
behaviors are active under what situations, and how states are
transitioned. When multiple behaviors are active and competing for
influence of the vehicle, the IvP solver is used to reconcile the
behaviors (Figure \ref{fig_bhvarch}).

\vspace{0.15in}

\begin{figure}[htp]
  \centering 
  \includegraphics[width=.65\linewidth]{figures/helmarch-simple.png}
  \caption{{\bf The IvP Helm}: The helm is a single MOOS application
    running as the process pHelmIvP. It is a behavior-based
    architecture where the primary output of a behavior on each
    iteration is an IvP objective function.  The IvP solver performs
    multi-objective optimization on the set of functions to find the
    single best vehicle action, which is then published to the
    MOOSDB. The functions are built and the set is solved on {\em
      each} iteration of the helm - typically one to four times per
    second. Only a subset of behaviors are active at any given time
    depending on the vehicle situation, and the state space
    configuration provided by the user.}
\label{fig_bhvarch}
\end{figure}

\vspace{0.1in}

The solver performs this coordination by soliciting an objective
function, i.e., utility function, from each behavior defined over the
vehicle decision space, e.g., possible settings for heading, speed and
depth. In the IvP Helm, the objective functions are of a certain type
- piecewise linearly defined - and are called IvP Functions. The
solver algorithms exploit this construct to find a rapid solution to
the optimization problem comprised of the weighted sum of contributing
functions.

The concept of a behavior-based architecture is often attributed to
\cite{bro86}. Since then various solutions to the issue of action
selection, i.e., the issue of coordinating competing behaviors, have
been put forth and implemented in physical systems. The simplest
approach is to prioritize behaviors in a way that the highest priority
behavior locks out all others as in the Subsumption Architecture in
\cite{bro86}. Another approach is referred to as the potential fields,
or vector summation approach (See {\cite{ark87}}, \cite{kha85}) which
considers the average action between multiple behaviors to be a
reasonable compromise. These action-selection approaches have been
used with reasonable effectiveness on a variety of platforms,
including indoor robots, e.g., \cite{ark87}, \cite{acm93},
\cite{pir98}, \cite{rie99}, land vehicles, e.g., \cite{ros97}, and
marine vehicles, e.g., \cite{bl00}, \cite{cbr00}, \cite{ks01},
\cite{rwd02}, \cite{wndrd00}. However, action-selection via the
identification of a single highest priority behavior and via vector
summation have well known shortcomings later described in
\cite{pir98}, \cite{rie99} and \cite{ros97} in which the authors
advocated for the use of multi-objective optimization as a more
suitable, although more computationally expensive, method for action
selection. The IvP model is a method for implementing multi-objective
function based action-selection that is computationally viable in
the IvP Helm implementation.
</pre></body></html>