Brian, Carlos, Tully, Thanks for taking the time to review our use case and apologies again about the short notice. We are soliciting your help since our team is oversubscribed and we’d like to see progress toward a multi-vehicle sim made in 2020. Here’s a short blurb that I hope will provide some context and help clarify what we need beyond the text that’s in the phase 1 proposal I sent earlier. ### Overview of lrauv-application and current simulator arch: At the basic level, the lrauv-application (or “the app” as we call it) is a single-process/multi-threaded C++ application, which runs a main synchronous loop thread that executes individual software components in sequence. The sync loop executes everything from the driver level upwards, including control/guidance code, continues built-in-tests, etc. The app also runs a number of supporting threads for logging and other asynchronous components. Data is passed between components/threads via a shared memory object called “the Slate,” to which we have standard reader/writer accessors that are inherited at the basic component level. More recently, we’ve added network based messaging using LCM that enables communication with other processes including “back-seat-driver” applications that execute on a separate/secondary processing unit. The app was designed to run on a low-power embedded Linux target, but is also capable of running on a host (e.g., a Linux VM) in simulation mode. When run in sim, the app attaches to a SimDaemon server process via socket interface (not LCM). The SimDaemon runs a faster-than-real-time external simulation of the vehicle, which includes a 6-DOF dynamics and collision model that runs over a bathymetry map derived from standard marine navigation charts. The sim supports a minimal environmental envelope (fixed current) and sensor simulation for core instruments (altitude, temp, salinity, etc.) via lookup chart. These data are passed from the SimDaemon to the running app instance over the socket link, and the data is then distributed amongst the app components via Slate interface. The sim is essentially a command line tool, so the live output is a view of the vehicle’s syslog. The app generates logged datasets that can be processed/visualized after the fact. Multi-vehicle simulation is not currently supported. # Multi-vehicle sim project: The motivation for integration with Gazebo is threefold: 1) take advantage of existing multi-vehicle and visualization properties that are inherent to ROS/Gazebo/Rviz in order to enable a scalable development path for new multi-vehicle applications at MBARI, 2) tap into ROS ecosystem community for resource reuse, 3) tap into ROS ecosystem community for technology export. While we aren’t planning on transitioning our main vehicle application to a ROS-based arch in the near future, we see the integration of the app with a ROS/Gazebo sim as a step in that direction. **Use case:**an MBARI researcher developing a new multi-vehicle application for LRAUV against a full simulation of the vehicle and a marine environment with back-seat-driver hardware in the loop. **As stated in the proposal document, this scoping study has two parts:** 1. Scope the required development and integration efforts to interface LRAUV’s software stack with a Gazebo simulation. 2. Develop a proof-of-concept demonstration that will form the basis for a multi-year project proposal. ## Task 1 - DESIGN ONLY - Define lrauv-application <--> Gazebo sim interfaces: ### Questions we’re hoping to answer: - What are potential integration models between multiple app instances (multi-vehicle) and a **faster-than-real-time** Gazebo sim? - What are the performance tradeoffs between implementation models that will allow us to synchronize data between the sim and the app’s synchronous loop arch (multiple app instances)? For example, lockstep vs other integration model. - At what level does the interface between Gazebo and existing app reside? Do/should we keep parts of existing sim daemon (e.g., 6-DOF dynamics model that includes ~160 coefficients, or other domain specific implementation details?) - What lives in the Gazebo sim? How much needs to be developed vs what can we reuse from community contributions? Can we re-package some of our existing simulation code to run within Gazebo? What would that entail? - How should we architect the internal Gazebo topics/messages and design the model output interfaces with LCM or Slate? - How can we incorporate acoustic communication between vehicles running in the simulation? - Could we use the Gazebo world sim for data replay/visualization? ### Outputs from the SimDaemon to lrauv-application instance: **Vehicle attitude/state:** \- ALTITUDE_METER // Written by Bathymetry & read by DVL \- DEPTH_METER // Used by Depth_Keller sensor \- LATITUDE_DEGREE // Used in NAL_9602 sensor \- LONGITUDE_DEGREE // Used in NAL_9602 sensor \- HEADING_RADIAN // Used in AHRS_M2 sensor \- YAW_RATE_RADIAN_PER_SECOND // Used in AHRS_M2 sensor \- PITCH_RADIAN // Used in AHRS_M2 sensor \- PITCH_RATE_RADIAN_PER_SECOND // Used in AHRS_M2 sensor \- ROLL_RADIAN // Used in AHRS_M2 sensor \- ROLL_RATE_RADIAN_PER_SECOND // Used in AHRS_M2 sensor \- VELOCITY_X_WRT_GROUND_METER_PER_SECOND // Used in DVL bottom track and navigation module \- VELOCITY_Y_WRT_GROUND_METER_PER_SECOND // Used in DVL bottom track and navigation module \- VELOCITY_Z_WRT_GROUND_METER_PER_SECOND // Used in DVL bottom track and navigation module **Actuators:** \- BUOYANCY_POSITION_CUBIC_METER // Used in BuoyancyServo \- ELEVATOR_ANGLE_RADIAN // Used in MotorServo \- MASS_POSITION_METER // Used in MotorServo \- PROPELLER_OMEGA_RADIAN_PER_SECOND // Used in MotorServo \- RUDDER_ANGLE_RADIAN // Used in MotorServo **Science sensors:** \- DENSITY_KILOGRAM_PER_CUBIC_METER // Used in CTDs \- SALINITY_PART_PER_THOUSAND // Used in CTDs \- TEMPERATURE_DEGREE_CELSIUS // Used in CTDs \- SOUND_SPEED_METER_PER_SECOND // Used in CTDs \- MASS_CONCENTRATION_OF_CHLOROPHYLL_UG_PER_L // Used by Fluorometer sensor \- MASS_CONCENTRATION_OF_OXYGEN_UG_PER_L // Used by Oxygen sensor \- EASTWARD_WATER_VELOCITY_METER_PER_SECOND, // Used in DVL \- NORTHWARD_WATER_VELOCITY_METER_PER_SECOND, // Used in DVL \- WATER_VELOCITY_X_METER_PER_SECOND, // Used in DVL \- WATER_VELOCITY_Y_METER_PER_SECOND, // Used in DVL \- WATER_VELOCITY_Z_METER_PER_SECOND, // Used in DVL \- MAGNETIC_VARIATION_DEGREE, // Used in MagneticVariation \- HOMING_SENSOR_RANGE_M, // Used in Directional Acoustic Transponder to determine range to acoustic target \- HOMING_SENSOR_AZIM_RAD, // Used in Directional Acoustic Transponder to determine azimuth to acoustic target \- HOMING_SENSOR_ELEV_RAD, // Used in Directional Acoustic Transponder to determine elevation to acoustic target ### Inputs to the SimDaemon from lrauv-application instance: \- **Control commands:** \- BUOYANCY_ACTION // commanded by VerticalControl \- ELEVATOR_ANGLE_ACTION // commanded by VerticalControl \- MASS_POSITION_ACTION // commanded by VerticalControl \- PROP_OMEGA_ACTION // commanded by SpeedControl \- RUDDER_ANGLE_ACTION // commanded by HorizontalControl \- DROP_WEIGHT_STATE // denotes the state of the emergency drop-weight ## Task 2 - lrauv-application <--> Gazebo sim proof-of-concept demonstration: - Simple world model with stubs for environmental envelope dynamic components (current, wind, waves) - LRAUV vehicle model: - Vehicle dynamics simulation should approximate with reasonable level of fidelity (comparable to the performance of existing dynamics model or better) - Must have actuator models: prop, elevator, rudder - Optional actuator models: variable buoyancy system, mass shifter, drop weight - Realistic vehicle shape - Realistic mesh is a “nice to have” - Science sensor models - CTD and Fluorometer