Using the UMAA Standard with RTI Connext

Use Case:

I am a developer who is creating an Anchor Controller app for a UMAA system.

Workflow:

Using Connext this is what my workflow would look like:

1. I am given an XML file (resources/xml_components) from my systems engineering team that defines the Anchor Controller component’s DDS entities.
2. I develop my app using XML App-creation and compiled data types, looking up my defined entities.
3. I run the rest of my system (“Autonomy”) that references the same xml file(resources/xml_components) but uses DynamicData types.
4. I test my app using a Python script to simulate the NavData component, using resources/xml_components as well(Connext 7.3.0).
5. Finally, I simulate my GUI by sending commands to my app using Admin Console and Graphical Data Publishing (Connext 7.3.0).

This example simulates a few components using types and services from the public UMAA 5.2.1 standard. The intention is to minimize application code and highlight the ease of access to the writers/readers and their usage.

Note: These components are purely for reference purposes (UMAA defined components are not public yet). UMAA application layer requirements such as “Flow Control” and “Large Collections” are not part of this example as the focus is on setting up the middleware/infrastructure.

The resources/umaa_components.xml file contains the configurations for the behavior (QoS), Topics, Domains and Types of the Connext databus.

It takes advantage of Connext’s exclusive XML-Based Application Creation framework to define and manage all of the messaging entities with XML files.

XML-Based Application Creation:

When using XML-Based Application Creation, all of the entities are pre-defined using XML, and can be changed without a need for re-compilation.

These artifacts can be created and controlled by your Systems Engineering group, allowing the development team to focus on application logic and minimal boilerplate code.

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

Compiled vs Dynamic Data:

When handling data types, there are two different options Connext provides for your convenience:

Compiled Types

Pros: Compiled Types will be a bit more performant, and simpler to access sub structures.
Cons: Require additional overhead in the build system.

As part of this example, the UMAA IDL files are converted to type code using rtiddsgen, compiled, and then linked into a shared library.

DynamicData Types

Pros: DynamicData Types do not require any code generation, and only needs XML type definition files as input.
Cons: A bit more involved to access/set members, slightly less performant when using variable length types.

As part of this example, the IDL files are converted to XML using rtiddsgen.

Please reference the readme for the latest and most accurate info for this repository.

To build and run this example 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.git.
   
   If you forget to clone the repository with --recurse-submodule, simply run the following command to pull all the dependencies:
   
   git submodule update --init --recursive
   
   
2. 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=Release

Set Up Python Environment

Follow the directions in the Python API manual to setup your environment.

Build

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 Anchor Controller application.

Anchor Controller

./build/anchor_controller -f ./resources/umaa_components.xml

You should see an initial state of “STOWED” on startup:

ANCHOR PAYOUT: 0
LAST COMMAND: AnchorActionEnumType: :STOP
ANCHOR STATE: AnchorStateEnumType: :STOWED

The Anchor Controller has a simple state machine that manages “lowering” and “raising” the anchor based on the commands it receives.

Autonomy

./build/autonomy -f ./resources/umaa_components.xml

If you have the Anchor controller running as well, this should be your initial state:

MISSION FAULTED
SPEED COMMS:  FALSE
ANCHOR COMMS: TRUE
ANCHOR UP:    TRUE

The Autonomy application checks for comms to the “Anchor Controller” and the “Nav Data” application, as well as verifies that the Anchor is in the “STOWED” state before giving the green light to start a mission.

NavData

Python
python ./python/nav_data.py -f ./resources/umaa_components.xml

If you have Anchor Controller running as well as the Autonomy application, and you start the Nav Data component, this is what your autonomy app should look like:

MISSION READY
SPEED COMMS:  TRUE
ANCHOR COMMS: TRUE
ANCHOR UP:    TRUE

Congratulations, you are ready to start a mission!

GUI

Commands: Commands can be sent down one of two ways: 

1. Python
2. Admin Console Graphical Data Publishing

Note: These commands do not follow the command state sequence as defined in the UMAA spec as that is outside the scope of this middleware reference example.

Python (Connext 7.3.0): Pass in the enum values per command:

• LOWER: 0
• RAISE: 1
• STOP: 2

For example, to "RAISE” the anchor:

Python
python python/gui.py -c 1

Admin Console: Graphical Data Publishing (Connext 7.3.0)

1. Open up the Admin Console.
2. Right click on the “AnchorCommand” topic, and select “Publish”.
   
   
   
   
3. You should see a Dialog box popup. Admin Console automatically detects the correct type based on Discovery.
   Click “OK”.
   
   
   
   
4. The Sample for this type will get pre-populated.
   
   
   
   
5. Modify the desired command value to either “RAISE”, “LOWER”, or “STOP”.
   
   
   
   
6. Click the “Play” Icon to publish the sample.
   
   

You should see the Anchor Controller application go into a “LOWER” state and the “ANCHOR PAYOUT” value decrement.

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 Professional Services team is here to help customers 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.

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.