Success-Plan ServicesGetting Started with UMAA Using RTI Connext
Scalable Command and Control for Maritime Uncrewed Systems
Introduction
The maritime development space generates rapid evolution. From the old compass-guided vehicles that were only able to sample environmental readings to the latest UUVs and USVs that capture impressive imagery using HISAS sonars, the pace of innovation is exponential. And these uncrewed vehicles are now routinely equipped with Inertial Navigation System (INS) sensors, DVLs, high resolution cameras and augmented with new capabilities that include mission autonomy, object detection, behavior trees and obstacle avoidance.
Earlier mission objectives, such as sending out a vehicle to collect salinity readings or basic navigation, are far different from the current operational needs and complexities and require new levels of software functionality. In the past, a simple interface between a single operator and a vehicle might have been enough. Today however, even a basic CONOPS effort can easily involve multiple vehicles, operators, relay buoys, plus the need to transmit all of this data over various communication paths.
This evolution of scaled complexity necessitates infrastructure software to power that data flow, while keeping the management overhead low. The UMAA standard was developed to allow for a “Single Pane of Glass” for operators across the wide array of UUVs and USVs that the Navy is currently employing. This allows for one operator to command and control multiple platforms from various vendors across a common standard.
The UMAA standard selected DDS as its messaging layer protocol for its ability to be vendor agnostic and its capacity to support a broad range of use cases.
RTI Connext (DDS) software has been successfully powering U.S. Navy systems such as Aegis for decades, delivering the reliability and feature set needed to help reduce cost and complexity.
RTI’s Services department has developed a UMAA Case + Code Starter Kit to aid in development to the UMAA standard. Using Connext’s XML Application framework we are able to define UMAA components in XML and then look up the DDS entities in our code. This provides a clean separation of system configuration and developer code allowing us to change settings as needed without recompiling.
-
UMAA Standard High-Level Overview
- Latest Version: 6.0 Distro A Download from AUVSI
- The UMAA standard defines the following(as of 6.0):
- DDS Level:
- Data model (~600 data types in an IDL format)
- No QoS (Exception: Large Collections - PRESENTATION)
- Topics (“Interfaces”) per “Service”.
- Application level:
- Command state machine/handshaking ("Flow Control")
- Large data set synchronization ("Large Collections")
- Type relationship ("Generalizations/specializations)
- Systems level:
- "Components", which are a collection of "Interfaces" derived from the UMAA MBSE model.
- This starter kit provides an xml definition of the Autopilot and USVNAV component DDS entities based on our interpretation of the v1.0 Component Definitions release.
- There are currently ~40 components defined by UMAA of which 9 are Distro A.
- "Components", which are a collection of "Interfaces" derived from the UMAA MBSE model.
- DDS Level:
Note: The application level requirements (i.e Flow Control / Large Collections / Generalizations-specializations)
are outside of the current scope of this middleware reference starter kit. Some application layer development would be required on top of the middleware infrastructure to be compliant with the UMAA standard. - Latest Version: 6.0 Distro A Download from AUVSI
-
What this Example Does
This Starter Kit provides an entry point to developing with UMAA. It highlights usage of a few UMAA defined Components to simulate interaction between the different interfaces.
It showcases Connext’s ability to easily instantiate UMAA components using either the Modern C++ or the Python APIs and manage the configuration of both systems with a centralized configuration store.
UMAA Components:These reference applications simulate a few components using types and services from the public UMAA 6 standard. The intention here was to minimize application code and highlight the ease of access to the writers/readers and their usage.
There are currently ~40 components defined by UMAA of which 9 are Distro A.
The latest UMAA v1.0 Component Definitions doc is provided for your convenience in /resources/components.
XML-Based Application Creation:By inspecting the start_component.sh script we can see how components can be
instantiated from Modern C++ or Python apps using the same DDS configuration files.
This example takes advantage of Connext’s XML-Based Application Creation framework
to define and manage all of the messaging entities with XML files.
This lends itself well to the common use case of simulation/test apps in Python
correlating with deployed apps in Modern C++.
With a single set of XML config files, we can manage the QOS configuration of our System across both the Modern C++ and Python API’s. These artifacts could be owned by the Systems engineering team, with the Developers only needing to “Look up” the entities and use them.
Connext can create all of these entities. The remaining tasks for the application code are:
1. Register the Type (Compiled Types)
2. Look up the Type/Entity
3. Use
Click image to enlarge.
-
Building the Starter Kit
To build and run this starter kit on your network:
1. Clone the source code from our RTI Community GitHub repository
To clone the repository you will need to run git clone as follows to download both the repository and its submodule dependencies:
git clone --recurse-submodule
https://github.com/rticommunity/rticonnextdds-usecases-umaa.gitIf you forget to clone the repository with --recurse-submodule, simply run the following command to pull all the dependencies:git submodule update --init --recursive2. Open a terminal in the newly-created directory
3. Configure your build environment for RTI Connext
Configure
cd rticonnextdds usecases/umaa_case_code/examples
cmake -B build -DCMAKE_BUILD_TYPE=ReleaseBuild
cmake --build ./build --config Release
The build will take some time (~15 mins) as it is generating typecode for all of the UMAA types, and then compiling them into a shared library to be used by the AutoPilot application.Set Up Python Environment
Follow the directions in the Python API manual to set up your environment
-
Running the Example
Note: These examples do not implement Command Flow Control. The intention here was just to highlight use of the Connext API for clarity.
AutoPilot Componentcd examples
.start_component autopilot
All of the necessary DDS entities have been defined in the “resources/components/autopilot.xml” file. This allows anyone to use this config file as a starting point for development. We have selected a few entities to instantiate for the purpose of this example.
Producer: GlobalVectorControl
This application is a Producer of the GlobalVectorControl Service. This means that it intends to receive commands for this service, operate on them, and provide Command statuses on the associated topics.
For the purposes of this example, we have highlighted the ability to receive a command using an AsyncWaitset and store into a local object using the Instance as a key. This allows us to track various commands on the databus and handle them as appropriate.
Consumer: GlobalPoseStatus, VelocityStatus, SpeedStatus
We have also provided a reference example of using Listeners to receive periodic data such as Telemetry as input. As this component is a Consumer of these services, we have highlighted how to capture the latest value and store it in an object for internal application use.USVNAV Component
cd examples
./start_component.sh usvnav
Producer: GlobalPoseStatus, VelocityStatus, SpeedStatus
This example simulates publishing to the telemetry topics as a Producer. After running this Python script you should be able to see the associated values update in the AutoPilot component.GlobalVectorCommand Consumer
cd examples
./start_component.sh globalvector
This is just a simple example of a GlobalVectorCommand consumer. This will publish a sample GlobalVectorCommand message to be received by the AutoPilot component.
By running this script you should be able to see the AutoPilot component update with the received command.
-
Summary
These example applications and XML files offer a better understanding of using Connext’s XML-Application framework and helps to minimize some of the friction when starting development.
The RTI Services team is here to help you out with setting up your system, and is prepared to provide you with an XML file package that works with the latest UMAA standard.
As the UMAA standard doesn’t specify QoS settings, this package will include our recommended QoS profiles for the given topics based on their data patterns.
-
Next Steps
Post questions on the RTI Community Forum.
Check out more of the Connext product suite and learn how Connext can help you build your distributed system. If you haven't already, download the free trial.