RTI Connext DDS Micro
Version 2.4.6
|
RTI Connext DDS Micro is provided in separate host and target packages (.zip or .tar.gz).
The host bundle contains this product documentation, the rtiddsgen code generation tool, and example source code.
Each target bundle contains libraries of RTI Connext DDS Micro for a specific platform.
Download the host bundle and target bundle(s), and follow the directions below to install them.
The distribution is packaged in one or more .zip files. Unzip them into a directory of your choice.
The distribution is packaged in one or more files. Unpack them as described below. You do not need to be logged in as root during installation.
For the optional buildable source bundle, unpack it in the same directory (from the example above, /home/user).
The RTIMEHOME environment variable must be set to the installation directory path for RTI Connext DDS Micro.
To distribute data using RTI Connext DDS Micro, you must first define a data type, and then run the rtiddsgen utility to generate the type-specific support code that RTI Connext DDS Micro needs and calls to publish and subscribe that data type.
RTI Connext DDS Micro accepts types definitions in Interface Definition Language (IDL) format.
struct HelloWorld { string<128> msg; };
As an example, the HelloWorld examples provided with RTI Connext DDS Micro use this simple type defined in HelloWorld.idl. It contains a string "msg" with max length of 128 chars.
You will provide your IDL as an input to rtiddsgen. rtiddsgen supports code generation for the following standard types:
The script to run rtiddsgen is in <your_top_level_dir>/rti_connext_micro.2.4.4/rtiddsgen/scripts.
Calling the script to generate support code for HelloWorld.idl:
rtiddsgen -micro -language C -replace HelloWorld.idl
Run "rtiddsgen -help" to see all available options. For the options used here:
The generated code output consists of these files for HelloWorld.idl:
rtiddsgen does not generate publisher or subscriber code for RTI Connext DDS Micro. This is different than for RTI Connext DDS, where rtiddsgen will generate HelloWorld_publisher.c and HelloWorld_subscriber.c.
The rest of this guide will walk you through the steps of creating an application and will provide example code snippets. It assumes that you have defined your types and have used rtiddsgen to generate their support code.
The DomainParticipantFactory, in addition to its standard role of creating and deleting DomainParticipants, contains the RT Registry that a new application register with some necessary components.
The architecture of RTI Connext DDS Micro defines a run-time (RT) component interface that provides a generic framework for organizing and extending functionality of an application. An RT component is created and deleted with an RT component factory, and each RT component factory must be registered within an RT registry in order for its components to be usable by an application.
RTI Connext DDS Micro automatically registers components that provide necessary functionality. These include components for DDS Writers and Readers, RTPS protocol, and the UDP transport.
In addition, every DDS application must register three components:
Example source:
Only one discovery component can be registered, either DPDE or DPSE. Each has its own properties that can be configured upon registration.
You may need to configure the UDP transport component that is pre-registered by RTI Connext DDS Micro. To change the properties of the UDP transport, first the UDP component has be unregistered, then the properties have to be updated, and finally the component must be re-registered with the updated properties. Example code: - Unregister the pre-registered UDP component
A DomainParticipantFactory creates DomainParticipants, and a DomainParticipant itself is the factory for creating Publishers, Subscribers, and Topic.
When creating a DomainParticipant, you may need to customize DomainParticipantQos, notably for
Example code:
Your data types that have been generated from IDL need to be registered with the DomainParticipants that will be using them. Each registered type must have a unique name, preferably the same as its IDL defined name.
DDS Topics encapsulate the types being communicated, and you can create Topics for your type once your type is registered.
A topic is given a name at creation (e.g. "Example HelloWorld"). The type associated with the Topic is specified with its registered name.
DPSE discovery relies on the application to specify the other, or remote, DomainParticipants that its local DomainParticipants are allowed to discover. Your application must call a DPSE API for each remote participant to discover. The API takes as input the name of the remote participant.
A publishing application needs to create a DDS Publisher and then a DataWriter for each Topic it wants to publish.
In RTI Connext DDS Micro, PublisherQos in general contains no policies that need to be customized, while DataWriterQos does contain several customizable policies.
The DataWriterListener has its callbacks selectively enabled by the DDS status mask. In the example, the mask has set the on_publication_matched status, and accordingly the DataWriterListener has its on_publication_matched assigned to a callback function.
A publishing application using DPSE discovery must specify the other DataReaders that its DataWriters are allowed to discover. Like the API for asserting a remote participant, the DPSE API for asserting a remote subscription must be called for each remote DataReader that a DataWriter may discover.
Whereas asserting a remote participant requires only the remote participant's name, asserting a remote subscription requires more configuration, as all QoS policies of the subscription necessary to determine matching must be known and thus specified.
Within the generated type support code are declarations of the type-specific DataWriter. For the HelloWorld type, this is the HelloWorldDataWriter.
Writing a HelloWorld sample is done by calling the write API of the HelloWorldDataWriter.
A subscribing application needs to create a DDS Subscriber and then a DataReader for each Topic to which it wants to subscribe.
In RTI Connext DDS Micro, SubscriberQos in general contains no policies that need to be customized, while DataReaderQos does contain several customizable policies.
The DataReaderListener has its callbacks selectively enabled by the DDS status mask. In the example, the mask has set the DDS_SUBSCRIPTION_MATCHED_STATUS and DDS_DATA_AVAILABLE_STATUS statuses, and accordingly the DataReaderListener has its on_subscription_matched and on_data_available assigned to callback functions.
A subscribing application using DPSE discovery must specify the other DataWriters that its DataReaders are allowed to discover. Like the API for asserting a remote participant, the DPSE API for asserting a remote publication must be called for each remote DataWriter that a DataReader may discover.
Like done when asserting a remote publication, asserting a remote subscription requires configuration of all QoS policies of the subscription necessary to determine matching.
Accessing received samples can be done in a few ways:
In lieu of supporting Content-Filtered Topics, a DataReaderListener in RTI Connext DDS Micro provides callbacks to do application-level filtering per sample.
You control the callbacks' sample_dropped parameter; upon exiting either callback, the DataReader will drop the sample if sample_dropped is true. Consequently, dropped samples are not stored in the DataReader's queue and are not available to be read or taken.
Neither callback is associated with a DDS Status. Rather, each is enabled when assigned, to a non-NULL callback.
Note, because it is called after the sample has been deserialized, on_before_sample_commit provides an additional sample_info parameter, containing some of the usual sample information that would be available when the sample is read or taken.
The HelloWorld_dpde example's subscriber has this on_before_sample_commit callback: