VILT Exercises

Prerequisites and covered concepts 3

Project Introduction 3

Topics overview 3

Exercise 1. "Proximity Data" topic 5

Data modeling with IDL 5
Modify XML QoS 5
Publishing Application 6
Modify the Publishing Application 6
Modify the Publishing Loop 6
Subscribing application 7
Modify the Subscribing Application 7
Modify the Data Processing Function 7
Compile Your Changes and Run the Applications 8
Subscribing with Admin Console 8
Switch to Data Visualization Perspective 8
Open the Topic Data Tab 9
Subscribe to "Proximity Data" 9
Use the Topic Data Tab 9
Takeaways 9
Exercise 2. Architectural considerations 10
USER_QOS_PROFILES.xml modifications 10
ProximityData.idl modifications 11
CMake 11
Takeaways 12
Exercise 3. "Device Status" topic 13
Add the new type to IDL 13
Modify XML QoS 13
Proximity Sensor 14
Controller 14
Takeaways 14
Considerations about the provided solution 15
Exercise 4. "Brake Command" topic 16
Add the new type to IDL 16
Modify XML QoS 16
Changes to CMakeLists.txt 16
 "Brake Command" functionality 17
Takeaways 17
Considerations about the provided solution 17
Exercise 5. "Device Status" topic for the Brake application 18
Brake 18
Controller 18
Takeaways 19
Considerations about the implemented system 19

Exercise 6. Moving away from listeners to process data (if using Traditional C++) 20
Prerequisites and covered concepts

Prerequisites:
● Install RTI Connext DDS:
○ Install RTI Connext DDS Professional Host package for 6.0.1​.
○ Install RTI Connext DDS Professional Target package for 6.0.1​.
○ Alternatively, visit the ​free trial website​.
● CMake​ (CMake minimum required version: 3.7).
● It is encouraged to complete the ​RTI Connext DDS Getting Started Guide​ before starting
these exercises.

Concepts covered in these exercises:

● Basic data modeling.
● Using the code generator.
● Modifying XML QoS.
● DDS entity creation APIs.
● Viewing your data in RTI Admin Console.
● Scaling your infrastructure using CMake.
● Content-filtered topics.
● Listeners vs. waitsets.

Project Introduction
The project for this exercise is to implement a system, consisting of a sensor, a controller and
an actuator:
● Proximity sensor​, which publishes proximity data based on the distance of an object in
front of the vehicle.
● Controller​, which receives the proximity data and makes a decision on the level of
intensity the brakes should apply.
● Brake​, which receives data from the controller to activate the brakes.

Both the sensor and the actuator will publish their status that is received and interpreted by the
controller.

In this scenario, assume we don’t have the actual hardware. There is also a set of requirements
for the data model and the communication behavior that we will address as part of this exercise.

Topics overview
Let's review some of the design requirements and then construct an IDL file that satisfies the
data modeling requirements for this project.
The 3 applications need to publish / subscribe to 3 different topics:
● Proximity sensor:
○ DW: Proximity Data.
○ DW: Device Status.
● Controller:
○ DR: Proximity Data.
○ DR: Device Status.
○ DW: Brake Command.
● Brake:
○ DR: Brake Command.
○ DW: Device Status.
Exercise 1. "Proximity Data" topic
Time to complete: 30 minutes.

Required VILT sessions for this module:

● DDS Introduction.
● DDS Data Model.
● Quality of Service & QoS XML configuration.

By now, you have learned the basics of DDS entities and Quality of Service (QoS) in your VILT
sessions. In this exercise we are going to take a set of requirements for a project, create an IDL,
configure QoS, and write the code to create our first set of DDS applications.

Data modeling with IDL

First, let's focus on the communication between the Proximity Sensor and the Controller. The
requirements for this communication are as follows:
● "Proximity Data" topic:
○ A string identifying the sensor, up to 16 characters long.
○ A 32-bit floating point value for the proximity in meters.

Step 1.​ Implement the data model requirements in IDL as a ​ProximityData​ type. For this, create
a file called ​ProximityData.idl.​

Step 2.​ Which DDS communication pattern do you think would fit a topic with this data type?
Which QoS policies will we be likely to modify with this pattern?

Generating Code from IDL

Step 3.​ From a terminal or command prompt, run ​rtiddsgen,​ which runs the code generator on
ProximityData.idl​. You will need to generate an example using C++ (​Traditional C++ API​) or
C++11 (​Modern C++ API​).

You will see that several files are created. For the sensor and the controller, we will modify 3 of
them:
● ProximityData_publisher (Proximity Sensor)
● ProximityData_subscriber (Controller)
● USER_QOS_PROFILES.xml​.

Modify XML QoS

The default ​USER_QOS_PROFILES.xml​ file will contain a library called ​ProximityData_Library
and a profile called ​ProximityData_Profile​. The profile contains an attribute
is_default_qos="true".​ On Session 3 of the VILT, we saw that this is not a good practice, so go
ahead and ​remove the attribute​ from the ​qos_profile​ tag.
None of the policies in the profile modify the data flow of the "Proximity Data" topic. We have
some additional requirements that will be used to determine what needs to be changed:
1. "Proximity Data" should be processed by the Controller every 500 milliseconds at most.
2. "Proximity Data" does not need to be delivered reliably, but an alert should be triggered if
the data is not received for 2 or more seconds.

Step 4.​ Make all modifications to the ​ProximityData_Library::ProximityData_Profile​ profile in

USER_QOS_PROFILES.xml​.
● Set the QoS for any DataWriters using this profile.
● Set the QoS for any DataReaders using this profile.

Step 5.​ Does it make sense to use the default "​BuiltinQosLib::Generic.StrictReliable"​ parent
profile? Which builtin profile(s) could we have used as a base for the "Proximity Data" profile?
How would that inheritance affect the QoS modifications required to meet the specifications for
this topic?

Publishing Application

Modify the Publishing Application

In the code provided, the publishing application contains a default DomainParticipant, publisher
and DataWriter for a topic, using the datatype in our IDL file.

Step 6.​ Assign a proper topic name to the topic.

Apart from that, the entities will use a "default" QoS. This default QoS won't be the one we
specified in ​USER_QOS_PROFILES.xml​ since we removed the ​is_default_qos​ attribute from
the QoS profile.

Step 7. ​Modify the creation of the DomainParticipant and DataWriter to use the
ProximityData_Library::ProximityData_Profile​.

Step 8. ​In this exercise we loaded QoS from the ​USER_QOS_PROFILES.xml file​. What are the
other ways to specify QoS files?

Modify the Publishing Loop

Step 9.​ Modify the code to send the "Proximity Data" at a 10 Hz rate.

Step 10. ​On C / Traditional C++, you will see that the DataWriter writes an object called
instance.​ Modify the name of the object to ​sample.​
In a real scenario, we would populate the sample with the values that the sensor provides.
However, in this example, we will have to come up with made-up values.

Step 11. ​Populate the sample so that the proximity varies between 0 and 300 meters.
Suggestion: establish a step of value "1" for every iteration of the loop (0, 1, …, 299, 300, 299,
…, 1, 0).

Recall that your "Proximity Data" Topic describes your data. This topic is associated with the
data type ProximityData, which is defined in the IDL file created earlier in this exercise. This loop
updates the values in this structure with bounded sequential data and publishes the updated
data to the RTI DDS Databus.

Note: ​A ​sample​ is a single update to a ​Topic,​ in this example that is a single update with the
latest proximity data. Every time an application calls ​write​, it is "writing a sample." Every time an
application receives data, it is "receiving a sample."

Subscribing application

Modify the Subscribing Application

Similar to the publishing application, the subscribing application contains a default
DomainParticipant, subscriber and DataReader for a topic, using the datatype in our IDL file.

Step 12.​ Assign a proper topic name to the topic.

Apart from that, the entities will use a "default" QoS.

Step 13. ​Modify the creation of the DomainParticipant and DataReader to use the
ProximityData_Library::ProximityData_Profile​.

Step 14. ​If we wanted our subscribing application to process incoming data on another topic,
what other DDS Entities will we need to add at a minimum? What if we wanted to ​publish​ on a
different Topic instead?

Modify the Data Processing Function

In C / Traditional C++, the data is processed using a ​listener.​ In C++11, the data is processed
using a ​waitset.​ In both cases, the whole sample is printed.

Step 15.​ Modify the listener / waitset where the data is processed and print the fields one by
one.
Compile Your Changes and Run the Applications
Now that you have made changes to both the publisher and subscriber code, compile
the code with your modifications. (For general instructions on how to compile on
each operating system, see the ​README_<architecture>.txt​ file included with your
generated code).

You should see two applications in the ​objs/<architecture>​ directory:

● ProximityData_publisher.
● ProximityData_subscriber.

Step 16.​ Run both applications. Is there any error printed? From which directory should you run
the applications if you want the ​USER_QOS_PROFILES.xml​ file to be loaded?

Step 17.​ Verify that the requirements are met. How can you verify that requirement #1 is met?
How about #2?
1. Proximity Data should be processed by the controller every 500 milliseconds at most.
2. Proximity Data does not need to be delivered reliably, but an alert should be triggered if
the data is not received for 2 or more seconds. For this step, you may need the content
from VILT Session 7 (Subscribing to Data).

With both applications running, you should see the samples being received on the subscribing
application.

Step 18. ​Given what you know about DDS in terms of data modeling and QoS, can you identify
any problems with the solution we have created? Will there be any potential issues as this
project scales to support multiple sensors? If so, how could we resolve these issues?

Subscribing with Admin Console

With Admin Console, you are able to monitor and debug the system. Apart from that, you can
also subscribe to topics. Open ​Admin Console​ from ​RTI Launcher​.

You may be prompted to automatically or manually join domains if this the first time you have
opened ​Admin Console​. For the purposes of this exercise, choose to automatically join (the
default).

Switch to Data Visualization Perspective

Select the Data Visualization Perspective entry under the Visualization menu. (You may need to
close a Welcome tab first.) If you can't select the Data Visualization Perspective menu item, you
may already be in that mode.
Open the Topic Data Tab
From the DDS Logical View, click on the "Proximity Data" Topic to open the Topic View. After
switching to the Data Visualization Perspective, the main window will show the Topic Data tab.

Subscribe to "Proximity Data"

Admin Console​ itself is a DDS application, so it must also create DataReaders to subscribe to
the "Proximity Data" Topic. (See the ​Admin Console​ online Help for more information about
this.) When you subscribe to "Proximity Data" in ​Admin Console,​ it will create a DataReader for
the Topic.

Click on the ​Subscribe...​ button or right-click on the Topic in the DDS Logical View and select
Subscribe. This will open the ​Create Subscription​ dialog seen below. Click OK to subscribe to
the Topic.

Use the Topic Data Tab

After the Topic is subscribed to, you will see your "Proximity Data" updates.

Step 19. ​What can you observe is different from the data Admin Console receives and the data
your subscribing application receives?

In the ​Admin Console​ tool, you’re also able to inspect DataWriter and DataReaders. You can
even chart live data. You are highly encouraged to experiment with the Data Visualization
perspective to see how to use this functionality.

Takeaways
With steps 1-19 in this exercise, you have:
● Implemented a data model.
● Identified a data pattern based on requirements.
● Modified the generated example applications to implement a simple sensor → controller
example.
● Made use of the concept DataWriter, DataReader, DomainParticipant, topic and sample.
● Learnt how to use Admin Console to subscribe to data.
Exercise 2. Architectural considerations
Time to complete: 20 minutes.

Required VILT sessions for this module:

● DDS Data Model.
● Quality of Service & QoS XML configuration.

So far, in our system we have 2 DomainParticipants, 1 publisher, 1 DataWriter for the "Proximity
Data" topic, 1 subscriber and 1 DataReader for the "Proximity Data" topic. In our
USER_QOS_PROFILES.xml​ we have a P ​ roximityData_Library​ and a ​ProximityData_Profile​.

USER_QOS_PROFILES.xml modifications

The next steps in this project would be to add more topics and applications to our system. It
would not make much sense to design a profile for every topic, or use the profile that we are
currently using with the "Proximity Data" topic for a DomainParticipant.

Step 1.​ Create a new profile in ​USER_QOS_PROFILES.xml​ for DomainParticipants.

Suggestion: a good name would be "ParticipantBase".

Step 2.​ Add a QoS policy for this new profile.

Step 3.​ Split the profiles into 2 libraries: ​System_Library​ and ​Data_Library.​ Would you put the
new ​ParticipantBase​ profile into the ​System_Library​ or the ​Data_Library​? What about the
ProximityData_Profile​?

Step 4. ​Modify the creation of the 2 DomainParticipants so that they both use the new
DomainParticipant profile.

Step 5. ​Future topics may follow the same pattern as the "Proximity Data" topic. Do you think it
makes sense for them to have a profile per topic? Or should they reuse the same profile as the
"Proximity Data" topic? If they should reuse it, rename the profile so that it has a pattern-friendly
name.

If you renamed the profile and try to run the applications, you will see that they show an error.

Step 6.​ What does this error mean? Fix it before continuing to the next step.
ProximityData.idl modifications
In order to establish a correlation between the IDL definition (managed by System Architects)
and the code (managed by developers), we can set the topic names, QoS library names and
QoS profile names in the IDL file.

Step 7.​ Set the topic name, QoS library names and QoS profile names in the IDL file using
constants.

To propagate the change to the files generated by ​rtiddsgen,​ you will have to run it again. Notice
that running it again will not replace the already existing files and it will just skip them. You will
need to run ​rtiddsgen​ with the ​-replace​ option. W
​ ATCH OUT!​ Running ​rtiddsgen​ with the
-replace​ option will overwrite our publisher and subscriber if you also include the ​-example
option. Use the ​-platform​ option instead

Step 8. ​Re-run ​rtiddsgen​ with this command:

$ rtiddsgen ​-platform <architecture>​ -language <language>
ProximityData.idl -replace

With this, you can call the variables you just added to IDL from your applications.

Step 9.​ Modify the publishing and subscribing applications to make use of your new variables.
Compile them and verify that they run correctly.

The data type for the "Proximity Data" topic is in the ​ProximityData.idl​ file. If we used one file per
data type, we would end up with lots of different files. A different approach would be to add all
the type definitions to a single file, or split the type definitions into a limited number of files. Let's
create a file where we will have all our datatype definitions.

Step 10.​ Rename the IDL file to a more generic name. Suggestion: ​DatatypeDefinitions.idl​.

CMake
Since you renamed the file, the names of the generated files will also change. Remember that
rtiddsgen​ can also generate 2 example applications, one for the publisher and another for the
subscriber. In our case, we will need 3 applications: Proximity Sensor, Controller and Brake. A
multi-platform solution that we can use to meet our requirements for the 3 applications is
CMake. Another option would be to re-run ​rtiddsgen​ as many times as needed and manually
modify the ​makefiles​ to include as many applications as we need. Option 2 does not scale in the
long term. Let's go with the CMake option.

An example CMakeLists.txt file is provided in the ​exercise_2​ folder, along with a ​README.md
file.
Step 11.​ Before running CMake, change the names of the files we already created and put
them in a folder called ​srcCxx​:
● ProximityData_publisher → srcCxx/ProximitySensor​.
● ProximityData_subscriber → srcCxx/Controller​.

Step 12.​ Change the include headers in the ​ProximitySensor​ and ​Controller​ files to match the
new IDL.

Step 13.​ Follow the instructions in the ​README.md​ file to run CMake and compile the
applications.

Step 14.​ Verify that you can run the applications and that you observe the exact same behavior.
Feel free to explore the new architecture, specially the ​CMakeLists.txt​ file. Notice that ​rtiddsgen
is run automatically from the ​CMakeLists.txt​ file.

Note:​ Observe that the files generated by RTI Code Generator are located under the ​build/src
folder. These are files that ​should not be committed​ to your project's repository, since they
can be generated at compile time from the ​DatatypeDefinitions.idl​ file.

Takeaways
With steps 1-14 in this exercise, you have:
● Created a more scalable, systematic approach for ​USER_QOS_PROFILES.xml,​ adding
a participant-based profile and a pattern-based profile.
● Made a correlation between the IDL definition and the code by adding constant strings to
the IDL.
● Created an scalable infrastructure using CMake.
Exercise 3. "Device Status" topic
Time to complete: 20 minutes.

Required VILT sessions for this module:

● DDS Introduction.
● DDS Data Model.
● Quality of Service & QoS XML configuration.
● Recommended - Subscribing to Data.

Let's make our Proximity Sensor publish the "Device Status" topic.

Add the new type to IDL

First, the requirements for the new topic:
● "Device Status" topic:
○ A string identifying the device, up to 16 characters long.
○ An enum for the kind of device (SENSOR, ACTUATOR).
○ A union for the kind of device (if SENSOR: TEMPERATURE, PROXIMITY,
PRESSURE; if ACTUATOR: BRAKE, BEAM, HONK).
○ An enum for the status of the device (ON, OFF).
○ A string adding extra information. If there is no extra information to share, the
string should be empty.

Step 1.​ Implement the data model requirements in IDL as a ​DeviceStatus​ type. Do we need a
new IDL file or can we reuse ​DatatypeDefinitions.idl​?

Step 2.​ Do we need to update the ​CMakeLists.txt​ file?

Modify XML QoS

From the QoS perspective, we have new requirements for this topic:
1. Device status shall be published at start-up of the device, or on change.
2. The device shall not wait for subscribing applications to join the communication before
publishing the status.
3. The status of the device shall be delivered reliably.
4. The last update is the only meaningful update. Updates before that one shall be
discarded.

Step 3. ​Add these requirements to ​USER_QOS_PROFILES.xml​. Should we add a new QoS

library? What about a QoS profile? Is there a builtin QoS profile that meets all the requirements
specified?
Proximity Sensor
Step 4.​ Add the necessary entities to write the new topic in the Proximity Sensor. How many
new entities have you needed? Do you need an extra DomainParticipant? What about an extra
publisher?

Step 5. ​What QoS library and profile have you assigned to your new entities?

Step 6.​ Write a sample for this topic at start-up. What information does the Proximity Sensor
application need to include in this sample?

Step 7. ​Compile and run the Proximity Sensor application.

Step 8. ​Verify with Admin Console that the Proximity Sensor correctly publishes the information
you included in your sample. Would you need to change any QoS policy when creating Admin
Console's DataReader in order to receive the data?

Controller
The controller now needs to receive the "Device Status" topic.

Step 9.​ Add the necessary entities to receive the new topic in the Controller application. How
many new entities have you needed? Do you need an extra DomainParticipant? What about an
extra publisher?

Step 10. ​Compile and run the Controller application. Verify that you receive only one sample of
the "Device Status" topic at start-up.

We now have a new requirement for the controller:

1. The Controller shall notify the application when any new device (sensor or actuator) joins
the communication.

Step 11.​ Which mechanism would you use to be notified about this action? Implement it so that
the information is printed on the screen. For this step, you may need the content from VILT
Session 7 (Subscribing to Data).

Step 12. ​Verify that the controller is notified when a new DataWriter joins the communication.
For this step, you may need the content from VILT Session 7 (Subscribing to Data).

Takeaways
With steps 1-12 in this exercise, you have:
● Added a new datatype to your IDL definition with new types (union, enum).
 ● Added a new topic to your applications by adding the necessary entities (just one
DataWriter and one DataReader).
● Added a new QoS profile to satisfy the needs of a new communication pattern.
● Verified with Admin Console that you publish the data correctly.
● Been able to notify the application that a new entity has joined the communication.

Considerations about the provided solution

For the sake of simplifying the provided solution, under the ​exercise_3​ folder, you can see that
there is a lot of repeated code for both the "Proximity Data" and the "Device Status" topic. As
the system grows, a possible approach would be to templetize the creation of the different
entities based on their datatype and topic name.
Exercise 4. "Brake Command" topic
Time to complete: 45 minutes.

Required VILT sessions for this module:

● DDS Introduction.
● DDS Data Model.
● Quality of Service & QoS XML configuration.

Let's make our Controller publish the "Brake Command" topic.

Add the new type to IDL

First, the requirements for the new topic:
● "Brake Command" topic:
○ A string identifying the actuator that needs to receive the data, up to 16
characters long.
○ A float specifying the brake intensity as a percentage.

Step 1.​ Implement the data model requirements in IDL as a ​BrakeCommand​ type.

Modify XML QoS

From the QoS perspective, we have new requirements for this topic::
1. The command shall not be received by late-joiners.
2. The command shall be delivered reliably.
3. The last update is the only meaningful update. Updates before that one shall be
discarded.
4. The sample used to send the command should be deleted from both publishing and
subscribing applications after 5 seconds.

Step 3. ​Add these requirements to ​USER_QOS_PROFILES.xml​. Should we add a QoS profile?

Changes to CMakeLists.txt
The ​CMakeLists.txt f​ ile gives us the option of adding as many applications as we need. It is as
easy as adding another application in line 32.

Step 4. ​Create a new ​Brake.cxx​ file for the Brake application.

Step 5.​ Add a new ​Brake​ application to the ​CMakeLists.txt​ file subscribing to the "Brake
Command" topic.
"Brake Command" functionality
The requirements for the Controller application regarding the "Brake Command" topic are:
1. Only one sample shall be sent to notify about the brake intensity that needs to be
applied. That is, the "Brake Command" topic shall not be published periodically.
2. A "Brake Command" update will be published by the Controlleraccording to this logic:
a. If proximity > 100 meters, brake intensity = 0.
b. If 50 < proximity ≤ 100, brake intensity = 50.
c. If 0 ≤ proximity ≤ 50, brake intensity = 100.

Step 6. ​Add the necessary entities to the Controller application to publish the "Brake Command"
topic.

Step 7. ​Implement the new requirements in the Controller application. Populate the "Brake
Command" sample accordingly. Since the "Device Status" topic has not been published by the
Brake application yet, the Controller won't know what ​device_id​ to use. Let's leave it empty for
now.

Step 8.​ Compile the applications and verify that the Brake application receives the "Brake
Command" updates according to the ​proximity​ published by the Proximity Sensor application.

Takeaways
With steps 1-8 in this exercise, you have:
● Added a new datatype to your IDL definition.
● Added a new application to your system by modifying the ​CMakeLists.txt​ file and
creating a new file for the application.
● Implemented the "Brake Command" topic in the system.
● Created a new QoS profile to satisfy the needs of a new communication pattern.

Considerations about the provided solution

As with the previous exercise, for the sake of simplifying the provided solution, under the
exercise_4​ folder, you can see that there is a lot of repeated code in the Controller application.
As the system grows, a possible approach would be to templetize the creation of the different
entities based on their datatype and topic name.

Apart from that, for Traditional C++, the command is sent in a ​listener.​ As you will learn in
"Session 7, Subscribing to Data", this is not a good practice, since it is not recommended to do
lots of processing in a listener. In ​Exercise 6​, you will need to change the listener to a ​waitset​.
Exercise 5. "Device Status" topic for the Brake application
Time to complete: 30 minutes.

Required VILT sessions for this module:

● DDS Introduction.
● DDS Data Model.
● Quality of Service & QoS XML configuration.
● Subscribing to Data.

Let's make our Brake application publish the "Device Status" topic.

The type is already defined in the ​DatatypeDefinitions.idl​ as per ​Exercise 3​. In that exercise, we
also defined the necessary QoS profile for this topic.

Brake
Step 1.​ Add the necessary entities to write the "Device Status" topic in the Brake application.
How many new entities have you needed? Do you need an extra DomainParticipant? What
about an extra publisher?

Note:​ in the provided solution, for the Traditional C++ API, you can see that a new couple of
files have been added to abstract the creation of the "Device Status" topic. The Proximity
Sensor, the Controller and the Brake application make use of these new files to simplify the
code. Notice the change in ​CMakeLists.txt​ file to include the new file.

Step 2.​ Write a sample for this topic at start-up. Choose a different ​device_id​ from the one that
the Proximity Sensor uses.

Step 3. ​Compile and run the Brake application.

Step 4. ​Verify with Admin Console that the Proximity Sensor correctly publishes the information
you included in your sample.

Controller
The Controller now needs to receive the "Device Status" topic from the Brake.

Step 5.​ Do you need to add new entities to the Controller? Is it enough with the DataReader we
already had for the "Device Status" topic?

Let's use the information we have received from the Brake to populate the "Brake Command"
updates. We will need to include the ​device_id​ from the Brake application.
Step 6. ​Use the ​device_id​ received from the Brake application to populate the "Brake
Command" sample. Verify that the brake correctly receives its own ​device_id​ through the "Brake
Command" topic.

In a scenario with multiple brakes, all subscribing to the "Brake Command" topic, they would all
receive all the updates, even the ones that are not meant for them. This could be solved if each
of them implemented a content-filtered topic based on their own ​device_id.​ This way, only the
Brake that is supposed to receive the command will receive it.

Step 7.​ Implement a content-filtered topic based on the ​device_id​ on the Brake application.
Suggestion: check the CFT example on ​RTI's Github repository​.

Feel free to implement a logic in which you can verify that your Brake application is the only one
receiving a "Brake Command" update for its own ​device_id​.

Takeaways
With steps 1-7 in this exercise, you have:
● Added the "Device Status" topic to the Brake application and the Controller.
● Identified that the Controller is able to receive samples from any publishing application
for the "Device Status" topic. As you have learnt during the VILT, DDS does not require
any previous knowledge about a new DataWriter joining the communication.
● Implemented a CFT based on the ​device_id​ of the Brake. With this, only that specific
Brake will receive the updates that are meant for it.
● Reused datatypes and QoS profiles that you had already created in the past.

Considerations about the implemented system

By finishing exercise 5, you have finished implementing the necessary requirements
from the project definition!​ The next exercise will help you implement a listener instead of a
waitset if you are using the Traditional C++ API.
Exercise 6. Moving away from listeners to process data (if using
Traditional C++)
Time to complete: 20 minutes.

Required VILT sessions for this module:

● Subscribing to Data.

If you have been using the Traditional C++ API, you have seen that in order to process the data,
you have been using ​listeners​ instead of ​waitsets​. On Session 7, you learnt the consequences
of using listeners to process the data: if your application spens too long in the listener, you may
block the receive thread. Therefore, we will implement a waitset in this exercise for the Brake
application.

Step 1.​ Implement a ​read condition​ with a waitset to receive data from the "Brake Command"
topic in the Brake application. Suggestion: use the slides from Session 7 or check the ​waitsets
example​ on RTI's Github repository.

Step 2.​ Compile and run the applications to verify that you observe the same behavior.

Feel free to use a waitset for the rest of the applications. The solution provided only contains a
waitset for the Brake application.