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
> ./runtime_launch.sh 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
> ./runtime_launch.sh 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 ; ./cruise_config.sh mbat \\
Next step is to start the topside command and control, with the commands:
> cd .../missions-lamss/topside \\
> ./simulation_launch.sh 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:
> ./array_config.sh durip
The simulated Unicorn is now launched using the command:
> ./simulation_launch.sh switch1 switch2 ....
The configuration switches fall into different categories:
: 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.
: 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
launch, and include e.g. switches controlling which sensor processing modules are activated.
: 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.
: 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.
: Use HITL micromodems, directly attached to serial ports on the computer. This is default in the runtime
: Use the LAMSS micromodem pool via TCP-IP. Provides HITL for up to four nodes, providing no one else is using it.
: 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.
: 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
: De-centralized, fixed MAC scheme. When applied, it must be used on all nodes.
: De-centralized MAC scheme with auto-discovery. When applied, it must be used on all nodes.
: 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.
: 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.
: 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.
: 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.
: 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
. 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.
: Activates the active sonar processing chain and the active sonar simulator processes.
: 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.
: 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.
: Use the high-fidelity environmental fields generated by MSEAS, rather than the default databases for bathymetry and CTD simulation.
: Used together with passive
to set up pMOOSBridge link to the MOOS community containing all sensor simulation processes.
: Disables all vehicle dynamics simulation processes, which are instead assumed to be executed in a separate 'frontseat' community.
: Use the generic vehicle dynamics simulator uSimMarine
instead of the default uMVSBluefin
. It is used as default for time-warped simulations.
: 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-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.
: Specifies which vehicle the simulation environment shoulkd be configured for.
: Activates the passive sonar simulator modules.
: Activates the active sonar simulator processes.
: 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.
: 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.
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
> ./cruise_config.sh mbat
> cd ../topside
> ./simulator_launch.sh ufld ship
> cd ../auv/macrura
> ./array_config.sh durip
> ./simulation_launch.sh ufld passive
> cd ../auv/unicorn
> ./array_config.sh durip
> ./simulation_launch.sh ufld bearingsim
Unicorn with Active Sonar Contact Simulator and Synchronization with ACOMMS
> cd ../topside
> ./simulator_launch.sh ufld fixed_mac
> cd ../auv/unicorn
> ./array_config.sh mfa16
> ./simulation_launch.sh 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 (10.0.1.xxx).
> cd .missions-dsop/topside
> ./simulator_launch.sh ufld hitl
Start frontseat simulator, conveniently on different desktop:
> cd missions-dsop/auv/frontseat_sim
> ./simulation_launch.sh hitl auv=unicorn
Start active sonar and environmental sensor simulators, conveniently on separate desktop:
> cd missions-dsop/auv/sensor_sim
> ./simulation_launch.sh 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
> ./simulation_launch.sh quiet gumstix ufld sensorsim frontseatsim active_proc