<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_memo_format}
%===================================================================

\begin{document}

\begin{labcover}
\labtitle{An Overview of the Mission Simulation Pipeline}
\vspace{0.1in}
\labdate{January 2022}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
%\labtoc{small}
\end{labcover}

\wikidoc{file=Memo.VVMissionPipeline}
\wikidoc{auth=mikerb@mit.edu}
\wikidoc{toc=false}


%==================================================================
\section{Components of the Automated Test Environment}
\label{sec_test_over}

While platform autonomy and the uField structure comprise the bulk of
test environment, there are a few other moving parts for automated
unsupervised simulations to proceed. These are conveyed in Figure
\ref{fig_test_env} below. The four elements in the shaded region
comprise a typical run on a physical vehicle. The elements in the
larger dashed box comprise a typical supervised multi-vehicle
simulation. The complete set of shown components enable the automated
batches of unsupervised simulations and reporting.

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.96\textwidth]{figures/test_environment.png}
  \caption{{\bf Automated Test Environment}: A nested structure of
    scripts, command-line interface (CLI) applications, and MOOS
    applications comprise the automated test architecture. Using this
    structure, mission launch, monitoring, evaluation, halting,
    analysis, and archiving and report generation, are automated and
    can be distribute across multiple machines.}
  \label{fig_test_env}
\end{figure}
\vspace{0.1in}

\noindent
Each of these components will be discussed in this document in the
following sections:

\begin{packed_itemize}
\item Platform autonomy. Section \ref{sec_platformai_over}.
\item Shoreside mission, a.k.a., the uField Toolbox. Sections \ref{sec_ufld_over}.
\item Mission launch scripts. Section \ref{sec_launch_scripts}.
\item Mission managament tools. Section \ref{sec_mission_mgt}.
\item Post mission tools. Section \ref{sec_post_mission}.
\item Launch script for unsupervised missions (\cmd{xlaunch}). Section \ref{sec_xlaunch}.
\item Health monitoring tools. Section \ref{sec_health}.
\item Automatic evaluation tools. Section \ref{sec_auto_eval}.
\end{packed_itemize}

\vspace{0.1in}
\noindent
The components in Figure \ref{fig_test_env} do not quite convey the
flow of a simulation, or the nested nature of the launch scripts
involved.  Figure \ref{fig_scripts} below makes this clearer. In a
normal supervised simulation, with the user interacting with a command
and control GUI deploy vehicles and assess the mission, the
\cmd{launch\_all.sh} script is invoked by the user which invokes a
launch script N times for each vehicle, and a launch script for the
shoreside MOOS community (recall Figure \ref{fig_ufield_autonomy}).
Many of the example missions distributed with the MOOS-IvP public
codebase contain this mission structure since this is the traditional
structure for launching a supervised mission.

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.92\textwidth]{figures/script_environment.png}
  \caption{{\bf Script Components}: Launch scripts are used for
    launching traditional supervised multi-vehicle missions. These can
    be invoked from within the \cmd{xlaunch} script for an unsupervised,
    headless mission that will be monitored and halted automatically. Batches
    of \cmd{xlaunch} invocations can be invoked from within a \cmd{zlaunch}
    script which will march through a set of pre-planned or randomly
    generated missions.}
  \label{fig_scripts}
\end{figure}
\vspace{0.1in}

\noindent
Supervised missions are launched with the \cmd{xlaunch} script. This script
will invoke the \cmd{launch\_all} script with the headless (no GUI) option
invoked. The \cmd{xlaunch} script will continually monitor the mission for
resolution or timeout, and then bring down all the processes involved in the
mission. The \cmd{xlaunch} script is also responsible for handling log file
archiving and reporting results to the target locations.

\vspace{0.1in}
\noindent
The \cmd{zlaunch} script is comprised of a batch of unsupervised
simulations, each invoked with \cmd{xlaunch}.  The batch may march
through several different types of missions, or the same mission with
varying configuration or seed parameters. Or \cmd{zlaunch} may simply
invoke the same mission many times with randomization applied within
lower level launch scripts.

\vspace{0.1in}
\noindent
What triggers the \cmd{zlaunch} script? The most obvious answer is
that it may be invoked by the user from the command line any time. For
automation, \cmd{zlaunch} could also be invoked as a \cmd{cron} job,
perhaps running all missions once per day.  It is also possible the
tie a \cmd{zlaunch} invocation(s) to each code commitment. 

\end{document}



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