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
Clin-Smooth opened this Issue Feb 22, 2013 · 5 comments

Comments

Projects
None yet
3 participants
@Clin-Smooth

Clin-Smooth 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

This comment has been minimized.

Show comment
Hide comment
@dirk-thomas

dirk-thomas Feb 22, 2013

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.

Member

dirk-thomas commented Feb 22, 2013

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.

@Clin-Smooth

This comment has been minimized.

Show comment
Hide comment
@Clin-Smooth

Clin-Smooth 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.

Clin-Smooth 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

This comment has been minimized.

Show comment
Hide comment
@dirk-thomas

dirk-thomas Feb 22, 2013

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:

Member

dirk-thomas commented Feb 22, 2013

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

This comment has been minimized.

Show comment
Hide comment
@clacarbone

clacarbone Feb 22, 2013

Dirk Thomas notifications@github.com 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.

clacarbone commented Feb 22, 2013

Dirk Thomas notifications@github.com 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

This comment has been minimized.

Show comment
Hide comment
@dirk-thomas

dirk-thomas Feb 22, 2013

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.

Member

dirk-thomas commented Feb 22, 2013

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