I’m out of town this week, so not much progress on resolving my issues - but I wanted to post a quick update on what has happened since I initially posted:
- I had a call with eProsima and they suggested a few debugging tips:
- They noted that there is a “keep alive” timeout, so I am avoiding shutting down nodes and then restarting them immediately (waiting at least a minute to make sure the connections have timed out)
- They noted that there is a “fastdds shmem clear” command which can clear the shared memory in case there is something left residually. This did not help with my issue.
- If you’re using the FastDDS monitor tool - it will only show one participant per process, so the number of participants will be different than “ros2 node list” displays.
With some additional testing, I found an interesting issue:
- I had been running “ros2 node list” to see if things were out there - and it doesn’t seem to report all the nodes (which was why I assumed this was a discovery issue)
- HOWEVER, this time around I decided to test running "ros2 topic echo /tf"even when “node list” doesn’t return everything, and that WORKED - I was definitely getting all three sets of TF data I would expect (map->odom, odom->base, everything else from robot_state_publisher).
- So… it appears this might actually be something slightly different than a pure discovery issue (since the CLI tools can connect but not navigation).