You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Reader.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/Reader.hpp

If data is read synchronously, the user might be interested in the most recent data only. The Reader class can be used to create a data reader from which the most recent valid data can be requested using get_sample. Data is valid if its valid_after_stamp is lower than the current timestamp t_now that is passed to the function.

The Reader stores all received data in a ring buffer. The order in which data arrives is not regarded when data becomes overwritten. Thus, some slightly newer samples might get lost if get_sample is called infrequently - the Reader's buffer is not flushed regularly in between - and if data does not arrive in the correct order.

ReaderAbstract.hpp

https://git.rwth-aachen.de/CPM/Project/Lab/software/-/blob/master/cpm_lib/include/cpm/ReaderAbstract.hpp

This is just a basic DDS reader, which only offers information regarding matched publications and a take() function. It does not require the user to know or understand DDS implementation details and is thus recommended whenever a basic reader is required in your application. Setting QoS parameters is available through the constructor. 

AsyncReader.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/AsyncReader.hpp

Data received by a RTI DDS DataReader can either be read synchronously or asynchronously. The latter requires the usage of e.g. a StatusCondition, an AsyncWaitSet and a callback function. To save the users the time to look up which StatusCondition is (mostly) required and to write the > 10 lines of code required for every single reader that relies on a callback function, AsyncReader is provided as a sort of wrapper that performs the set-up.

The class must be passed a callback function, a domain participant and a topic (or a filtered topic). Reliable communication can be turned on / off with a boolean parameter.

MultiVehicleReader.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/MultiVehicleReader.hpp

Like Reader.hpp, but for multiple vehicles at once: Gather all received messages of type T by all vehicles that publish on the (filtered) topic my_topic, then return all newest samples when get_samples is used. For more information on the implementation, refer to Reader.hpp.

ParticipantSingleton.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/ParticipantSingleton.hpp

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.

Participant.hpp

https://git.rwth-aachen.de/CPM/Project/Lab/software/-/blob/master/cpm_lib/include/cpm/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.

Writer.hpp

https://git.rwth-aachen.de/CPM/Project/Lab/software/-/blob/master/cpm_lib/include/cpm/Writer.hpp

This is just a basic DDS writer, which only offers information regarding matched subscriptions and a write() function. It does not require the user to know or understand DDS implementation details and is thus recommended whenever a basic writer is required in your application. Setting QoS parameters is available through the constructor. 

get_topic.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/get_topic.hpp

For each domain participant, a topic can only be created if a topic with the same name has not been created before. This can lead to some trouble, e.g. if different classes depend on the same topic object but sharing it would be too complicated or would result in ugly code / a lack of data abstraction. RTI DDS provides a find method to find already created topics. As the user should, in our opinion, not be forced to decide which object should be created first or to find out which topics have already been created by the lib, get_topic uses both the create and the find method. Independent from the order in which the objects are created, get_topic returns the required topic object without throwing an error.

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.

VehicleIDFilteredTopic.hpp

https://github.com/embedded-software-laboratory/cpm_lab/blob/master/cpm_lib/include/cpm/VehicleIDFilteredTopic.hpp

If not all data that is received by a RTI DDS DataReader 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.


  • No labels