Navigation2 Planner plugin best practices

Question

We're working on a modified version of the example "nav2_straightline_planner". Our goal is to plan a straight path from one waypoint to the next, without regard for the robot's position. This path is only changed after completing the current goal. As it is currently written, our Planner works as expected. We do not use obstacle avoidance of any kind, and do not plan to at the moment. The operating area of the robot is static.

My questions are:

• Is it bad practice to not use the current position of the bot when planning paths?
• Should paths always be planned from the origin of the robot without exception (base_link or similar)?
• Will allowing the robot to be "disconnected" from the planned path cause issues elsewhere (namely for the chosen Controller, RPP in our case)?

We've been running the robot in this current setup for weeks with pretty decent success. RPP does seem to need better tuning on our part to more closely follow the planned path.

It seems all of the provided Planners in the Navigation2 stack plan from the robots origin each iteration, unless I'm understanding that incorrectly.

Thank you

---

Originally posted by hapy-capy on ROS Answers with karma: 33 on 2022-11-01

Post score: 1

Answer 1

Will allowing the robot to be "disconnected" from the planned path cause issues elsewhere (namely for the chosen Controller, RPP in our case)?

No

Should paths always be planned from the origin of the robot without exception (base_link or similar)? Is it bad practice to not use the current position of the bot when planning paths?

Not necessarily, its up to the algorithm designer, though that's an atypical use of it (which you may wish to document), there's nothing technically wrong with it.

---

Originally posted by stevemacenski with karma: 8272 on 2022-11-02

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by hapy-capy on 2022-11-03:
Thank you for the clarification.

In our use case, the path placement is key to proper operation; the paths always needs to be in the same place. These paths (exclusively straight lines) are planned with very tight tolerances in a large outdoor space, relying heavily upon RTK. We're exploring creating static costmaps (without the use of lidar) to be used for keep-out zones lining the paths. We're avoiding traditional obstacle avoidance as we need to drive through what would be considered obstacles by a lidar/depth-sensing system; CV is currently too difficult/time-intensive to implement for our system.

We do plan to document, and share with the community portions of our work when developed further. We're grateful for the work that's been done by the community and hope to contribute.