An Overview of MOOS-IvP Developments at the

Naval Surface Warfare Center, Panama City Division

Dr. Matthew J. Bays Autonomy Group Lead

Code X22: Automation & Dynamics

Naval Surface Warfare Center, Panama City Division

Distribution Statement A: Approved for public release; distribution is

unlimited.

Mission & Vision

VISION: Technical Center of Excellence for Littoral Warfare and Coastal Defense

NSWC PCD MISSION:

Conduct Research, Development, Test, Evaluation, and

Life Cycle Sustainment work within our assigned mission areas

that enable the Navy to remain a Global Force for Good:

► Mine Warfare

► Naval Special Warfare Systems

► Diving & Life Support Systems

► Amphibious/Expeditionary Maneuver

Warfare Systems

► other missions that occur primarily in

coastal (littoral) regions

END STATE: Rapidly deliver Littoral Warfare and Coastal

Defense capability to the warfighter through technical rigor,

accountable leadership, and stakeholder partnerships.

2 8/8/2017

Non-Mag Area &

Fanselau Coil

Littoral Warfare

Integration Facility

Prototype

Fabrication Facility

Sea Fighter

(FSF-1)

Joint Gulf Test

Range

NSWC PCD Core Areas

Advanced

Sensors

Search Theory

Modernization

Signal Processing &

Information Fusion

Automation &

Dynamics

Cognitive

Architectures

Target Scattering

Chem/Bio Individual

Protection

USMC Mine Roller

Family of Systems

SEAL Delivery

Vehicles(SDV)

Restricted Overhauls

SEAVIEW

Damage Control

Personnel Protection

USMC Raids &

Recon

MIW Sustainment

(MCM 1, MH-53E,

Mines)

MCM Tactics &

Doctrine

LCS Mission Package IO&TE

Certification and IOT&E

Naval Mine Warfare

Simulation (NMWS)

Foreign Weapon

Exploitation

MH-60S/AMNS

Live Fire

Expeditionary

Energy Evaluation

Human Systems

Integration

MK18 EOD UUV

Expeditionary C2

(DJC2,USMC, MLP,

NETC2)

ASQ-232

(SeaFox RDC)

LCAC SLEP

SQQ-32 (V)4Sonar

Upgrades

AAG/IAAG Acoustic

Sweeps

Expeditionary C2

Air Cushion Vehicle

Systems (LCAC100)

USMC Route

Reconnaissance &

Clearance

Mission Package

Application Software

Mission Capable

Unmanned System

MH-60S/AMCM

Integration

TEST & EVALUATION

PRODUCT DELIVERY

FLEET SUPPORT

RESEARCH & DEVELOPMENT

SCIENCE & TECHNOLOGY

Fleet Liaison &

Aviation Det 3 8/8/2017

Science & Technology

• Entire Department at NSWC PCD specifically dedicated to Science & Technology (6.1 – 6.3)

• ~200 Scientists & Engineers

– ~1/3 PhDs

– ~1/3 Masters

• Core areas

– Autonomy

– Unmanned Systems

– Automated Target Recognition

– Littoral Acoustics

– Signal Processing

Distribution A

Code X

Outline

• Autonomy in a Box

• Task-level Control using MOOS-IvP

• Leveraging the Interval Programming suite natively within the Robot Operating System

Distribution A

Outline

• Autonomy in a Box

• Task-level Control using MOOS-IvP

• Leveraging the Interval Programming suite natively within the Robot Operating System

Distribution A

National Unmanned Systems Shared Resource Center

(NUSSRC)

Background

NUSSRC was formed in Fiscal Year 2008 by the Office of Naval Research (ONR) and the Naval Surface Warfare Center Panama City Division (NSWC PCD) after recognizing the need for a central organization to provide Unmanned Underwater Vehicles (UUVs) and trained operators for Science & Technology activities and support other Navy and DoD operations. The need for a proficient work force with the expertise to operate and maintain the UUVs has grown more important as UUVs become more mainstream. NSWC PCD has successfully continued to maintain and operate NUSSRC UUVs.

Objective

To provide highly-skilled unmanned vehicle operators , SMEs and fully operational unmanned vehicles to support ongoing ONR testing and fleet exercises and be recognized as the Maritime Unmanned Vehicle Center of Excellence.

NUSSRC Priorities

1. Development and support of UUV System technologies for future

capabilities and fleet use including

• Payload and Autonomy Science and Technology (S&T)

• SMEs for fleet benefit

2. Support other programs’ goals, operations and testing

NUSSRC

• Leverages past ONR investments

• Is a centralized POC for planning and scheduling UUV operations

• Provides a source for experienced, qualified operators, and Subject

Matter Experts for several systems

• Is a single interface for logistics and mission execution

• Integrates, experiments, and tests UUV S&T

Common Support Efforts

• Site Surveys

• Payload and Autonomy S&T efforts

• “Introduction to UUVs” Course

Point of Contact

Amanda Bobe, X21 NSWC PCD, Amanda.Bobe@navy.mil Distribution Statement A; Approved for public release; distribution is unlimited.

UUV Inventory / Expertise

Name Vehicle Primary Sensor Bluefin SeaLion Bluefin 9 Marine Sonics

Bluefin Buried Mine Identification (BMI)

Buried Object Scanning Sonar (BOSS)

Bluefin 12 BOSS /Electro-

Optic (EO)

Remote Environmental Monitoring Units

(REMUS) 100 – With Payload Computer

REMUS 100 Marine Sonics

REMUS 600 REMUS 600 EdgeTech

REMUS 600 BMI

Laser Scalar Gradiometer (LSG)

REMUS 600 LSG

Small Synthetic Aperture Minehunter (SSAM II) REMUS 600 SSAMII

Small Synthetic Aperture Minehunter (SSAM III) REMUS 600 SSAMIII

Ocean Server - Iver2 – With Payload Computer Iver2 Klein UUV-3500

Riptide uUUV Swarm uUUV N/A

Motivation

Distribution A

Current Payload Computer Paradigm

PCM: Payload Computer Module

MVC: Main Vehicle Computer

OS: Operating System

Vehicle

PCM & OS

MVC Autonomy Engine

The UUV is a shared asset between many

software developers and autonomy projects.

Software Developer #1

Software Developer #2

Developers usually need write access

on the PCM for their algorithms and

and OS dependencies.

Motivation

Distribution A

Vehicle

PCM & OS

MVC Autonomy Engine

Operator

Vehicle Operator is responsible for integrity & safety

of vehicle.

Current Payload Computer Paradigm

Motivation

Distribution A

Vehicle

PCM & OS

MVC Autonomy Engine

Current Payload Computer Paradigm

Software Developer #1

-Ubuntu Linux 14

-Robot Operating System

-libBOOST v.1.1.3

-OpenCV

Software Developer #2

-OpenSUSE Linux 13.1

-MOOS-IvP Autonomy Engine

-libBOOST v.1.2.5

-Google Protocol Buffers

PCM & OS

MVC Autonomy Engine

Motivation

Distribution A

Old Way

Operator Software Developers

This can lead to conflict, operator mistrust, and dramatic

vehicle reconfigurations after each autonomy test.

Vehicle

Payload Computer Paradigm

Distribution A

New Way

PCM & OS

MVC

Autonomy Engine

Docker Docker Container

Algorithms Dependencies

Use Docker containers!

Benefits with Model

• Autonomy Developers don’t need admin access to PCM OS, they just need to develop their own Docker container or work with provided baseline.

• Autonomy Developers can utilize their OS and dependencies of choice for AE and/or algorithm development.

• Facilitates simple reconfigurations of a baseline Docker container.

• Docker containers can be transferred from topside to vehicle for final testing easily over ethernet or wireless.

Distribution A

Docker Deployment for UxVs

Distribution A

Approach

• Leverages the cloud virtualization software known as Docker

(www.docker.com) to create a standardized integration environment.

• Integrates a standardized autonomy framework and commonly-used

maritime autonomy behaviors into a Docker container.

• Uses software scripts to enable automatic, hardware agnostic

deployment/configuration on commonly used maritime assets.

• Following configuration Management procedures for software

solution.

• Maintaining several baseline images for use with commonly

autonomy frameworks.

.

Autonomy in a Box Office of Naval Research

Objective

• Develop a quickly-deployable autonomy software solution for use on

both development platforms and unmanned systems using a shared

environment.

• Provide developers an “autonomy sandbox” for development for easy

transition to fielded platforms in a shared-asset framework.

• Lower the expense of testing autonomy algorithms on actual

hardware.

• Reduce lead time from algorithm development to implementation and

sea testing.

PI’s: Dr. Matthew J. Bays, matthew.bays@navy.mil, 850-230-7711,

Dr. Drew Lucas, drew.lucas@navy.mil, 850-230-7712.

Current Technology Readiness

• Over 50 hours of in-water tests based on three different underlying

technology frameworks. Including MOOS-IvP, the Robot Operating

System, and Advanced Vehicle Architecture.

• Easily deployable with a user-friendly graphical user interface.

• Publications

• R. M Mabry, J. Ardonne, J. N. Weaver, D. Lucas, and M. J.

Bays, "Maritime Autonomy in a Box: Developing a quickly-

deployable autonomy solution using the Docker container

environment," IEEE/MTS OCEANS, 2016.

PCM/OS

MVC

Autonomy

Engine

Docker

Docker

Container

Algorithms Dependencies

DISTRIBUTION STATEMENT A: Approved for public release; distribution is

unlimited.

More Information

• PI: Dr. Matthew Bays

• matthew.bays@navy.mil

• Co-PI: Dr. Drew Lucas

• drew.lucas@navy.mi

• R. M Mabry, J. Ardonne, J. N. Weaver, D. Lucas, and M. J. Bays,

"Maritime Autonomy in a Box: Developing a quickly-deployable

autonomy solution using the Docker container environment,"

IEEE/MTS OCEANS, 2016.

Outline

• Autonomy in a Box

• Task-level Control using MOOS-IvP

• Leveraging the Interval Programming suite natively within the Robot Operating System

Distribution A

Motivation

• Setpoint Control – Greatest flexibility and control

– Same behavior can be re-used across platforms

– Behavior is owned and under developmental control of payload owner

– Requires re-development of existing capabilities

– Tightly integrated subsystems may not be accessible

• Task Control – Use existing, proven capabilities on target

platform

– May allow access to subsystems not available to setpoint control

– Desired task must be available and implemented; less flexible

– Implementation is tied to the host platform

– Dependent on system owner for implementation and changes

Distribution A

Control Method Paradigms

Approach

• Develop hybrid architecture incorporating low-level behaviors from

MOOS-IvP with a high-level task managers.

• Leverages Google Protocol buffers for high-level communications.

• Allow for compatibility with the Robot Operating System.

• Incorporate perception with a World Model for external data

management.

.

Autonomous Vehicle Architecture (AVA) Office of Naval Research

Objective

• High-level autonomy controller for automated mission re-planning,

task de-confliction and sensor cueing

• Modular and Open Design

Loose coupling and high cohesion that allow for independent

acquisition of system components

• Reusable Application Software

Scalable and portable

• Life Cycle affordability

• Encouraging Competition and Collaboration

• Promote technology development while Managing Risk

PI: Dr. Joshua Weaver, joshua.n.weaver@navy.mil

DISTRIBUTION STATEMENT A: Approved for public release; distribution is

unlimited.

J. N. Weaver, J. Perkins, and D. Stirnlicht,”Advanced Autonomy

Architecture for maritime autonomy,” IEEE/MTS OCEANS, In Press.

20

• Setpoint Controller – IvP Behavior Manager configures and

runs IvPHelm behaviors and monitors for end conditions

– IvPHelm runs concurrent behaviors to generate immediate heading, speed, and depth decisions

• Task Controller – Vehicle Task Manager (VTM) converts

tasks directly to vehicle requests

– Currently supports Transit, Loiter, Bottom, and Cancel

DISTRIBUTION STATEMENT A – PUBLIC RELEASE

Parallel Controllers

21 DISTRIBUTION STATEMENT A – PUBLIC RELEASE

• Used to determine which controller executes which task

• Routes instructions from Task Manager based on configuration

• Tasks are assigned to IvP setpoint controller by default

• Tracks active controller and only passes updates from that controller back to Task Manager

• Structure is extensible to an arbitrary number of controllers based on unique three-letter prefixes

TASK DISCRIMINATOR

IVP BEHAVIOR MANAGER (IVP)

VEHICLE TASK MANAGER (VEH)

ARBITRARY CONTROLLER

(FOO)

Task Discriminator

Common Protobuf Messages

• All low-level controllers produce a CommandRequest message defining the action that the vehicle should take

• Setpoint controllers produce a desired course, defining the current desired setpoint value for navigational parameters

• Task controllers produce a desired task, defining the task to be delegated and its execution parameters

22 DISTRIBUTION STATEMENT A – PUBLIC RELEASE

IVP BEHAVIOR MANAGER (IVP)

VEHICLE TASK MANAGER (VEH)

ARBITRARY CONTROLLER

(FOO)

23

• Generic vehicle interface implementing a state machine for management of vehicle payload control

• Free and open source (gobysoft.org)

DISTRIBUTION STATEMENT A – PUBLIC RELEASE

• Uses a plugin for each unique vehicle interface

• Initially, only supported setpoint control and DesiredCourse commands

goby iFrontSeat

24

• Controller states generated based on same configuration as Task Discriminator

• Monitors active controller to determine which controller state and commands are significant

• Only processes commands from active controller

DISTRIBUTION STATEMENT A – PUBLIC RELEASE

• Setpoint command mode acts as a pass-through and translates to the vehicle-specific messages

• Task command mode additionally monitors for task start and end as reported by vehicle

• Additions will be contributed back to the project pending public release

Vehicle Interface

Simulation Results

25 DISTRIBUTION STATEMENT A – PUBLIC RELEASE

Transit executed using

setpoint control via IvPHelm

Transit executed using

task control

Simulation results confirmed during in-water test in August 2016

More Information

• Lead: Andrew Bouchard

• andrew.bouchard@navy.mil

• A. T. Bouchard, “Multi-Layered Vehicle Control via Payload

Autonomy” IEEE/MTS OCEANS, 2016.

Outline

• Autonomy in a Box

• Task-level Control using MOOS-IvP

• Leveraging the Interval Programming suite natively within the Robot Operating System

Distribution A

Motivation & Previous Work

• Leverage core Interval Programming (IvP) functionality from MOOS-IvP natively within the Robot Operating System (ROS).

• Allow utilization of ROS’s advanced messaging and node introspection capabilities.

• Previously, a MOOS-ROS bridge has been developed to act as a translator between the two messaging frameworks (DeMarco, 2011)

– Requires both MOOS Database and ROS Core messaging running simultaneously.

– Inherently limited to MOOS message formats (string, float, etc).

– Potential for delay highly reactive environments.

Distribution A

ROS-IvP

• Two iterations

– ROS-IvP Native

• Re-written CMOOSCommClient class to use pub-sub features of ROS.

• No MOOSDB instantiated.

• Still requires non-ROS/catkin build scripts.

– ROS-IvP2

• Completely extrapolated IvP Packages.

– IvP Helm

– MarineSim Maritime Simulator

– Marine Viewer

– Marine PID Controller

• No MOOSDB here either.

• Built with ROS catkin.

– Both still leverage MOOS-like message structure, but using ROS message schema. Distribution A

How we did it

Core ROS Packages

• moos_common

– Meta Package containing other packages.

• ivp

– Package containing the IvP Helm.

• marine_pid

– PID controller for marine vehicles.

• sim_marine

– Basic vehicle simulator.

• moos_geodesy

– Georgraphic reference library.

Distribution A

Message Schema

• mooscommon.msg

Distribution A

Results

Distribution A

ROS IvP Qt Graph

Results

MarineSim from ROS ROS RVIZ Showing k1_alpha

Distribution A

Simulations

IvP in ROS Pros and Cons

Distribution A

More Information

• Lead: Dr. Josh Weaver

• joshua.n.weaver@navy.mil

• M. Snyder, J. N. Weaver, and M. J. Bays, “ROS-IvP: Porting the Interval Programming Suite into the Robot Operating System for Maritime Autonomy," IEEE/MTS OCEANS, 2016.

Summary

• Presented several MOOS-related technical developments

– Autonomy in a Box containerization environment.

– Task-level autonomy control.

– Leveraging the Interval Programming suite natively within the Robot Operating System.

Distribution A