|
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo_launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo_launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo_launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
Additional Links
Maintainers
- D. Hood
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor -- --display
. - 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.
- Run the
ros2 run topic_monitor launch_fragmentation_demo
executable on the stationary machine. - 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). - 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.
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
ros2run | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
Additional Links
Maintainers
- D. Hood
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 for package topic_monitor
0.5.1 (2018-06-28)
0.5.0 (2018-06-27)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 for package topic_monitor
0.14.4 (2022-12-06)
0.14.3 (2021-05-10)
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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |
Launch files
Messages
Services
Plugins
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
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.
- 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”. - 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. - 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:
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.
- 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). - Start the monitor on a mobile machine such as a laptop with
ros2 run topic_monitor topic_monitor --display
. - 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.
- Run the
ros2 launch topic_monitor fragmentation_demo.launch.py
executable on the stationary machine. - 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). - 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 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)
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
rclpy | |
launch | |
launch_ros | |
std_msgs | |
ament_flake8 | |
ament_pep257 |
System Dependencies
Name |
---|
python3-pytest |
Dependant Packages
Name | Deps |
---|---|
desktop |