-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Multi-robot navigation (using multi_tb3_simulation_launch.py) does not work [Groot monitoring] #2386
Comments
PRs would be appreciated.
Looking at your log file, it probably has nothing to do with the log snippet added above |
@SteveMacenski This shouldn't be a gazebo problem for a number of reasons:
|
There's clearly a major error there -- I'd look into resolving that first. The lifecycle error is likely in response to not completing other lifecycle transitions or having errors itself as a direct result of this. It would probably not be worth looking into the lifecycle error until this was resolved since there is a high likelihood of correlation. |
I fixed the
I will continue looking into this. @SteveMacenski Any insight on what might be causing the |
Please submit a PR to update that in That error has some history in the ROS2 community if you google it, but I don't see a clear answer. I'd start with looking at the list of ros2 nodes and ros2 topics / srvs / actions and see if any are colliding (e.g. are their nodes or network objects not correctly namespaced under robot1 or robot2?) If so, then its probably a collision and that's DDS's way of telling you that you have 2 things with the same name/type/id on the network and its unhappy. It may be possible we made some changes by accident with leading |
The only thing I notice when inspecting topics is that robot2 has a
|
I analyzed the list and have the same conclusion. Looking at another example of a client node in costmap:
It looks like the WP follower is missing some of the fields for namespacing properly. Try updating the waypoint follower client node inputs as the costmap_2d format, that will probably resolve. In particular the extra |
I'm not sure the waypoint follower has to do with the I've also tried switching the order of the nodes in the launch file so that Also, having a look at the code for the rclcpp node, it seems to be in the same format as the costmap code.
Any ideas on how to proceed? |
I think I've narrowed down the issue, when I haven't looked further yet, but I guess error arise somewhere here Maybe it's conflicting ports/addresses, I don't know for sure. |
Ah I see, I think I have an understanding of the issue then. Groot monitoring only allows 1 zero-mq object per process (which was the root of another implicit issue in the stack). I don't see why it would have an issue with multiple processes, but its possible that with the multi-robot case, the ports are in collision with each other. You could try to change the port IDs to resolve. However, this is one of a few different issues that the live groot monitoring is causing us, so I'd also be open to a PR to simply remove this capability. I don't think many, if any, users rely on it and it has caused us a number of issues. Live BT monitoring was a "nice to have" but not if it conflicts with "need to have" features like the ability to spawn multiple robot instances on 1 machine. |
@tiffanyyk @AlexKaravaev Does this PR resolve your issues? #2409 |
I believe that the fix here is to set the groot parameters for each robot to be different. That would be the fix so that you can utilize groot in multirobot situations. However by default enabling it, they will collide with each other. As such, I have decided to turn groot off by default, so that it is only fired on when requested by a user. In that situation, then they'd be conciously adding the Closing this issue with the merging of #2417 because it implements your solution, we understand the problem (groot was on using the same ports for 2 instances) and the solution is to either disable if you don't want them or make sure your yaml file uses different ports for the robots so there is no collision. Thank you for reporting this issue and I will make sure to document this on navigation.ros.org for future consumption! Edit: docs PR ros-navigation/docs.nav2.org@8cbed5e |
Bug report
Required Info:
Steps to reproduce issue
Run the command:
In both of the rviz windows that open:
Startup
Expected behavior
Startup
should successfully start the nav2 stack for both robotsActual behavior
Startup
(lines 685 to 690 in the attached file):Additional information
The terminal output is attached here:
log_multi_tb3_sim.txt
The text was updated successfully, but these errors were encountered: