-
 

Package Summary

Tags No category tags.
Version 0.20.5
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version humble
Last Updated 2024-07-26
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Audrow Nash
  • Michael Jeronimo

Authors

  • D. Hood
  • Mabel Zhang
  • Scott K Logan

Visualizing the effect of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.20.5 (2024-07-26)

0.20.4 (2024-05-15)

0.20.3 (2023-01-10)

0.20.2 (2022-05-10)

0.20.1 (2022-04-08)

0.20.0 (2022-03-01)

0.19.0 (2022-01-14)

0.18.0 (2021-12-17)

  • Update maintainers to Audrow Nash and Michael Jeronimo (#543)
  • Contributors: Audrow Nash

0.17.0 (2021-10-18)

0.16.0 (2021-08-11)

  • Small cleanups to the topic monitor. (#517)
  • Contributors: Chris Lalancette

0.15.0 (2021-05-14)

  • Fix topic_monitor for high publication rate (#461)
  • Use is_alive for threads. (#510)
  • Contributors: Chris Lalancette, Elias De Coninck

0.14.2 (2021-04-26)

0.14.1 (2021-04-19)

  • Use underscores instead of dashes in setup.cfg (#502)
  • Contributors: Ivan Santiago Paunovic

0.14.0 (2021-04-06)

  • Change index.ros.org -> docs.ros.org. (#496)
  • Contributors: Chris Lalancette

0.13.0 (2021-03-25)

0.12.1 (2021-03-18)

0.12.0 (2021-01-25)

0.11.0 (2020-12-10)

  • Update deprecated qos policy value names (#468)
  • Update the package.xml files with the latest Open Robotics maintainers (#466)
  • Contributors: Ivan Santiago Paunovic, Michael Jeronimo

0.10.1 (2020-09-21)

0.10.0 (2020-06-17)

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.27.2
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version iron
Last Updated 2024-07-11
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Aditya Pande
  • Audrow Nash
  • Michael Jeronimo

Authors

  • D. Hood
  • Mabel Zhang
  • Scott K Logan

Visualizing the effect of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo_launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo_launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo_launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.27.2 (2024-07-10)

  • fix readme for topic_monitor. (#631)
  • Contributors: Tomoya Fujita

0.27.1 (2023-05-11)

0.27.0 (2023-04-13)

0.26.0 (2023-04-11)

  • update launch file name format to match documentation (#588)
  • Contributors: Patrick Wspanialy

0.25.0 (2023-03-01)

0.24.1 (2023-02-24)

0.24.0 (2023-02-14)

  • [rolling] Update maintainers - 2022-11-07 (#589)
  • Contributors: Audrow Nash

0.23.0 (2022-11-02)

0.22.0 (2022-09-13)

0.21.0 (2022-04-29)

0.20.1 (2022-04-08)

0.20.0 (2022-03-01)

0.19.0 (2022-01-14)

0.18.0 (2021-12-17)

  • Update maintainers to Audrow Nash and Michael Jeronimo (#543)
  • Contributors: Audrow Nash

0.17.0 (2021-10-18)

0.16.0 (2021-08-11)

  • Small cleanups to the topic monitor. (#517)
  • Contributors: Chris Lalancette

0.15.0 (2021-05-14)

  • Fix topic_monitor for high publication rate (#461)
  • Use is_alive for threads. (#510)
  • Contributors: Chris Lalancette, Elias De Coninck

0.14.2 (2021-04-26)

0.14.1 (2021-04-19)

  • Use underscores instead of dashes in setup.cfg (#502)
  • Contributors: Ivan Santiago Paunovic

0.14.0 (2021-04-06)

  • Change index.ros.org -> docs.ros.org. (#496)
  • Contributors: Chris Lalancette

0.13.0 (2021-03-25)

0.12.1 (2021-03-18)

0.12.0 (2021-01-25)

0.11.0 (2020-12-10)

  • Update deprecated qos policy value names (#468)
  • Update the package.xml files with the latest Open Robotics maintainers (#466)
  • Contributors: Ivan Santiago Paunovic, Michael Jeronimo

0.10.1 (2020-09-21)

0.10.0 (2020-06-17)

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.33.5
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version jazzy
Last Updated 2024-09-06
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Aditya Pande
  • Audrow Nash

Authors

  • D. Hood
  • Mabel Zhang
  • Scott K Logan

Visualizing the effect of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo_launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo_launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo_launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.33.5 (2024-09-06)

0.33.4 (2024-06-27)

0.33.3 (2024-05-13)

0.33.2 (2024-03-28)

  • Update maintainer list in package.xml files (#665)
  • Contributors: Michael Jeronimo

0.33.1 (2024-02-07)

0.33.0 (2024-01-24)

0.32.1 (2023-12-26)

0.32.0 (2023-11-06)

0.31.1 (2023-09-07)

0.31.0 (2023-08-21)

0.30.1 (2023-07-11)

0.30.0 (2023-06-12)

0.29.0 (2023-06-07)

  • fix readme for topic_monitor. (#630)
  • Contributors: Tomoya Fujita

0.28.1 (2023-05-11)

0.28.0 (2023-04-27)

0.27.0 (2023-04-13)

0.26.0 (2023-04-11)

  • update launch file name format to match documentation (#588)
  • Contributors: Patrick Wspanialy

0.25.0 (2023-03-01)

0.24.1 (2023-02-24)

0.24.0 (2023-02-14)

  • [rolling] Update maintainers - 2022-11-07 (#589)
  • Contributors: Audrow Nash

0.23.0 (2022-11-02)

0.22.0 (2022-09-13)

0.21.0 (2022-04-29)

0.20.1 (2022-04-08)

0.20.0 (2022-03-01)

0.19.0 (2022-01-14)

0.18.0 (2021-12-17)

  • Update maintainers to Audrow Nash and Michael Jeronimo (#543)
  • Contributors: Audrow Nash

0.17.0 (2021-10-18)

0.16.0 (2021-08-11)

  • Small cleanups to the topic monitor. (#517)
  • Contributors: Chris Lalancette

0.15.0 (2021-05-14)

  • Fix topic_monitor for high publication rate (#461)
  • Use is_alive for threads. (#510)
  • Contributors: Chris Lalancette, Elias De Coninck

0.14.2 (2021-04-26)

0.14.1 (2021-04-19)

  • Use underscores instead of dashes in setup.cfg (#502)
  • Contributors: Ivan Santiago Paunovic

0.14.0 (2021-04-06)

  • Change index.ros.org -> docs.ros.org. (#496)
  • Contributors: Chris Lalancette

0.13.0 (2021-03-25)

0.12.1 (2021-03-18)

0.12.0 (2021-01-25)

0.11.0 (2020-12-10)

  • Update deprecated qos policy value names (#468)
  • Update the package.xml files with the latest Open Robotics maintainers (#466)
  • Contributors: Ivan Santiago Paunovic, Michael Jeronimo

0.10.1 (2020-09-21)

0.10.0 (2020-06-17)

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.34.2
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version rolling
Last Updated 2024-09-06
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Aditya Pande
  • Audrow Nash

Authors

  • D. Hood
  • Mabel Zhang
  • Scott K Logan

Visualizing the effect of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo_launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo_launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo_launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.34.2 (2024-07-29)

0.34.1 (2024-06-17)

0.34.0 (2024-04-26)

0.33.2 (2024-03-28)

  • Update maintainer list in package.xml files (#665)
  • Contributors: Michael Jeronimo

0.33.1 (2024-02-07)

0.33.0 (2024-01-24)

0.32.1 (2023-12-26)

0.32.0 (2023-11-06)

0.31.1 (2023-09-07)

0.31.0 (2023-08-21)

0.30.1 (2023-07-11)

0.30.0 (2023-06-12)

0.29.0 (2023-06-07)

  • fix readme for topic_monitor. (#630)
  • Contributors: Tomoya Fujita

0.28.1 (2023-05-11)

0.28.0 (2023-04-27)

0.27.0 (2023-04-13)

0.26.0 (2023-04-11)

  • update launch file name format to match documentation (#588)
  • Contributors: Patrick Wspanialy

0.25.0 (2023-03-01)

0.24.1 (2023-02-24)

0.24.0 (2023-02-14)

  • [rolling] Update maintainers - 2022-11-07 (#589)
  • Contributors: Audrow Nash

0.23.0 (2022-11-02)

0.22.0 (2022-09-13)

0.21.0 (2022-04-29)

0.20.1 (2022-04-08)

0.20.0 (2022-03-01)

0.19.0 (2022-01-14)

0.18.0 (2021-12-17)

  • Update maintainers to Audrow Nash and Michael Jeronimo (#543)
  • Contributors: Audrow Nash

0.17.0 (2021-10-18)

0.16.0 (2021-08-11)

  • Small cleanups to the topic monitor. (#517)
  • Contributors: Chris Lalancette

0.15.0 (2021-05-14)

  • Fix topic_monitor for high publication rate (#461)
  • Use is_alive for threads. (#510)
  • Contributors: Chris Lalancette, Elias De Coninck

0.14.2 (2021-04-26)

0.14.1 (2021-04-19)

  • Use underscores instead of dashes in setup.cfg (#502)
  • Contributors: Ivan Santiago Paunovic

0.14.0 (2021-04-06)

  • Change index.ros.org -> docs.ros.org. (#496)
  • Contributors: Chris Lalancette

0.13.0 (2021-03-25)

0.12.1 (2021-03-18)

0.12.0 (2021-01-25)

0.11.0 (2020-12-10)

  • Update deprecated qos policy value names (#468)
  • Update the package.xml files with the latest Open Robotics maintainers (#466)
  • Contributors: Ivan Santiago Paunovic, Michael Jeronimo

0.10.1 (2020-09-21)

0.10.0 (2020-06-17)

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.4.0
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version ardent
Last Updated 2017-12-09
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • D. Hood

Authors

No additional authors.

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib package installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor -- --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 run topic_monitor launch_reliability_demo executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor -- --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See [[ROS 2 Cleint Libraries]] for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor -- --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 run topic_monitor launch_depth_demo executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor -- --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See [[DDS and ROS Middleware Implementations]] for instructions on how to change the vendor.

  1. Run the ros2 run topic_monitor launch_fragmentation_demo executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor -- --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG
No CHANGELOG found.

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.5.1
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version bouncy
Last Updated 2018-10-30
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • D. Hood

Authors

No additional authors.

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib package installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See [[ROS 2 Cleint Libraries]] for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See [[DDS and ROS Middleware Implementations]] for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.6.2
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version crystal
Last Updated 2019-01-15
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Scott K Logan

Authors

  • D. Hood

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.8.4
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version eloquent
Last Updated 2020-11-04
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Mabel Zhang
  • Michael Jeronimo

Authors

  • Scott K Logan
  • D. Hood

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.7.9
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version dashing
Last Updated 2020-10-28
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Mabel Zhang
  • Michael Jeronimo

Authors

  • D. Hood
  • Scott K Logan

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.14.4
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version galactic
Last Updated 2022-12-07
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Mabel Zhang
  • Michael Jeronimo

Authors

  • D. Hood
  • Scott K Logan

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.14.4 (2022-12-06)

0.14.3 (2021-05-10)

  • Use is_alive for threads. (#510) (#513)
  • Contributors: Chris Lalancette

0.14.2 (2021-04-26)

0.14.1 (2021-04-19)

  • Use underscores instead of dashes in setup.cfg (#502)
  • Contributors: Ivan Santiago Paunovic

0.14.0 (2021-04-06)

  • Change index.ros.org -> docs.ros.org. (#496)
  • Contributors: Chris Lalancette

0.13.0 (2021-03-25)

0.12.1 (2021-03-18)

0.12.0 (2021-01-25)

0.11.0 (2020-12-10)

  • Update deprecated qos policy value names (#468)
  • Update the package.xml files with the latest Open Robotics maintainers (#466)
  • Contributors: Ivan Santiago Paunovic, Michael Jeronimo

0.10.1 (2020-09-21)

0.10.0 (2020-06-17)

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 0.9.4
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/demos.git
VCS Type git
VCS Version foxy
Last Updated 2022-07-25
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Package containing tools for monitoring ROS 2 topics.

Additional Links

No additional links.

Maintainers

  • Mabel Zhang
  • Michael Jeronimo

Authors

  • D. Hood
  • Scott K Logan

Visualizing the effector of QoS policies

This demo uses a “topic monitor” that can be used to visualize the statistics of ROS 2 topics that are publishing sequential data.

Background

Please read the About Quality of Service Settings page for background information about the Quality of Service settings available in ROS 2.

Running the demo

To visualize the reception rate, we will use a “topic monitor” that periodically calculates the reception rate of topics with publishers of periodic, sequential data.

If you have the Python3 matplotlib and tkinter packages installed, you can use the --display option to plot the reception rate of topics:

ros2 run topic_monitor topic_monitor --display

Alternatively, if you have ROS 1 installed, you can use the ROS 1 - ROS 2 bridge to plot the reception rate using ROS 1 tools such as rqt, or log it using rosbag. Be sure to run the bridge with --bridge-all-2to1-topics so that all topics will be bridged, that way rqt will be able to list the topics before it has subscribed to them.

For all invocations that follow make sure the same ROS_DOMAIN_ID has been set to the same value on the respective machines.

Comparing reliability QoS settings

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor reliability_demo.launch.py executable on the stationary machine. This will start two nodes: one publishing in “reliable” mode, and one in “best effort”.
  2. Start the monitor on a mobile machine such as a laptop. Use ros2 run topic_monitor topic_monitor --display --allowed-latency 5 to account for any latency that may occur re-sending the reliable messages.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the “reliable” topic has a reception rate that is almost always either 0 or 100%, while the “best effort” topic has a reception rate that fluctuates based on the strength of the connection.

Here’s an example plot:

reception rates plot

Comparison with ROS 1

The behavior shown here is comparable to the difference between that of TCPROS and UDPROS. One difference is that even the “reliable” reliability in ROS 2 uses UDP underneath, which allows for a range of behavior in between that of TCP and UDP. Another key difference is that UDPROS has currently only been implemented in the C++ ROS 1 client library, and is not an option for ROS 1 nodes written in Python. By contrast, the QoS settings available in ROS 2 are implemented in a core library that language-specific client libraries then make use of, meaning that these features only have to be implemented once and then just exposed through the different language interfaces. See ROS 2 Client Libraries for more information.

Comparing the latency of reliability QoS settings

Repeat the previous demo with a lower allowed latency on the topic monitor. That is, in step 2, run ros2 run topic_monitor topic_monitor --display --allowed-latency 1.

You should see that the “best effort” reception rate is unaffected, while the “reliable” reception rate drops sooner when the machines are going out of range of each other. This is because a “reliable” message may be re-sent multiple times in order to be delivered.

Comparing the effect of queue depth

As you saw in the previous demo, “reliable” data can take a while to be successfully sent if the network connection is not robust. If calls to publish are being made faster than the data can be acknowledged by the subscriber, the queue depth comes into play. A queue depth of 10 (the default) means that 10 messages will be kept in the publisher’s buffer before they get overwritten. If the 10th latest message has not been successfully acknowledged by the time the next message is published, it will be overwritten and the subscriber will not receive it, causing the reception rate to decline.

You will need two machines with ROS 2: one mobile and one stationary.

  1. Run the ros2 launch topic_monitor depth_demo.launch.py executable on the stationary machine. This will start some nodes publishing both small (payload of 1-character string) and large data (payload of 100,000-character string) with different depths: a pair publishing with a depth of 1, and a pair with a larger depth (50).
  2. Start the monitor on a mobile machine such as a laptop with ros2 run topic_monitor topic_monitor --display.
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the reception rate of the publishers with the higher depth is better than those with the depth of 1, because messages are less likely to get overwritten when data is taking longer to be acknowledged.

Comparing the effect of data size

The maximum message size in UDP (the underlying transport for ROS 2) is 64KB, after which messages get fragmented into smaller parts and sent individually. Larger message requires multiple fragments to be sent, and unless all fragments are received, the reception rate of the data declines. For connections with “reliable” reliability policy, when the lost fragments will be re-sent. For connections with “best effort” reliability, the loss of any fragment causes the whole message to be discarded by the subscriber.

You will need two machines running ROS 2: one stationary and one mobile.

Warning: this demo causes a lot of network traffic. You should not use the Fast RTPS ROS middleware implementation for this part. See DDS and ROS Middleware Implementations for instructions on how to change the vendor.

  1. Run the ros2 launch topic_monitor fragmentation_demo.launch.py executable on the stationary machine.
  2. Run ros2 run topic_monitor topic_monitor --display --expected-period 4 on the mobile machine. This will launch four publishers publishing messages of strings of different lengths: small (1), medium (50000), large (100000) and xlarge (150000).
  3. Take the mobile machine out of range of the monitor, and observe how the reception rates differ for the different topics.

You should see that the difference between the reception rate of the small and medium message sizes not the same as that for the medium and large message sizes. The large message requires two fragments to send it (the xlarge message three), and unless both fragments are received, the reception rate goes down.

CHANGELOG

Changelog for package topic_monitor

0.9.4 (2022-07-25)

  • Update maintainer list for Foxy (#471)
  • Contributors: Michael Jeronimo

0.9.3 (2020-06-01)

0.9.2 (2020-05-26)

  • Use consistent quotes in help messages (#447)
  • Contributors: Dirk Thomas

0.9.1 (2020-05-12)

0.9.0 (2020-04-30)

  • more verbose test_flake8 error messages (same as ros2/launch_ros#135)
  • Contributors: Dirk Thomas

0.8.4 (2019-11-19)

0.8.3 (2019-11-11)

0.8.2 (2019-11-08)

0.8.1 (2019-10-23)

  • Update setup.py versions
  • Contributors: Jacob Perron

0.8.0 (2019-09-26)

0.7.6 (2019-05-30)

0.7.5 (2019-05-29)

0.7.4 (2019-05-20)

  • Fix deprecation warnings (#334)
  • Update expected type name in topic monitor (#335)
  • Contributors: Jacob Perron

0.7.3 (2019-05-10)

0.7.2 (2019-05-08)

0.7.1 (2019-04-26)

0.7.0 (2019-04-14)

0.6.2 (2019-01-15)

0.6.1 (2018-12-13)

  • Fixed typo and broken links (#298) Mention tkinter package since it is required and not included by default on bionic
  • Contributors: Shane Loretz

0.6.0 (2018-12-07)

  • Updated package maintainer for logging_demo and topic_monitor (#285)
  • Fix lint warning from invalid escape sequences (#280)
  • Contributors: Jacob Perron, Scott K Logan

0.5.1 (2018-06-28)

0.5.0 (2018-06-27)

  • Updated the launch files for the topic monitor to use the new-style of launch. (#246)
  • Updated launch files to account for the "old launch" getting renamespaced as launch -> launch.legacy. (#239)
  • Contributors: Dirk Thomas, Mikael Arguedas, William Woodall, dhood

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

Name Deps
desktop

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged topic_monitor at Robotics Stack Exchange