Add new navigate with replanning Objective and only have front lidar …

[bgill92]

…on the ur5e

[bkanator]

interesting, so I verified that it is working.
A couple notes though 1) it does not confirm the path, which may be a nice to have. 2) it does not show the re-plans or path it is about to take ? and on my first attempt I 3) got it into an infinite re-plan loop

I took a video of the first try and just luckily picked a final goal it can never get to! ha. So it is definitely re-planning!

so that leads to 4) should we somehow realize the goal is unachievable and notify the user, or should they be smart enough to just hit stop objective like I did. Watch below

replan-2026-04-02_15.56.34.mp4

[griswaldbrooks]

Agree with @bkanator on 1.
For 2, this ticket https://github.com/PickNikRobotics/moveit_pro/issues/17813 is supposed to do that. On 3, @bgill92 should this be handled by configuring the timeout on NavigateToPoseAction or can the recovery server be configured somehow? For me, timeouts don't always make sense as something close to the robot and ones far away will take different times... though... I'm not sure the robot ever failed, it just kept trying

[griswaldbrooks]

https://docs.nav2.org/behavior_trees/trees/nav_to_pose_recovery.html says it should try 6 times, but doesn't say what constitutes failure without reading the tree

[bgill92]

@bkanator @griswaldbrooks

1. Right now with NavigateToPoseAction, there is no mechanism to extract the path or tell it to wait for initial path confirmation. The Behavior sends the pose goal to the /navigate_to_pose action server and it automatically starts to navigate. I could add a VisualizePose and maybe a breakpoint or something? But the path cannot be visualized until the frontend has been updated as stated by the ticket Griz linked
2. I think an alternate can be to increase the size of the inflation for the local costmap so that the robot doesn't get into those nooks and crannies in the local costmap that causes it to keep replanning.