Publishing Sensor Data Parent topic: Publishing Sensor Data

Platform-independent Publish Subscribe (PiPS)

You can use PiPS with any of its supported providers to share sensor data from sensors to a sensor application.

The pips_pubsub application is provided in the QNX Platform for ADAS to demonstrate sharing sensor data through PiPS. To use this application, ensure that you have installed the QNX Platform for ADAS 2.0 PiPS (Target Packages > ADAS) package.

The following diagram and associated descriptions illustrate the flow of sensor data from a Sensor service on one target to an application on a remote target using pips_pubsub.



  1. The Sensor service on one target (Target A) starts streaming sensor data from sensors that were specified in its sensor configuration file.

    The pips_pubsub (publisher) application registers to receive the sensor data that's streaming from the Sensor service.

  2. The pips_pubsub (publisher) application receives sensor data.

    The pips_pubsub (publisher) application accesses the sensor data that's streaming. It then writes the sensor data via PiPS to the pips_pubsub (subscriber) that's running on a remote target (Target B).

  3. The pips_pubsub (subscriber) application on the remote target (Target B) reads the sensor data that it receives through PiPS.
  4. The pips_pubsub (subscriber) application publishes the interim data to the Sensor service that was started with the interim data configuration file.
  5. The Sensor service on the remote target (Target B) starts streaming sensor data from sensors that were specified in the interim data configuration file.

    A sensor application (e.g., sensor_example receives the interim data that's streaming from the Sensor service. The sensor application must be appropriately registered with the Senser service to receive interim data.

You must have the Sensor service already running before you can start pips_pubsub. The Sensor service must be started with the appropriate sensor and interim data configuration files for your publisher and subscriber. Your interim data configuration file must contain interim data units that directly correspond to sensor units in your sensor configuration file. You can refer to the example pair of sensor and interim data configuration files from your reference images:

For more information on sensor and interim data configuration files, see “Sensor configuration file” and “Interim Data configuration file”, respectively.

Configuration

The pips_pubsub application uses configuration files to control properties such as data availability, data delivery, timeliness, and resource usage. The main changes you will want to make are to define Quality of Service (QoS) settings that are appropriate to transport sensor data in a system with multiple network interfaces. There's one configuration file associated with each of the supported PiPS providers. On your reference images, configuration files are available for these providers:

Note: To use RTI Connext DDS Pro or RTI Connext DDS Micro, you must contact RTI to get license.
For example: 
{
	"name":"FASTRTPSDDS",
	"dll":"pips-fastrtps-provider.so",
	"domain-id":13,
	"qos":{
		"resource":{
			"max-samples":1,
			"max-instances":1,
			"max-samples-per-instance":1,
			"allocated-samples":1,
		},
		"history":{
			"policy":"last",
			"depth":1,
		},
		"reader":{
			"reliability":"reliable",
			"durability":"volatile",
		},
		"writer":{
			"reliability":"reliable",
			"durability":"volatile",
		},
	},
}
The exact parameters that you can set and the arrangement of the nested JSON objects that store them vary with the provider, but the following parameters apply to the Fast RTPS and RTI Connext providers:
name
Name for referring to the provider from the pips_pubsub command line
dll
Library file that implements the provider
domain-id
Publishers and subscribers can talk to each other only if they have the same domain-id setting. This attribute lets you avoid contention on a network and perform parallel isolated testing of identical systems.
max-samples
Samples are data updates exchanged through topics (which represent data types). The max-samples attribute limits the number of samples available to each reader (subscriber) or writer (publisher).
max-instances
Limits the number of readers or writers per topic. Currently for pips_pubsub, this must be 1.
max-samples-per-instance
Limits the number of samples that can be loaded by each reader or writer. Currently for pips_pubsub, this must be 1.
allocated-samples
Number of pre-allocated samples per reader or writer. This attribute lets pips_pubsub avoid allocating memory “on-the-fly” when reading or writing a sample.
history policy
  • all—keep the last few samples; the number kept is equal to the history depth
  • last—keep only the last sample
history depth
Number of samples to keep in the history for a reader. Due to race conditions with incoming packets, we recommend a depth of 3.
reliability
  • reliable—each write will be confirmed for reception, and no other write will go through until this happens
  • best-effort—each write will be sent to the underlying interface (network or otherwise), which may flood if writes are sent faster than the subscriber can read them
durability
  • volatile—after sending a sample, the writer discards it and it isn't available for reading by subscribers that join afterwards
  • local—the writer keeps a copy, as allowed by max-samples
Currently with pips_pubsub, this must be set to volatile.
publish-mode
If set to async for writers, the samples are delivered to readers asynchronously.
transport allowed-interfaces
Name of the interface, as listed by ifconfig (e.g., lo0, eq0, vx0).
discovery initial-peers
Interfaces allowed for discovery, as an array of strings (e.g., ["4@builtin.udpv4://127.0.0.1", "builtin.shmem://"]).
For more information about the configuration settings for specific providers, see the documentation from their vendors:
Parent topic: Publishing Sensor Data