Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publishing message immediately after topic creation with rospy is never sent. #176

Closed
ghost opened this issue Feb 22, 2013 · 5 comments
Closed
Labels

Comments

@ghost
Copy link

ghost commented Feb 22, 2013

Hi all,

After attempting to set the IP address of a bot on boot, I have run into an issue where the initial messages are never sent. Running 'rostopic echo "/TestTopic"' prior to the following code, I only receive 'Message 2'. Sleeping before message 1 also works.

[code]
import socket
import time
import std_msgs
import rospy
rospy.init_node("TestNode")
pub = rospy.Publisher("/TestTopic", std_msgs.msg.String)
pub.publish("Message 0")
time.sleep(1)
pub.publish("Message 1")
[/code]

The issue is easily solved in my situation, but may be problematic in situations other than mine, and the solution is not exactly optimal..

@dirk-thomas
Copy link
Member

This is a fundamental design choice of ROS and not "fixable". The connections between nodes happens after each node is started so messages can get lost until all these connections are made.

You should design your nodes in a way that they either do not rely on each message to arrive or consider using latched topics to at least get the last message when the connections is established after it was initially published.

@ghost
Copy link
Author

ghost commented Feb 22, 2013

I don't think you understand the issue.. We are using an Arduino with Rosserial to subscribe to a topic 'LCD' which we are sending the systems IP address on boot, the LCD is listening to a topic, then the python script starts, firing a message in code very similar to that above - the subscriber is already subscribed to the network prior to the publisher being created and sending a message, but no message is received.

@dirk-thomas
Copy link
Member

I think I do understand your scenario pretty well.

The problem is that the subscriber is only "announcing" to the rosmaster that he wants to subscribe to the topic, it is not directly subscribing to the topic. Then you start the publisher which "announces" to the rosmaster that he wants to publish to the topic. At that point in time there is not yet any connection established between the publisher and the subscriber therefore the first messages vanish.
Asynchronously the subscriber will now get notified by the master about the new publisher and then initiates a direct connection between the publisher and the subscriber. And only after this direct connection has been established the subscriber will receive the published message.

You will find the similar questions on answers.ros.org which boil down to the same source:

@clacarbone
Copy link

Dirk Thomas [email protected] wrote:

This is a fundamental design choice of ROS and not "fixable". The
connections between nodes happens after each node is started so
messages can get lost until all these connections are made.

Dirk I hit this same wall myself, coming to rely on delays to wait for the connections to choke up, but that is definitely not deterministic.

One thing I would like to see is a member (of both publisher and subscriber classes) to tell if the connection is established.
Bool ROS::subscriber.isestablished(topic)
Bool ROS::publisher.isestablished(topic)

That would be nice.
I don't see me having the time to attempt that in the near future but just for reference: would you mind pointing at the resources and modules I would need to tap into to make those members available?

Thanks
Claudio
-- Inviato dal mio cellulare Android con K-9 Mail.

@dirk-thomas
Copy link
Member

The approach you describe is not possible. A publisher has separate connections to each subscriber. An by definition in a publish/subscribe system the publisher is decoupled from the subscriber so he does not know how many subscribers should be there.

You can already check the number of current connections for a publisher and subscriber (get_num_connections()) but adding such logic into your nodes makes them less flexible and reusable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants