<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}

%=================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%=================================================================

\begin{document}

\begin{labcover}
\labtitle{Launching MOOS Processes and Mission Scripts with pAntler}
\vspace{0.1in}
\labauth{Paul Newman, Oxford}
\vspace{0.1in}
\labtoc{small}
\end{labcover}

\wikidoc{file=IvPTools.PAntler}
\wikidoc{auth=Paul Newman}

%=================================================================
\section{Overview}
%=================================================================

This section discusses how to use the application \app{pAntler} to
launch multiple MOOS processes. This is useful tool for starting up a
set of processes all of which share a single configuration file.  The
process \app{pAntler} is used to launch/create a MOOS community. It is
simple to use and Post V7.0.2 very extensible.  One of the ideas
underlying MOOS is the one mission file one mission paradigm. A single
mission file contains all the information required to configure all
the processes needed to undertake the task (mission) in hand.  (The
\app{pLogger} application backs up each mission file so the user can
discern exactly what mission file was run at the time data was
recorded - this is described in the \app{pLogger} documentation).
Note a collection of MOOS processes is commonly referred to as a {\em
  community}.

%=================================================================
\section{Basic Syntax}
%=================================================================

\app{pAntler} provides a simple and compact way to start a MOOS
mission. For example if the desired mission file is \var{Mission.moos}
then the following would launch the required processes/community for
the mission:

\vspace{0.1in}
\begin{consoleverb}
  pAntler Mission.moos
\end{consoleverb}
\vspace{0.1in}

\noindent
It reads from its configuration block {\em (which is declared as
\pvar{ProcessConfig=ANTLER})} a list of process names that will
constitute the MOOS community. Each process to be launched is specfied
with a line with the general syntax:

\vspace{0.1in}
\begin{fileverb}
  Run = procname [ @ LaunchConfiguration] [~ MOOSName]
\end{fileverb}
\vspace{0.1in}


\noindent
where LaunchConfiguration is an optional comma separated list of
"parameter=value" pairs which collectively control how the process
"procname" (for example \app{iGPS}, or \app{iRemote} or
\app{MOOSDB}) is launched. Exactly what parameters can be specified is
detailed later in the document. \app{pAntler} looks through its entire
configuration block and launches one process for every line which
begins with \var{RUN=}. When all processes have been launched
\app{pAntler} waits for all of them to exit and then quits itself.

%=================================================================
\section{Controlling Process Launch}
%=================================================================

Immediately after the "@" symbol in a \var{RUN} directive the user
can supply a list of "parameter=value" pairs (comma separated) which
control how the process in question should be launched. The following
subsections will explain the action of available parameters.


%=================================================================
\subsection{Launching Processes in new console windows (or not)}

\prevblue
\begin{verbatim}
 Run = MOOSDB  @NewConsole = true
\end{verbatim}
\postverb

The optional \pvar{NewConsole} parameter specifies whether the named
process should be launched in a new window (an xterm in Unix or
cmd-prompt in Win32 derived platforms). By default a new console is
launched.

%=================================================================
\subsection{Controlling Console Appearance}
\label{Sec:Appearance}

Post V7.0.2 releases allow a good deal of control over the appearance
of the windows in which processes will be launched. Especially so on
the 'nix side of life. (The native win32 console has less flexibility
than the xterm. Deep apologies for Win32 users who may feel hard done
by by the asymmetry here.)

By specifying \var{XConfig=&lt;Name&gt;} or \var{Win32Config=&lt;Name&gt;}
(depending on OS) the user can have \app{pAntler} apply customisations
to the new console in a process is launched. For example:

\prevblue
\begin{verbatim}
  Run = MOOSDB  @NewConsole = true,XConfig=DBXConsoleSettings,  \ 
                              Win32Config=DBW32ConsoleSettings
\end{verbatim}
\postverb

\noindent
will cause \app{pAntler} to search through its configuration block to
find a line which begins with \pvar{DBXConsoleSettings =}. or
\pvar{DBW32ConsoleSettings =} -- depending on OS). What is the left of
the equality determines the appearance of the new console and is a
function of the host operating system.

%=================================================================
\subsection*{Console Appearance in Unix like OS's}

In unix derived operating systems the appearance string (referenced by
"XConfig") is a comma separated list of parameters that would be used
to configure an xterm. So continuing by way of the DBConsoleSettings
example. If the DBConsoleSettings was specified (on its own line) as
follows

\prevblue
\begin{verbatim}
  DBXConsoleSettings = -bg,#FF0000,-fg,#FFFFFF,-geometry,80x12+2+00,+sb,-T,TheMOOSDB
\end{verbatim}
\postverb

\noindent
then the MOOSDB would be launched in 12 rows by 80 columns window,
white text on red at the top left of teh screen. The string
"TheMOOSDB" would appear in the title. Note any xterm configuration
parameters can specified in this way. See the manual page for xterm
for information on the options allowed.

%=================================================================
\subsection*{Console Appearance in Win32 OS's}
The only native WIN32 console options supported control the background
color of the terminal (text is always white). The LHS of the
configuration line (referenced by "Win32Config") can contain a comma
separated list of \var{BACKGROUND\_RED} \var{BACKGROUND\_BLUE} and
\var{BACKGROUND\_GREEN}. The following would produce a white on red
win32 console:

\prevblue
\begin{verbatim}
  DBW32ConsoleSettings = BACKGROUND_RED
\end{verbatim}
\postverb

%=================================================================
\subsection{Appearance Example}

\vspace{0.1in}
\begin{listing}{An example Antler configuration block}
\label{antler_config}
\footnotesize
\begin{verbatim}
 1  //------------------------------------------------------------------
 2  // pLogger configuration block
 3  ProcessConfig = Antler
 4  {
 5    // look on system path
 6    ExecutablePath = system
 7    
 8    // launch a DB
 9    Run = MOOSDB  @NewConsole = true,XConfig=DBXConsoleSettings,Win32Config=DBW32ConsoleSettings
10  	
11    // xterm configuration for DB
12    DBXConsoleSettings = -bg, \#FF0000,-fg,\#FFFFFF,-geometry,80x12+2+00,+sb,-T,TheMOOSDB
13  
14    // Win32 Configuration for DB
15    DBW32ConsoleSettings = BACKGROUND_RED	
16  }
\end{verbatim}
\normalsize
\end{listing}

%=================================================================
\subsection{Controlling Search Paths}

Post V7.0.2 \app{pAntler} offers extended functionality regarding
specifying how executables are located on the host file system. The
paths which you wish the OS to use when searching for executable to
launch can be specified globally (a common path for all processes) or
on a process by process basis.

%=================================================================
\subsection*{Specifying Global Executable Paths}
\label{Sec:ExecPath}

Adding line of the form

\vspace{0.1in}
\begin{moosfileverb}
  ExecutablePath = path
\end{moosfileverb}
\vspace{0.1in}

\noindent
to Antler's configuration block where {\em path} is a suitable path
string, will make \app{pAntler} search in that place for the
exectables to launch. Not specifying this variable or setting path to
"SYSTEM" will cause Antler to relie on the host OS being able to
locate the executable in its own executable paths.

%=================================================================
\subsection*{Specifying Paths for an Individual Process}

The global executable path (default "system") can be overridden for a
particular process by providing your prefered path in the "RUN"
directive line. For example:

\vspace{0.1in}
\begin{moosfileverb}
 Run = pP1 @  NewConsole = true,path=/usr/strangeplace
\end{moosfileverb}
\vspace{0.1in}

\noindent
will try to launch a process called "pP1" from a the directory
"/usr/strangeplace".  Such process specific path directives overide
any path set with \var{ExecutablePath=...} (Section
\ref{Sec:ExecPath}).

%=================================================================
\section{Passing Parameters to Launched Processes}
%=================================================================
\label{Sec:ExeParameters}

%=================================================================
\subsection{The Two Default Parameters}

Unless told otherwise (see \ref{Sec:Inhibit}) each process launched is
passed the mission file name as a command line argument and also the
name it should use to register with the MOOSDB. This means that by
default \var{argv[1]} of \var{main} is the name of the mission file
currently in play (the one which \app{pAntler} is itself reading) and
argv[2] is the name of the process in to be launched (for example
\app{iGPS} or \app{pLogger}). By default pAntler assumes the name
which a process will be registering with the MOOSDB with is the name
of the process itself. For example \app{pLogger} will register with
the MOOSDB with the name "pLogger". However this can be changed using
the \var{~ MOOSName} syntax:

\vspace{0.1in}
\begin{moosfileverb}
 Run = iGPS  @NewConsole = true ~ GPS_A
\end{moosfileverb}
\vspace{0.1in}

\noindent
The above will cause the executable \app{iGPS} to be launched in a new
console but (because iGPS handles command line parameters
appropriately) it will register with the \app{MOOSDB} under the name
of "GPS\_A".

%=================================================================
\subsection{Handling default parameters}
Of course just passing the MOOSName to a process doesn't mean
automagically that all MOOS connections within that process will use
this name. Supporting code must be provided. 

%Listing \ref{Code:Argv}
%illustrates just one way in which this can be done.

%\lstinputlisting[ caption = {Handling default command line
%parameters. Note how the MOOSName and Mission file are passed to the
%CMOOSApp derived object.},label = {Code:Argv} ]{../code/main.cpp}
 
%=================================================================
\section{Running Multiple Instances of a Particular Process}
%=================================================================

As already described in Section \ref{Sec:ExeParameters}, the optional
\var{MOOSName} parameter allows MOOSProcesses to connect to the
\app{MOOSDB} under a specified name. Why is this useful? Well for
example a vehicle may have two GPS instruments onboard. Now by default
\app{iGPS} may register it existence with the \app{MOOSDB} under the
name \app{iGPS}. This name is now taken and no other MOOSClient can
use the name "iGPS" - if they try the MOOSDB will not accept them into
the fold. By using the \var{~} syntax multiple instances of the
executable \app{iGPS} can be run but with each connecting to a the
\app{MOOSDB} using a different name. For example:

\vspace{0.1in}
\begin{moosfileverb}
 Run = iGPS @ NewConsole = true ~iGPSA
 Run = iGPS @ NewConsole = true ~iGPSB
\end{moosfileverb}
\vspace{0.1in}

\noindent
would launch two instances of \app{iGPS} registering under "iGPSA" and
"iGPSB" respectively. Note there would need to be two GPS
configuration blocks in the mission file -- one for each and the
process names (RHS of \var{ProcessConfig=}) would be "iGPSA" and
"iGPSB"

%=================================================================
\subsection{Customising the Command Line Parameters Passed to a Launched Process}
%=================================================================


But what if your beloved new process which you desire \app{pAntler} to
launch requires extra command line configuration? Or what if you don't
want \app{pAntler} to pass the Mission file name and the MOOS name in
a parameters? Fear not, just read on.

%=================================================================
\subsection{Specifying Additional Process Command Line Parameters}

You can specify additional parameters which should be passed to a
launched process using a syntax similar to that used to specify
console appearance (see Section \ref{Sec:Appearance}) The trick is to
specify the name of a parameter string (R.H.S of a
\pvar{ExtraProcessParams=...} in the process's \pvar{RUN} directive
line. \app{pAntler} the rescans its configuration block looking for
this named string which must be a comma separated list of
parameters. An example will make this blindingly obvious.

\vspace{0.1in}
\begin{moosfileverb}
  ProcessConfig = Antler
  {
    Run = iProcA @ NewConsole = true,path=/usr/local/bin, ExtraProcessParams=ProcAParams 
    ProcAParams =-o,--verbose,--clever
  }
\end{moosfileverb}
\vspace{0.1in}

\noindent
The above would launch a process called \app{iProcA} in a new console,
(with default appearance as no appearance string is specified see
Section \ref{Sec:Appearance}), and the process will be passed
{\em six} parameters at launch time:

\begin{packed_enumerate}
\item \var{argv[0]}: the executable image name. 
\item \var{argv[1]}: the mission file name
\item \var{argv[2]}: the process's MOOS name
\item \var{argv[3]}: -o
\item \var{argv[4]}: --verbose
\item \var{argv[5]}: --clever
\end{packed_enumerate}

%=================================================================
\subsection{Inhibiting default parameters and Launching Arbitrary (non-MOOS) Processes}
\label{Sec:Inhibit}

If you want to launch a process with \app{pAntler} that has not been
designed to handle the mission file name an MOOS name as the first two
parameters passed in the command line then it is possible to tell
\app{pAntler} not to pass these parameters. This is done using the
\pvar{InhibitMOOSParams} key word. For example if you wanted to launch
the executable \cmd{top} in its own window you would use
a configuration similar to:

\vspace{0.1in}
\begin{moosfileverb}
 Run = top @ InhibitMOOSParams=true, NewConsole=true
\end{moosfileverb}
\vspace{0.1in}
 
%=================================================================
\section{Distributing a Community over Multiple Machines}
%=================================================================


%=================================================================
\subsection{Motivation}

Up until now we have implicitly assumed that all processes launched by
a single instance of \app{pAntler} reside on the same physical
computer. Surely this is conflicts with the idea that any MOOS process
can run on any machine under any (common) OS? You're right it does and
this issue has been addressed in post V7.0.2 versions. Excellent. In
the broadest of terms it is possible to have have one Antler send a
single mission file to a host of other Antlers (presumably but not
necessarily sitting on a different machine or OS) which they then
process and launch processes locally. The idea is that you still only
need to edit one mission file to control a suite of processes running
over any number of physical machines. The operating paradigm is that
once a suitably configured \app{pAntler} has been started on a machine
you need never kill or restart it. It stays alive patiently waiting
for a instructions. See Figure \ref{Fig:Distributed}

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.65\textwidth]{figures/antler_distributed.png}
  \caption{In distributed mode, \app{pAntler} can be started in one of
    two ways. Here on the machine lisa1.robots.ox.ac.uk it is started
    in "Top MOOS" mode with the name of a mission file on the command
    line. On the two other machines (lisa2 and lisa3) Antler is
    started in headless mode receiving three command line parameters -
    the machine name on which a \app{MOOSDB} can be found, the port
    that \app{MOOSDB} is serving on and an AntlerID name which in this
    case is simply set to the machine name. When the "topMOOS" has
    spawned its processes it pushes the mission file to the DB. The
    headless Antlers pick up this notification and run themselves from
    the newly received Mission file. Each headless Antler only
    launches processes which have a Run directive line containing that
    particular instantiation of Antler's ID.}
\label{Fig:Distributed}
\end{figure}

%=================================================================
\subsection{Antler Modes: Monach and Headless}

The idea is that \app{pAntler} can be run in one of two modes which we
shall refer to as "headless" and "monach" (as in Monach of the Glen -
referring to the size antlers). These terms only have meaning if the
\pvar{EnableDistributed} flag is set to \var{true} in the Antler
configuration block -- ie when Antler is being told to support
distributed process control. If this flag is set and \app{pAntler} is
launched in the usual way:

\vspace{0.1in}
\begin{consoleverb}
 ./pAntler Mission.moos
\end{consoleverb}
\vspace{0.1in}


\noindent
then this will become a "Monach". Think of it as
king/governing/top/controlling \app{pAntler} which will take
responsibility for distributing (via the \app{MOOSDB}) the mission
file to any other "headless" Antlers sitting on other machines.  If
however you start \app{Antler} with three command line parameters as
follows

\vspace{0.15in}
\begin{consoleverb}
  ./pAntler lisa1.robots.ox.ac.uk 9000 lisa2
\end{consoleverb}
\vspace{0.15in}

\noindent
then Antler will launch in "headless" mode. Headless \var{Antlers} are
bound to a single "Monachs" via a \app{MOOSDB} (which will usually be
lauched by the monach itself). The three parameters specify the
location and port of this \app{MOOSDB} and alls an
\var{AntlerID}. This last parameter is a string which is used by
headless Antlers to figure out which Run directives they should
execute. Consider the following simple example:

\vspace{0.1in}
\begin{fileverb}
 ProcessConfig = Antler
 {
   EnableDistributed = true
   Run = iProcA @ AntlerID = lisa2, NewConsole = true	
   Run = MOOSDB @ NewConsole=true
 }
\end{fileverb}
\vspace{0.1in}


Note how \app{iProcA} has an \var{AntlerID} specified. Now if as above
one started a headless \app{pAntler} with "lisa2" as its Antler ID on
machine "B" and then started another instance of \app{pAntler} on
machine "B". (A can equal B but whats the point?) but this time only
specifying a mission file (ie start \app{pAntler} as a "monach") you
would witness a \app{MOOSDB} coming up on machine A and \app{iProcA}
starting on machine B. If no \var{AntlerID} is specified in a run
directive, it is assumed that the monach is required to process the
directive. Headless Antlers only process run directives possessing an
\var{AntlerID} matching their own. Each headless Antler writes the
runtime received mission file (stripped of comments and superfluous
white space) to local disk (working directory) under the name
\var{dynamic\_&lt;TIMESTAMP&gt;.moos} for future perusal.

%=================================================================
\subsection*{Shutdown Behaviour}

The default behaviour is for headless Antlers to shut down all their
spawned processes when contact is lost with the MOOSDB. If this is not
the desired behaviour and you want launched processes to carry on
running simply add the directive \var{"KillOnDBDisconnect=false"} to
the configuration block.

\vspace{0.01in}
\begin{fileverb}
 ProcessConfig = Antler
 {
   EnableDistributed = true
   KillOnDBDisconnect=false
   Run = iProcA @ AntlerID = lisa2, NewConsole = true	
   Run = MOOSDB @ NewConsole=true
 }
\end{fileverb}
\vspace{0.01in}

\noindent
In any case as soon as a Mission file is received by a headless Antler
any and all running processes will be shutdown before processing the
new Mission file.

%=================================================================
\section{Examples}
%=================================================================

If you enable the building of examples via the CMake build screen (See
Figure \ref{Fig:Build}) then the example configurations in Sections
\ref{Sec:Local} and \ref{Sec:Distrib} serve as a good starting point
in experimenting with \app{pAntler}.  There are three examples
processes supplied in the sibling code directory of the documentation:

\begin{packed_enumerate}
\item \var{pAnterTestAppA} is nothing more than a dumb CMOOSApp that
  prints a string declared in its configuration block
\item \var{pAnterTestAppB} is nothing more than a dumb CMOOSApp which
  takes more than the standard two command line arguments, it uses these
  additional params to publish a variable to a MOOSDB
\item \var{pAnterTestAppC} is not a CMOOSApp. its just a program which
  prints out its command line arguments and spins in a do nothing loop.
\end{packed_enumerate}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.75\textwidth]{figures/antler_buildexample.png}
\caption{selecting the building of examples in the MOOS build screen}
\label{Fig:Build}
\end{figure}

%=================================================================
\subsection{Local Configurations}
\label{Sec:Local}

\begin{listing}{Example Configuration Blocks for Antler where all process are run on the same host machine.}
\label{antler_config}
\footnotesize
\begin{verbatim}
// Un-Comment/Comment the first line of each each example block
// to play with various Antler configurations

// Simplest possible example
// ProcessConfig = Antler
{
  Run = MOOSDB @ NewConsole = true
  Run = pAntlerTestAppA @ NewConsole = true
}

// Run two instances of pAntlerTestAppA under different names
// note two new configuration blocks are needed (Oxford and FenTech)
// ProcessConfig = Antler
{
  Run = MOOSDB @ NewConsole = true
  Run = pAntlerTestAppA @ NewConsole = true  ~ Oxford
  Run = pAntlerTestAppA @ NewConsole = true ~ FenTech
}


// Passing an additional two parameters to pTestAppB
// ProcessConfig = Antler
{
  Run = MOOSDB @ NewConsole = true
  Run = pAntlerTestAppA @ NewConsole = true
  
  Run = pAntlerTestAppB @ ExtraProcessParams = BParams , NewConsole = true
  BParams = CustomVar,ThisIsAString
}


// Specifying a default executable path and overloading it for MOOSBD
// ProcessConfig = Antler
{
  ExecutablePath  = C:/codescratch/MOOS/MOOSBin/debug/q
  Run = MOOSDB @ path=C:/codescratch/MOOS/MOOSBin/debug, NewConsole = true
  Run = qq @ NewConsole = true
}


// Passing three parameters to pTestAppC which is not expecting the first
// two parameters to be Mission File and MOOSName
// ProcessConfig = Antler
{
  Run = MOOSDB @ NewConsole = true

  Run = pAntlerTestAppA @ NewConsole = true
  
  Run = pAntlerTestAppB @ ExtraProcessParams = BParams , NewConsole = true
  BParams = CustomVar,ThisIsAString
  
  Run = pAntlerTestAppC @ ExtraProcessParams = CParams, InhibitMOOSParams=true, NewConsole = true
  CParams = set,the,moos,loose,1,2,3,45.6
}

// Adding some colour to MOOSDB, pAntlerTestB and pAntlerTestC
// ProcessConfig = Antler
{
  Run = MOOSDB @Win32Config=DBWin32,XConfig=DBX , NewConsole = true
  DBX = -bg,#FF0000, -geometry, 80x40+200+300
  DBWin32 = BACKGROUND_RED
  
  Run = pAntlerTestAppA @ NewConsole = true
  
  Run = pAntlerTestAppB @ Win32Config=BWin32,XConfig=BX, ExtraProcessParams = BParams, \
        NewConsole = true
  BParams = CustomVar,ThisIsAString
  BWin32 = BACKGROUND_GREEN,BACKGROUND_BLUE
  BX = -bg,#00FFFF, -geometry, 80x40+350+300
  
  Run = pAntlerTestAppC @ Win32Config=CWin32,XConfig=CX,ExtraProcessParams = CParams, InhibitMOOSParams=true , NewConsole = true
  CParams = set,the,moos,loose,1,2,3,45.6
  CWin32 = BACKGROUND_RED,BACKGROUND_BLUE
  CX = -bg,#FF00FF, -geometry, 80x40+400+300
}


// Configuration for TestAppA - just looks for a string to print
ProcessConfig = pAntlerTestAppA
{
  PrintThis = SetTheMOOSLoose
}

// Configuration for pTestAppB  - nothing but it expects a third and fourth
// command line tell it what to publish...
// ProcessConfig = pAntlerTestAppB
{

}

// Configuration for FenTech (which is actually  and instantiation of
// pAntlerTestAppA) - just looks for a string to print
ProcessConfig = FenTech
{
  PrintThis = ThisIsTestAppAAsFenTech
}

// Configuration for Oxford (which is actually  an instantiation of
// pAntlerTestAppA) - just looks for a string to print
ProcessConfig = Oxford
{
  PrintThis = ThisIsTestAppAAsOxford
}
\end{verbatim}
\end{listing}
\normalsize

%=================================================================
\subsection{Distributed Configuration}
\label{Sec:Distrib}

\vspace{0.1in}
\begin{listing}{Example Configuration Blocks for Antler where all processes are run on different hosts}
\label{antler_config_c}
\footnotesize
\begin{verbatim}
 1  // If you are really running this on different hosts make sure you 
 2  // set the server hostname below if you are simply testing how to run 
 3  // multipls instances of MOOS leaving it as local host is just fine
 4  
 5  ServerHost = localhost
 6  ServerPort = 9000
 7  
 8  // Adding some colour to MOOSDB, pAntlerTestB and pAntlerTestC
 9  ProcessConfig = Antler
10  {
11    EnableDistributed = true
12    Run     = MOOSDB @ Win32Config=DBWin32,XConfig=DBX , NewConsole=true
13    DBX     = -bg,#FF0000, -geometry, 80x40+200+300
14    DBWin32 = BACKGROUND_RED
15         
16    Run     = pAntlerTestAppA @ AntlerID=jupiter, NewConsole=true
17      
18    Run     = pAntlerTestAppB @ AntlerID=neptune, Win32Config=BWin32, \
19              XConfig=BX, ExtraProcessParams=BParams , NewConsole=true
20    BParams = CustomVar, ThisIsAString
21    BWin32  = BACKGROUND_GREEN,BACKGROUND_BLUE
22    BX      = -bg,#00FFFF, -geometry, 80x40+350+300
23      
24    Run     = pAntlerTestAppC @ Win32Config=CWin32, XConfig=CX, \
25              ExtraProcessParams=CParams, InhibitMOOSParams=true , NewConsole=true
26    CParams = set, the, moos, loose, 1, 2, 3, 45.6
27    CWin32  = BACKGROUND_RED,BACKGROUND_BLUE
28    CX      = -bg, #FF00FF, -geometry, 80x40+400+300
29  }
30      
31  // Configuration for TestAppA - just looks for a string to print
32  ProcessConfig = pAntlerTestAppA
33  {
34    PrintThis = SetTheMOOSLoose
35  }
36      
37  // Configuration for pTestAppB  - No params here, but it expects
38  // a third and fourth command line argument, a variable and string.
39  ProcessConfig = pAntlerTestAppB
40  {
41  }
42     
43  // Configuration for pTestAppC  - No params here, but it expects
44  // eight additional command line arguments
45  ProcessConfig = pAntlerTestAppB
46  {
47  }
\end{verbatim}
\end{listing}
\normalsize

%=================================================================
\section{Application note : I/O Redirection - Deployment} 
%=================================================================

Frequently \app{iRemote}, displayed on a remote machine, will be the
only interface a user has to the MOOS community.  We must ask the
question - "where does all the IO from other processes go to prevent
I/O blocking?". One answer to this is I/O redirection and
backgrounding MOOS processes - a simple task in unix derived systems
(Some OS are good for development others for running.)  Running
\app{pAntler} in the following fashion followed by a manual start up
of \app{iRemote} is the recommended way of running MOOS in the field
on a `nix platform.

\vspace{0.1in}
\begin{consoleverb}
 ./pAntler mission.moos &gt; ptyZ0 &gt; /dev/null &amp;
 ./iRemote mission.moos
\end{consoleverb}
\vspace{0.1in}

This redirection of \app{iRemote} is encapsulated in the \var{moosbg}
script included with the MOOS installations. In the case of an AUV the
interface can only be reached through in-air wireless communications,
which will clearly disappear when the vehicle submerges but will
gracefully re-connect when surfacing (not so easy to do with a PPP or
similar link).

\end{document}



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