Could not determine the type for the passed topic
I have two systems that I'm struggling to get communicating reliably with ROS2 via ethernet. I've tried both Dashing and Foxy with the same results and would like to know what next steps I can take to troubleshoot this.
ros2 topic pub /str1 std_msgs/msg/String 'data: pie'
Publishing #### ...
ros2 topic echo /str1
Could not determine the type for the passed topic
- providing the type on the echo never actually prints our any messages
- echo from the same machine works
- the topic shows up on the ros2 topic list on both machines
- ros2 multicast receive / send functions as expected
- i have tried all four RMW with the same results.
- I have tried foxy latest, but prefer to continue using dashing.
- Ethernet between the two hosts, private network.
Update 5/14
This commit has helpd significantly, but the issues persist. I have a better test procedure now:
- I'm building foxy from source on both systems, with no custom nodes.
- On both hosts I monitor topic info:
watch -n 0.1 ros2 topic info -v /str1 - On one host I pub via cli:
ros2 topic pub /str1 std_msgs/msg/String 'data: 111111' - On one host I sub via cli:
ros2 topic echo /str1
Prior to the commit above the remote nodes would disappear from the topic info list after ~4 minutes, but now it seems to be somewhat robust. In the past week I have only had one instance of the problem. Passing the --no-daemon flag makes the original fault reoccur.
So, while helpful, I think there's still an underlying issue with the DDS discovery process for remote hosts. I'm looking for some help on where to look and how to troubleshoot this further.
Here's a screen cap of the test. The top three and bottom three terminals are on different hosts. You can see the remote ros nodes disappear at about 4:30. I then restarted the publisher and you can see some interesting 'flashing' of the remote nodes, followed by another complete dropout at the end. Hope this helps trigger some thoughts on what could be wrong. The behavior is 100% reproducible here.
Thanks for your guidance!
Asked by dawonn_haval on 2020-05-08 22:02:58 UTC
Answers
The cli tools did not use the ros2 daemon for discovery before Foxy. Since remote hosts took a while to respond and the CLI tools don't take long to execute, the remote hosts would be missed on occasion.
https://github.com/ros2/ros2cli/commit/2ea0bccca965585a0f2aee7a52ed655a2b4af362
Asked by dawonn_haval on 2020-05-15 10:43:51 UTC
Comments
That doesn't explain why it doesn't work when the type is provided in the command line.
Asked by Dirk Thomas on 2020-05-15 11:21:33 UTC
good point, but in any case I have been dealing with poor stability of remote nodes with ROS2 for months and that commit resolved the issue with the cli tools. :) I will admit that the daemon is probably just covering up the underlying issue; I am guessing that something with the DDS discovery is not working as expected. I still have issues with ros bag not working well...
Asked by dawonn_haval on 2020-05-15 12:30:35 UTC
I take it all back; the system is more robust, but I just had a similar communication dropout just now. Restarting the system resolved it for now, but I guess I still need help identifying the root cause....
FWIW, I have a better test procedure but I'm not sure if I should edit this question or make a new one...
Asked by dawonn_haval on 2020-05-15 14:27:09 UTC
You can edit your question and add more information.
Asked by Dirk Thomas on 2020-05-15 14:32:01 UTC
Comments