[nav2_rviz_plugins/Selector] Unable to set goal pose if we run rviz2 later #4754
Comments
Rviz has no relationship with Nav2 in terms of functional performance. However, as the Getting Started Guide mentions, you need to give the robot its initial pose on startup so that you can complete the map->odom->base_link transformation tree. You do that in tutorial / testing using rviz, though in production its based on the known robot's last pose. If you didn't have rviz launch, then you probably didn't set this initial pose, and thus you see the global costmap timing out. tl;dr: you need to set the initial pose. You can see this done in all Nav2 system tests, Nav2 python simple commander demos, and in other tutorial/educational demonstrations of Nav2 on GitHub :-) |
|
Hi @SteveMacenski, |
I guess, the following snippet tells a clear story to me, but I don't discount the opportunity that I'm an idiot on occasion 😆 This is telling me that the map frame isn't available -- ergo the initial pose wasn't set. Once we hit a set deadline, if we haven't got a valid TF tree, the global costmap node refuses to activate properly and returns a failure. That is new in Jazzy, previously it would retry forever, but it was pointed out that this was a bad idea. This is a parameter though that could be widened. Then, AMCL gives us logs that it cannot do anything because initial pose wasn't set. All roads seem to lead back to the initial pose wasn't set 🙃 |
I think this is my fault that I didn't provide a clear description. I recorded the video to help to clarify my question. If I run nav2 first and then rviz2, the global_costmap doesn't work nav2_rviz.mp4However it will succeed if I have a reverse order rviz_nav2.mp4
Perhaps this is the reason why the issue happened. My rivz2 is stuck for some time, and this might cause the timeout of global costmap. Would you mind pointing me where the parameter is? Thank you. |
|
What is the logging from rviz / nav2 when the rviz display starts to respond again? Clearly something timed out and I want to know what it is / what it is related to. It seems like perhaps the same global costmap lifecycle transition. What happens if you remove each of the Nav2 panel plugins, one at a time, and launch between them? Anyone in in particular have the issue removed if not present (again, I expect to be related to the initialization - so I would think the main Nav2 panel if any). |
After rviz display starts to respond again: rviz2 nav2 After setting initial pose rviz2 nav2
OK, I think the issue might come from this in rviz. It works perfectly if I remove Selector in rviz file. Here is the rviz file that works on my side. |
|
Hi @SteveMacenski I'm not sure if you think this is a bug or not. Let me know if I should reopen the issue. Thank you |
SteveMacenski
changed the title
|
I agree this is a bug -- CC @padhupradheep as the author of this newer panel. I suspect it has to do with https://github.com/ros-navigation/navigation2/blob/main/nav2_rviz_plugins/src/selector.cpp#L154-L168 |
|
Thanks for reporting @evshary I'll take a look at it soon. |
|
I know you've got a few things on your queue @padhupradheep for Nav2 -- I'd put this on the bottom, the other 2 are higher priority. This is something we should fix for sure, but isn't functionally breaking Nav2 uses in deployed applications, so I would deprioritize this over those If @evshary or another user wants to jump in to debug further, I'm sure we'd appreciate it! |
|
Did a very quick dig, seems to be that for some reason, when the plugin loader is called here in the above line and when theget_parameters function is called here:
for some reason we have to wait few minutes for the function to return the parameters. This never occurred here
This is weird to see the |
|
That is odd, considering that the controller is actually activated before the planner https://github.com/ros-navigation/navigation2/blob/main/nav2_bringup/launch/navigation_launch.py#L44 Might be better to have it do this update in a separate thread so that it doesn't block bringup - then update its values once you have them. We could also do an async param get and after some timeout retry once so that if there's some discovery issues we try again once things have calmed down |
|
Makes sense to me. @evshary you want to give a swing at it? |
|
Hi @padhupradheep Thanks for looking into it. I could give it a try, but I've been blocked with other issues currently. Therefore, don't wait for me if this is urgent. |
Bug report
Required Info:
Steps to reproduce issue
Expected behavior
The result should do nothing with the execution order.
Actual behavior
The rviz is stuck for a while.
After waiting some time, we can set the initial pose, but the global costmap doesn't work properly.
Additional information
There is no any issue if we run rviz and nav2 together.
It also works well if we run rviz first and then nav2.
Here is the log in nav2:
I guess this log might be the key
The text was updated successfully, but these errors were encountered: