Telemetry Republisher Example¶

This example shows how to configure and run one instance of Telemetry Republisher. As the Telemetry Republisher is a final component it works as provided, no compile time modifications/customisation is needed.

In the provided example one instance of the republisher with name: tel_repub_1 is instantiated.

Provided Example¶

Note

For simplicity reasons, the example uses the file based implementation of OLDB, Persistent and Runtime Configuration Repositories; as well as file based service discovery. This means that the underlying format of configuration and data points is different than the one used when the above mentioned services are used with the standard back-ends such as CII configuration service, CII OLDB, etc.

Example Location¶

The example code can be found in the following sub-directory of the rtctk project:

_examples/exampleTelRepub

Modules¶

The provided example is composed into the following directories:

config - Contains configuration of the telemetry republisher example system
scripts - Helper scripts for deployment and control

Dependencies¶

The provided example code depends on the following modules:

Dependency Name	Description
Component Framework	For RTC Component functionality and Services
Reusable Components	For usage of provided components like TelRepub and libraries.
Standalone Tools	Several supporting tools are used, e.g. data sources, etc.

The Example Components¶

The telemetry republisher example consists of the following components

Executable	Description
rtctkMudpiPublisher	A Simple MUDPI data generator (standalone executable not based on Tk component infrastructure)
rtctkTelRepub	Acquiring MUDPI frames and publishing Agnostic DDS Samples
rtctkGenDdsSub	A generic DDS Agnostic topic subscriber

Configuration¶

The configuration can be found in file:

config/resource/config/rtctk/exampleTelRepub/runtime_repo/tel_repub_1.yaml

It configures the republisher side with two MUDPI receivers:

rcv_00 receiving MUDPI topic traffic on IP 127.0.0.1 port 60000, with CPU affinity 1 for the receiving thread
rcv_01 receiving MUDPI topic traffic on IP 127.0.0.1 port 60500

On the DDS side it configures 4 topics: topic_00 … topic_03:

topic_00 and topic_01 defines DDS topic with names Topic00 and Topic01 that map MUDPI topic 0 and 1 respectively both receiving on receiver 0 i.e. rcv_00. For topic_00 is define queue of size 100.
TopicAAA maps MUDPI topic 0, but received on second receiver i.e. rcv_01.
TopicBBB just simulates DDS topic sample data with frequency around 100Hz.

For configuration details please refer to Configuration section in Telemetry Republisher.

Running the Example¶

After installing the RTC Tk the example can be run using the following command:

$ rtctkExampleTelRepub.sh run

This will actually start the following process:

rtctkTelRepub - The Telemetry Republisher component itself.

Note

The commands indicated above, e.g. when using undeploy, may generate the following output:

rtctkMudpiPublisher: no process found

This is expected and should not be treated as an indication of failure. The same applies for similar commands in the rest of this tutorial.

Instead of using the run command, we can step manually through using the following sequence of commands to deploy and start:

$ rtctkExampleTelRepub.sh deploy
$ rtctkExampleTelRepub.sh start

As every other RTC Component it can be commanded through the life-cycle using directly the rtctkClient application, or to use the example script: rtctkExampleTelRepub.sh as follows:

$ rtctkExampleTelRepub.sh send Init
$ rtctkExampleTelRepub.sh send Enable
$ rtctkExampleTelRepub.sh send Run

Now we should have the republisher in On:Operational:Running state what means that it can republishes topic sample data i.e. receives MUDPI topic data, and publishes it via DDS topics.

MUDPI traffic can be generated (and sent to the Telemetry Republisher) by invoking:

$ rtctkExampleTelRepub.sh start_data

It sends topic samples with a frequency of approximately 100Hz with 6 frames per topic sample.

Note

The same can be achieved manually by using the MUDPI Publisher application. E.g. to send data to IP 127.0.0.1 PORT 60000 with TOPIC_ID 0 and FREQUENCY ~100Hz use:

rtctkMudpiPublisher -d10000 127.0.0.1  60000 0

The Generic DDS subscriber application can be used to monitor published DDS samples. E.g. to listen to DDS topic with name TestTopic00 that maps in the example to MUDPI topic with Id 0 use:

$ rtctkGenDdsSub -a 127.0.0.1 -t TestTopic00

The example is configured for more topics i.e. there are defined DDS topics with mapping to MUDPI topic. So we can start manually in parallel another source of MUDPI topic data e.g. for topic with id 1 as follow:

$ rtctkMudpiPublisher -d10000 127.0.0.1  60000 1

As in case for topic id 0 with frequency around 100Hz, sending data to 127.0.0.1 on port 6000.

As this topic is mapped to DDS topic with name TestTopic01 we can monitor both of them executing Generic DDS subscriber in the following way:

$ rtctkGenDdsSub -a 127.0.0.1 -t TestTopic00 TestTopic01

The MUDPI traffic sending (started via the script) can be stopped by executing:

$ rtctkExampleTelRepub.sh stop_data

We can steer the application back to On:NotOperational:NotReady state:

$ rtctkExampleTelRepub.sh send Idle
$ rtctkExampleTelRepub.sh send Disable
$ rtctkExampleTelRepub.sh send Reset

Gracefully terminate the application and clean-up:

$ rtctkExampleTelRepub.sh stop
$ rtctkExampleTelRepub.sh undeploy