Skip to content

Latest commit

 

History

History
184 lines (135 loc) · 7.85 KB

README.md

File metadata and controls

184 lines (135 loc) · 7.85 KB
Raw

transformer_app_demo

This is a simple C++ application that uses the Tangram LMCP and STANAG-4586 CSIs and an associated transform from STANAG-4586::InertialStates to LMCP::AirVehicleState to send data to OpenAMASE.

Requirements

The following are required to run this demonstration.

Ubuntu 20.04 LTS

OpenAMASE

The OpenAMASE graphical airborne simulator is used to display the scenario. The OpenAMASE application can be found here:

OpenAMASE is a Java application that is known to work with Java 11.

Tangram Pro has a tutorial that describes the process of obtaining and setting up OpenAMASE:

This demonstration is built on that capability and modifies it to add transforms.

OpenUxAS

OpenUxAS is a collection of modular services that can be used to construct airborne flight simulations. This demo does not specifically use OpenUxAS but does use one of the example scenarios in it. OpenUxAS can be found here

The scenario used is the 02_Example_WaterwaySearch found here:

If a git clone operation is done on the OpenUxAS repository, it will be easy to open and use the waterway search example from within OpenAMASE.

ZeroMQ Proxy

This demo uses ZeroMQ via a proxy. The proxy can be found here:

To run the proxy, the command used for the demo is:

./zmq_proxy tcp://*:6667 tcp://*:6668

CSIs

The following CSIs must be generated and available:

  1. LMCP with AirVehicleConfiguration and AirVehicleState messages.
  2. STANAG-4586 with InertialStates messages

Both of these can be created in Tangram Pro as process components. Workflows may be used to perform generation (code-gen-3 plugin) and build (g++ plugin) steps if desired, but this is not necessary for this exercise.

By default, a transform workflow will generate both of these CSIs automatically.

NOTE: The LMCP CSI used with this demo MUST have both the AirVehicleState and AirVehicleConfiguration messages in it. This may not be the case if the CSI is generated solely from the transform workflow. If when you build the demo application the compile step says it cannot find the AirVehicleConfigration.hpp file, your CSI is not complete. The CSI linked to the transform app only requires AirVehicleState, however. So an additional instance of the LMCP CSI should be used for the demo app link step. The demo app can use the STANAG-4586 CSI that was generated for the transform workflow as is.

Transformer App

It is also necessary to setup a transform between these. The direction of the transform needs to be STANAG4586::InertialStates to LMCP::AirVehicleState.

A workflow can be created for the transform. Transform workflows have only a single step. This is a specialized workflow that performs all the steps necessary for a complete "bump-in-the-line" transform. The following operations are performed by a transform workflow.

  1. Generation of each required CSI (this is a code-gen-3 process).
  2. Building of each required CSI (this is a g++ process).
  3. Generation of the transform function (this is a Flex process).
  4. Generation of the transformer app (this is a code-gen-3 process).
  5. Building of the transformer app (which incorporates the transform function).

The result should be a build artifact that contains the 2 generated and built CSIs as well as a generated and built transform app.

The transform app is a standalone executable. It starts up a loop that performs the following actions:

  1. Read an incoming message.
  2. De-serialize the message bytes received into a message object (C++ object).
  3. Transform the message object into the desired destination type (another C++ object).
  4. Serialize the message populated in the previous step.
  5. Send the outgoing message.

Building the Demo App

To build the demo app, a Makefile is provided. Only a single C++ source file is used. The Makefile assumes the 2 needed CSIs are available at the same level in the directory structure as the Makefile itself and that they are called "lmcp" and "stanag4586". This can be overridden by setting the LMCP_DIR and/or STANAG4586_DIR variables on the make line, if desired. If these folders exist elsewhere, symbolic links can also be used to find them.

The "lmcp" folder or link, again, must contain an LMCP CSI that contains both an AirVehicleConfiguration and an AirVehicleState message. The default folder generated from a transform is name "out" at its root. Under that should be the two CSIs generated by the transform workflow and a folder named "transform", which contains the transform app already built and ready to run.

If a second LMCP CSI is built to include the AirVehicleConfiguration message using a code-gen-3/g++ workflow, the default output name for that build artifact will be "code-gen-3" once extracted. Here's an example of what the directory structure would look like using these defaults and assuming that the both workflow artifacts are extracted to the transformer_app_demo folder.

ezwirner@pop-os:~/work16/demo2/transformer_app_demo$ ll
total 912
drwxrwxr-x  5 ezwirner ezwirner   4096 Dec  3 14:08 ./
drwxrwxr-x  3 ezwirner ezwirner   4096 Dec  2 17:21 ../
drwxr-xr-x 10 ezwirner ezwirner   4096 Dec  3 14:05 code-gen-3/
drwxrwxr-x  8 ezwirner ezwirner   4096 Dec  3 14:12 .git/
-rw-rw-r--  1 ezwirner ezwirner     31 Dec  3 14:06 .gitignore
lrwxrwxrwx  1 ezwirner ezwirner     10 Dec  3 14:07 lmcp -> code-gen-3/
-rw-rw-r--  1 ezwirner ezwirner   1472 Dec  2 17:21 Makefile
drwxr-xr-x  5 ezwirner ezwirner   4096 Dec  3 13:51 out/
-rw-rw-r--  1 ezwirner ezwirner   6086 Dec  3 14:13 README.md
-rwxrwxr-x  1 ezwirner ezwirner 873472 Dec  3 14:08 receiver*
-rw-rw-r--  1 ezwirner ezwirner  16768 Dec  3 13:52 receiver.cpp
lrwxrwxrwx  1 ezwirner ezwirner     14 Dec  3 13:53 stanag4586 -> out/stanag4586/

Provided the CSIs are in place as described, all that should be needed is to call "make". All needed dependencies should be found in one or both of the CSI folders. If the build succeeds, the "receiver" executable is generated.

Running the Demo

The order of operations is important. Please start things in this order:

  1. Run OpenAMASE. During testing, this meant going to the folder OpenAMASE/OpenAMASE/run/linux and running the script OpenAMASE.sh. This may need to be adjusted depending on the platform.

  2. On the OpenAMASE GUI, go to File then Open Scenario. Then browse to the OpenUxAS/examples folder and find 02_Example_WaterwaySearch. In that folder select the Scenario_WaterwaySearch.xml file.

  3. Press the "run" button (triangle pointing right) to start the scenario.

  4. Start the ZeroMQ proxy per the instructions above for that.

  5. Start the transformer app. This should just be ./transform in the folder.

  6. Start the demo app. This should just be ./receiver in that folder.

If all of this was successful, the Tangram UAV 500 should appear and start flying back and forth.

Contextual Transform Changes

NOTE: There are changes to the InertialStates to AirVehicleState transform currently in the works. This update will add a contextual transform parameter to this transform. This means a "Provider" class will need to be modified in order to run the transform. The "Provider" classes are generated when there are contextual transforms for which the user needs to supply additional information. In this case, the following error message would appear when the transform app is executed:

*** ERROR: Contextual parameters not populated in file Provider_Stanag4586InertialStatesToLmcpAirVehicleState_AirVehicleStateInfo.hpp!
Aborted (core dumped)

In order to fix this, at a minimum, open the file shown above and comment out the call to the abort function.