Why should I not send a nav2 goal pose in a relative frame?
Hi,
I was playing around with the nav2 stack and asked myself the following when I tried to send navigation goals:
Why is it not intended to send goals (geometry_msgs/PoseStamped) in frames other than the fixed map frame? For example sending the goal relative to base_link (or a sensor, gripper frame). It makes sense not to "drag" the frame through the whole navigation cycle which would probably result in an infinite movement (again: relative to the robot).
But is it not intended to hand in a frame_id in the header, transform it to the map frame (according to the header.stamp) and then continue using the map frame as a reference? Is this just not implemented or specifically not wanted?
I am aware that I can transform the pose myself and then hand it to nav2, but I was just curious why I am sending a stamped Pose but not take advantage of the header argument. Side note: In my case I was playing around with the nav2 simple commander using python and the options for tf2 transformations (python api) are not fully ported yet, why I came around the idea of including the frame in the nav2 msg directly.
Thanks!
Just a thought. I see there are two other functions that are expecting list poses stamped. goThroughPoses(poses) So a change will require that their functionality gets changed too
“In nominal execution, this will replan the path at every 3 seconds and pass that path onto the controller, similar to the behavior tree in Nav2 Behavior Trees. The planner though is now ComputePathThroughPoses taking a vector, goals, rather than a single pose goal to plan to. The RemovePassedGoals node is used to cull out goals that the robot has passed on its path. In this case, it is set to remove a pose from the poses when the robot is within 0.5 of the goal and it is the next goal in the list. This is implemented such that replanning can be computed after the robot has passed by some of the intermediary poses and not continue to try to replan through them in the future. This time, if the planner fails, it will trigger contextually aware recoveries in its subtree, clearing the global costmap. Additional recoveries can ...(more)