Can you please show us some code? I suspect you're sending the message "too soon", which leads to your message getting lost, as no subscriber has connected yet.
This is one of the reasons why using the Action server is preferred / recommended: you are guaranteed to receive feedback.
Edit:
The subscriber is started manually before launching the script - it should have enough time to set up [..]
It's not about the subscriber having time to set up, it's the time needed to establish communication between the publisher and the subscriber.
Your code shows virtually zero time between creating the publisher and publishing the first message, so I would expect it to get lost.
re: get_num_connections()
: that should help, yes. Wait until that returns 1
(or as many subscribers that you are expecting / require).
If you're still losing messages, then it could still be that you're publishing too soon. There's nothing specific in the driver that affects any of this, it's all basic roscpp
.
Originally posted by gvdhoorn with karma: 86574 on 2019-01-22
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by trhfdntzrtfghdgh on 2019-01-23:
@gvdhoorn I added the full code to my question and will try the action approach. The subscriber is started manually before launching the script - it should have enough time to set up before the first message is sent.
Comment by trhfdntzrtfghdgh on 2019-01-23:
Using the /joint_trajectory_action
works as expected (also with only one call).
@gvdhoorn Before sending my first message in the topic approach, calling pub.get_num_connections()
returns 1
, so there is a subscriber connected when I do the call. There also should be only one in my setup.
Comment by trhfdntzrtfghdgh on 2019-01-23:
So there is no way to check if messages can be sent safely (as I'd expect get_num_connections()
)? Or any recommended time to wait before sending messages?
Comment by gvdhoorn on 2019-01-23:
get_num_connections()
should work. Can you show how you are using it?
And it's not a solution, but using the action server is really recommended.
Edit: you don't have a rostopic echo ..
running somewhere? That would also count as a subscriber.
Comment by trhfdntzrtfghdgh on 2019-01-23:
I'm sorry, there actually was another subscriber (rqt) running...
When shutting down all other subscribers than the /motion_download_interface
I see 0 subscribers for the first iteration and one for the second one. So get_num_connections
seems to work.
Comment by gvdhoorn on 2019-01-23:
re: rqt: yes, that will interfere here.
Good to hear that we got things sorted out.
Comment by trhfdntzrtfghdgh on 2019-01-23:
Yes, indeed. I wonder why this is not documented. Like this you should expect the official python publisher tutorial (link in question) to not work...
Can I at least be sure that the action will be delivered?
Comment by gvdhoorn on 2019-01-23:
What is not documented?
Can I at least be sure that the action will be delivered?
If you set things up properly and use wait_for_server().
Comment by gvdhoorn on 2019-01-23:
And as always: documentation is either hosted on a wiki, or in API docs generated using Doxygen or Sphinx or some other tool.
ROS is (mostly) a community project. Without community members improving things like documentation, other users are going to run into the same questions again and again.
Comment by trhfdntzrtfghdgh on 2019-01-23:
Ah yes, I forgot about the wait_for_server()
.
The python publisher/subscriber tutorial lacks a warning that one needs to wait (for an undefined amount of time?!) before publishing a message - at least if you need it delivered. The code shown there also does not wait (that's why I did not).
Comment by gvdhoorn on 2019-01-23:\
The code shown there also does not wait (that's why I did not).
no, it doesn't. But that is because it uses a different approach: it's a periodic publisher. Anon-pub-sub is not really meant for guaranteed delivery of messages. It's fire-and-forget with no guarantees whatsoever. ..
Comment by gvdhoorn on 2019-01-23:
.. If you need guarantees (and feedback), use services (blocking calls and error messages) or actions (asynchronous services with futures and progress callbacks).
Topics are typically used for dataflows where a single lost msg is not a problem.