The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
To my surprise, the following simple program: [..] Prints 3
0s when I run a singlerostopic pub /topic std_msgs/Int32 "data: 0".
The behaviour you observe is actually as it should be, and the cause is not waitForMessage(..) doing something "wrong", but your expectations are incorrect.
The following is the output of the command you ran:
$ rostopic pub /topic std_msgs/Int32 "data: 0"
publishing and latching message. Press ctrl-C to terminate
Notice the "and latching message" part of what rostopic pub prints.
Latched publishers (wiki/roscpp/Overview/Publishers and Subscribers - Publisher Options) will republish the last published message upon subscription by new subscribers, even if those subscribers were not online when the initial message was published.
So in your case, rostopic pub publishes "the 0" once when it is started, and then subsequently again for every ros::Subscriber created by ros::topic::waitForMessage(..) (as that function creates a new subsciber every time it is run).
Receiving the same message with every waitForMessage(..) seems to be as it should.
One workaround is to add a
ros::Duration(1).sleep()between the waits [..]
That would surprise me actually, as that's not how latched publishers work.
As a final comment: please note that waitForMessage(..) is not intended to be used to periodically "sample" a message stream, or to implement some sort of rate-limiter (ie: calling waitForMessage(..) repeatedly in a while loop with a ros::Rate or something similar).
It is a fairly costly operation which is typically only used to get some initial state from a topic, or when really only a single message is needed for some reason.
In almost all other cases it would be better to use something like message_filters and/or regular subscribers.
| | 2 | No.2 Revision |
To my surprise, the following simple program: [..] Prints 3
0s when I run a singlerostopic pub /topic std_msgs/Int32 "data: 0".
The behaviour you observe is actually as it should be, and the cause is not waitForMessage(..) doing something "wrong", but your expectations are incorrect.
The following is the output of the command you ran:
$ rostopic pub /topic std_msgs/Int32 "data: 0"
publishing and latching message. Press ctrl-C to terminate
Notice the "and latching message" part of what rostopic pub prints.
Latched publishers (wiki/roscpp/Overview/Publishers and Subscribers - Publisher Options) will republish the last published message upon subscription by new subscribers, even if those subscribers were not online when the initial message was published.
So in your case, rostopic pub publishes "the 0" once when it is started, and then subsequently again for every ros::Subscriber created by ros::topic::waitForMessage(..) (as that function creates a new subsciber every time it is run).
Receiving the same message with every waitForMessage(..) seems to be as it should.
One workaround is to add a
ros::Duration(1).sleep()between the waits [..]
That would surprise me actually, as that's not how latched publishers work.
How can I have
waitForMessageactually wait for 3 publishes, provided that I don't know the interval between publishes?
I wouldn't know, as that's not what that function is for. How would it distinguish between "the same 0" and another message, which happens to also carry a 0?
As a final comment: please note that waitForMessage(..) is not intended to be used to periodically "sample" a message stream, or to implement some sort of rate-limiter (ie: calling waitForMessage(..) repeatedly in a while loop with a ros::Rate or something similar).
It is a fairly costly operation which is typically only used to get some initial state from a topic, or when really only a single message is needed for some reason.
In almost all other cases it would be better to use something like message_filters and/or regular subscribers.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.