an overview of moos-ivp developments at the …an overview of moos-ivp developments at the naval...
TRANSCRIPT
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, [email protected] 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, [email protected], 850-230-7711,
Dr. Drew Lucas, [email protected], 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
• Co-PI: Dr. Drew Lucas
• 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, [email protected]
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
• 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
• 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