Autonomous Sensing System Simulator

The LAMSS Autonomous Sensing System Simulator allows the user to exercise the mission level autonomy configuratio, using a suite of high-fidelity simulators of the 'outside world' of the MOOS-IvP autonomy system:

  • Acoustic Communication Networking
  • Environmental and Acoustic Sensors
  • Platform Dynamic Control

Mission Configuration and Launch

There are currently two active mission configuration trees, missions-lamss and missions-dsop, both structured in the same manner, but with differences in access, and details such as command and control messages, environments, and sensor configurations. The configuration trees are version-controlled using bzr, allowing the latest configuration tested in the simulator to be accurately copied into the actual vehicle via a simple update command (bzr up).

Field Deployment Mission Launch

To launch a mission on the actual vehicle, the user logs on to the payload computer and enters the payload autonomy directory, e.g. for the MIT Unicorn AUV. Assuming the payload computer has internet access to the bzr server, the following commands will launch the payload autonomy system:

> cd /opt/missions-lamss/auv/unicorn
> bzr up
> ./ switch1 switch2 ....

where 'switch1, switch2 etc.' are a set of optional switches, which are redefining the dwefault auv configuration, as described later.

Similarly, to launch the topside command and control,

> cd .../missions-lamss/topside
> bzr up
> ./ switchA switchB ....

Note here that there is no editing of mission or configuration files. Thus, all configuration changes must previously be implemented and tested in the simulation environment described below. Only configuration changes controlled by the switches are allowed in the runtime environment.

Simulated Mission Launch

The first step is to enter the mission directory on the simulation computer and configure the location and the environment for the mission, in LAMSS terminology the cruise. A number of earlier cruises are available as template for definition of new cruise environments. Once the cruise environment is defined, it is adopted globally by all vehicles, moorings, and the topside. For example, if the cruise definition is in the directory missions-lamss/cruise/mbat, it is activated by the command:

> cd .../mission-lamss ; ./ mbat \\

Next step is to start the topside command and control, with the commands:

> cd .../missions-lamss/topside \\

> ./ switchA switchB ....
To launch the web-based command and control GUI, 'goby_liaison', use the browser to connect to URL http://localhost:50001.

Next enter the vehicle directory, e.g. for Unicorn:

> cd .../missions-lamss/auv/unicorn
If not already configured, the sonar configuration is activated, e.g. for the durip towed array:

> ./ durip
The simulated Unicorn is now launched using the command:

> ./ switch1 switch2 ....

Configuration Switches

The configuration switches fall into different categories:

Global: Switches which apply to all vehicles and network nodes, including the topside command and control. The most important switches in this category concerns the communication networking. They must be used consistently on all nodes in the network.
Vehicle: These switches are in general specific to a particular autonomous vehicle node or platform class, e.g. an AUV, a glider or an array mooring. They are common to the simulation and runtime launch, and include e.g. switches controlling which sensor processing modules are activated.
Simulator: these switches apply to MOOS communities representing sensor actuator systems, usually used for stimulating sensor processing modules running on target hardware.
Topside: Switches unique to the topside command and control.

Each of the categories include switches that are used exclusively in simulations and or in runtime, but most can be used in either situation, yielding an important flexibility in regard to performing simulations with hardware-in-the-loop (HITL), or for running in-water missions replacing defective hardware with their simulated equivalent.

Global Switches

'goby1: Use Goby-1.0 in stead of the default goby-2.0 for the communication infrastructure. Note that this will require using the iCommander command console instead of the goby-liaison described below.
hw_modem: Use HITL micromodems, directly attached to serial ports on the computer. This is default in the runtime situation.
tcp_modem: Use the LAMSS micromodem pool via TCP-IP. Provides HITL for up to four nodes, providing no one else is using it.
ufld: Used the MOOS-IvP uField toolbox for emulating a multinide communication environment. Replaces the default legacy network simulator iModemSim, compared to which it provides a number of advantages, most importantly the capability top simulate the network in warped time.
poll: Use centrally polled MAC scheme for TDMA network control. This uis the default for the topside community. Note that only one node can be controlling the centralized polling. Therefore all other nodes must use the default mac_none.
fixed_mac: De-centralized, fixed MAC scheme. When applied, it must be used on all nodes.
slotted_mac: De-centralized MAC scheme with auto-discovery. When applied, it must be used on all nodes.
warp=xx: Specifies a time-warp factor.
quiet: Force all MOOS processes to route their output to /dev/null, i.e. producing no terminal output. This is the default in the runtime environment, and useful when operating target hardware in the simulator.

Topside Switches

bridge_messages: Uses pMOOSBridge to bridge all outgoing messages to another network node. Used e.g. for operating an autonomous surface craft as a mobile communication gateway.
ship: Activates pHelmIvP in the topside MOOS community, allowing the topside to be simulated as operated from an R/V. This feature is used e.g. for simulation collision avoidance scenarios between a network node and a maneuvering R/V. The 'ship' is commanded via the standard ASC command set.
hitl: The payload autonomy system is operated on a separate computer system, e.g. the target vehicle hardware. Forces the uField network simulator to operate in the network containing the target hardware.

Vehicle Switches

passive: Activates the passive sonar processing chain. If in simulation mode also starts the passive sonar simulator modules, unless the sensorsim switch is set, in which case the sonar simulator is run in a separate MOOS community, commonly on a separate computer.
bearingsim: Low-fidelity passive sonar simulator, generating contact reports with bearings to simulated target fields. Replaces the high-fidelity passive sonar simulator uSimPassiveSonar and the signal processing modules pBeamformer and pBearingTrack. Intended for use in time-warped network simulations with the full platform autonmy system, or for emulating a passive sonar on an AUV in the field.
active: Activates the active sonar processing chain and the active sonar simulator processes.
active_proc: Activates the active sonar control and processing chain, but NOT the active sonar simulator modules, which are to be operated in a separate MOOS community. This switch is used when running the autonomy system on the target hardware.
contactsim: Medium-fidelity active sonar contact simulator, generating contact reports with travel time and bearing to simulated target fields. Replaces the high-fidelity active sonar simulator uSimActiveSonar and the signal processing module pActiveSonarProcess. Intended for use in time-warped network simulations with the full platform autonomy system, and for emulating an active sonar on an AUV in the field.
mseas: Use the high-fidelity environmental fields generated by MSEAS, rather than the default databases for bathymetry and CTD simulation.
sensorsim: Used together with passive and active_proc to set up pMOOSBridge link to the MOOS community containing all sensor simulation processes.
frontseatsim: Disables all vehicle dynamics simulation processes, which are instead assumed to be executed in a separate 'frontseat' community.
usm: Use the generic vehicle dynamics simulator uSimMarine instead of the default uMVSBluefin. It is used as default for time-warped simulations.
gumstix: used when the payload autonomy is run on the target hardware, e.g. a Gumstix or BeagleBoard computer. This will configure the autonomy system for the proper IP addresses for the target hardware and the host computer running the frontseat and sensor simulators.
auto_target: Auto-generates a command for launching a simulated target, the kinematics of which is defined in missions-dsop/cruise/current/cruise.def.
sonar_start: Starts the active sonar at launch by auto-generating a Sonar_Control DCCL command. The sonar setting is defined in array_plugs/array.def in the vehicle directory.

Simulator Switches

auv=: Specifies which vehicle the simulation environment shoulkd be configured for.
passive: Activates the passive sonar simulator modules.
active: Activates the active sonar simulator processes.
frontseatsim: Disables the simulation of the standard navigation sensor such as altimeter and GPS, which are instead assumed to be performed in a separate 'frontseat' community.
hitl: The payload autonomy system is operated on a separate computer system, e.g. the target vehicle hardware. Activates the logic transferring simulated sensor data to the target hardware.
mseas: Use the high-fidelity environmental fields generated by MSEAS, rather than the default databases for bathymetry and CTD simulation.

Simulator Examples

Massachusetts Bay Autonomy Testbed - MBAT

To simulate autonomy missions with the R/V Resolution and the AUV Macrura towing the DURIP array, and Unicorn with an onboard passive sonar simulator:

Set cruise environment:

> cd missions-dsop
> ./ mbat
Start topside:

> cd ../topside
> ./ ufld ship
Start Macrura:

> cd ../auv/macrura
> ./ durip
> ./ ufld passive

Start Unicorn:

> cd ../auv/unicorn
> ./ durip
> ./ ufld bearingsim

Unicorn with Active Sonar Contact Simulator and Synchronization with ACOMMS

Start topside:

> cd ../topside
> ./ ufld fixed_mac
Start Unicorn:

> cd ../auv/unicorn
> ./ mfa16
> ./ ufld fixed_mac contactsim

Unicorn Autonomy and Active Sonar on Gumstix

To simulate autonomy missions with Unicorn equipped with an active sonar, with the autonomy system running on a gumstix connected to a host computer via LAN (

Start topside:

> cd .missions-dsop/topside
> ./ ufld hitl

Start frontseat simulator, conveniently on different desktop:

> cd missions-dsop/auv/frontseat_sim
> ./ hitl auv=unicorn

Start active sonar and environmental sensor simulators, conveniently on separate desktop:

> cd missions-dsop/auv/sensor_sim
> ./ active hitl frontseatsim auv=unicorn

Finally, on the Gumstix, start the platform autonomy system, without sensor and frontseat simulators:

> cd /opt/missions-dsop/auv/unicorn
> ./ quiet gumstix ufld sensorsim frontseatsim active_proc