Ask Your Question
0

Could not determine the type for the passed topic

asked 2020-05-08 22:02:58 -0600

dawonn_haval gravatar image

updated 2020-05-16 11:27:20 -0600

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!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
-1

answered 2020-05-15 10:43:51 -0600

dawonn_haval gravatar image

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/commi...

edit flag offensive delete link more

Comments

That doesn't explain why it doesn't work when the type is provided in the command line.

Dirk Thomas gravatar image Dirk Thomas  ( 2020-05-15 11:21:33 -0600 )edit

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

dawonn_haval gravatar image dawonn_haval  ( 2020-05-15 12:30:35 -0600 )edit

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

dawonn_haval gravatar image dawonn_haval  ( 2020-05-15 14:27:09 -0600 )edit

You can edit your question and add more information.

Dirk Thomas gravatar image Dirk Thomas  ( 2020-05-15 14:32:01 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2020-05-08 22:02:58 -0600

Seen: 176 times

Last updated: May 16 '20