Skip to content
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

ROS Galactic groot monitoring #2406

Closed
kribe48 opened this issue Jun 14, 2021 · 3 comments · Fixed by #2627
Closed

ROS Galactic groot monitoring #2406

kribe48 opened this issue Jun 14, 2021 · 3 comments · Fixed by #2627

Comments

@kribe48
Copy link

kribe48 commented Jun 14, 2021

Bug report

In ROS galactic, an additional action server has been added (navigate through poses). However, both servers use the same groot_zmq_publisher/server_port parameter values. This makes it impossible for me to monitor the behavior trees in groot. Am I using it wrong, or is it a bug that needs to be updated?

  • Operating System:
    ubuntu 20.04
  • ROS2 Version:
    Galactic
  • Version or commit hash:
    From source

Expected behavior

Able to monitor both navigate through poses and navigate to pose in groot

Actual behavior

Not possible to monitor either of them

@SteveMacenski
Copy link
Member

SteveMacenski commented Jun 14, 2021

This is a known issue with Groot, that it only allows a single instance per process. I'd welcome a PR to help resolve this, but as I alluded to this ticket, if this isn't resolved relatively soon, my tentative plan is to strip support for groot out of Nav2 since it seems to be causing issues with critically needed features.

Destroying and replacing Groot objects every time the navigator changes turns out to not be as straight forward as I thought it would be, so you'd be correct that right now it only works with NavigateToPose actions, not NavigateThroughPoses.

I have no issue with Groot, but this seems to be causing us a number of different issues. I'd really appreciate a PR with a fix to this if you have the cycles. That would greatly increase the likelihood it stays in the stack if this is something you rely on!

@SteveMacenski
Copy link
Member

I believe #2409 would resolve these concerns @kribe48. Do you agree?

@kribe48
Copy link
Author

kribe48 commented Jun 21, 2021

Yes, I agree!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants