Page History
...
Most communication takes place within a single DDS domain. As - per application - only one domain participant should be created per domain, the most commonly used domain participant is provided via a Singleton. It is used in the cpm library as well. Whenever you need to communicate with the vehicles, parts of the LCC or other parts within the lab that do not use their own participant (like Middleware < - > HLC), use this participant. Most of our constructors give you an option to leave out a participant e.g. when creating a Writer - in that case, the default choice is the ParticipantSingleton.
Participant.hpp
A simple participant abstraction. You can pass a domain number and an optional QoS file. Use this whenever you need to create a participant that is not part of the common DDS domain given by our ParticipantSingleton. This participant needs to be passed explicitly to e.g. a Writer so that it does not use the default participant.
get_topic.hpp
...
If only the topic name is passed as a parameter, a topic is created / looked up for the participant singleton instance. Else, the participant must be passed as well.
Most of our other wrappers, e.g. the Writer, do not require you to specify a topic - a topic string for the topic name suffices. The topic is then looked up internally.
VehicleIDFilteredTopic.hpp
...
If not all data that is received by a RTI DDS DataReader Reader is of interest, a filter can be used to only process data that matches the filter expression. The most commonly used filter in this project filters by the vehicle id. The VehicleIDFilteredTopic thus provides a wrapper that uses such a filter. The vehicle id and the topic can be passed as a parameter, and the returned object can be used instead of the topic object. This allows e.g. the Reader to only process information that is relevant for it.
Overview
Content Tools