1. MOOS-IvP Missions

A MOOS-IvP mission refers to a selection of software packages and configuration
options, to be run on one or more real or simulated robots, and on one or more
command-and-control computers, to achieve a set of objectives under certain
contraints. 

The mission artifacts are comprised of (a) configuration files for MOOS applications
and helm behaviors (b) a set of set of launch scripts for starting the MOOS-IvP
software across all vehicles and the command-and-control computer.

This document describes the core patterns for structuring missions, from (a) the simplest
one-vehicle mission in simulation, to (b), a mission with an arbitrary number of vehicles,
with simple switches for running the mission on multiple robots in the field, running
multiple simulated robots on a single computer, or a simulation distributed over 100 or
more computers.

1.1 Assumed Background
------------------

This documnent assumes that the reader is familiar with:

o The general idea of MOOS apps as a group distinct applications
(processes), communicating through a special app called the MOOSDB
(MOOS database).

o MOOS apps communicating in a publish-subscribe manner through the
MOOSDB. 

1.2 Topics Covered

o A MOOS Community

o Methods for launching mission with one or more MOOS communities

o MOOS Mission file and Helm Behavior file structure

o Dynamic Construction of Mission and Behavior files at launch time.




that can be run in the field and 

Missions and their artifacts can be constructed with and endless set of possible
configurations for possible missions. However

In this document, 

is a collection of MOOS apps and IvPHelm behaviors

Introduction

In this 



o A MOOS community

Launching a MOOS community

o Manually
o Using pantler
  - pAntler block
  - config blocks
o Using a launch script
o More advanced methods (xlaunch, zlaunch)

B. The uField architecture

o Even if one vehicle, there is shoreside and vehicle
o With multiple vehicles, one shoreside, multiple vehicles
  Not technically restricted to one shoreside, but usually one C&C
o Sharing MOOS vars between communities
  o Introduce pShare
  o The qbridge concept FOO_ALL, FOO_NAME
  o The NODE_MESSAGE structure
o uFld has tools for setting up the configuration