Nav2 Planner

[Amelie Robertos]

ThePlanner Server implements the server for handling the planner requests for the stack and host a map of plugin implementations.It will take in a goal and a planner plugin name to use and call the appropriate plugin to compute a path to the goal.It also hosts the global costmap.

The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to15 minutes in rcl but was changed to 10 seconds in this PR #1012, which may be less thansome actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline.This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround

In the /opt/ros/foxy/nav2_bringup/params, i found the nav2_params.yaml file. In the section controller_server, the plugin is set to dwb_core::DWBLocalPlanner. So, i guess the default local planner is dwb?

first i would like to thank you for your help.

I really appreciate it

Sorry for the confusion. I thought controller and local planner are the same thing.

Do you have an approach to change the local and global planner or do you know where i can change it ?

I guess there are more planner provided from the nav2 stack or do i have to create a planner by myself?

Yes, controller and local planner are the same. planner and global planner are the same.

local planner is not the same as global planner. planner is not the same as controller.

planner in ROS2 is global planner. controller in ROS2 is local planner. I hope now you are clear.

I believe there are 3 types of planners and 4 types of controllers currently in ROS2 Nav Stack.

And I am sure that you cannot use all of them on one type of robot. It may not be efficient.

If you want to create a planner or controller yourself, sure you can do so, but you need quite some knowledge on how to package it for ROS(1/2) nav stack.

Hello,I'm working with an Ackermann vehicle and using the TEB controller as the local planner (I built it for Foxy)After some tuning, I'm finally getting the vehicle to navigate kind of properly. However, the local planner's path is always different than the global planner's path. This is expected, I assume (but correct me if I'm wrong), but in some complex maneuvers, for example, when involving going in reverse, the path becomes really different and I think the global and local planners are kinda fighting each other. In most cases, the vehicle will make it to the goal but other times it just goes back and forth between the 2 paths and after a while it fails.

Below is an example of a case where the vehicle needs to reverse first to get to the goal. The good thing is that the paths look symmetrical, which means the 2 planners are using similar kinematic constraints. But, regardless, how can I solve this "conflict"?

Keep in mind TEB predates the Smac Planners by ... a decade or so, so it doesn't really know anything about the nature of the feasible path. Its used to working with outputs from NavFn which are infeasible and TEB's job is to make it feasible by those constraints itself -- so that's what its doing but ignoring Smac's requested maneuvers.

This isn't necessarily a problem unless you want it to exactly follow the Smac Planner's requested direction or TEB is oscillating so often that its not making progress. If you want the robot to always just follow the Smac Plan, you may want to instead just use the RPP controller which will just following the Smac plan exactly and there's no problem because its not a predictive controller that will try to deviate from the path in order to optimize for other criteria.

If you want that predictive behavior in general but not when talking about directional changes, I'd recommend using the MPPI controller that's been released which is a successor to TEB. This will do that for you for the most part currently and I'm working on some branches currently which will provide better enforce doing those path inversions at the same place as the Smac Planner requested very shortly (approx. by the end of the week).

Hi, I have been trying to move my create3 to Zenoh according to this tutorial.. I need some guidance on how to debug the problem. I can run both localization and mapping (it seems really smooth from preliminary tests, I can shutdown and restart nodes without issues, something that was instead a struggle with other DDSes) and set initial poses. Teleop with keyboard and joystick works as well. Unfortunately I can not issue navigation goals (see the log below). In particular, my setup is the following. The create3 (C3) and the raspberry (PI) communicate with each other in their own ROS_DOMAIN. PI runs just the lidar node and the Zenoh bridge. Then I have a laptop (LP) with another ROS_DOMAIN running the other end of Zenoh and the nav2 stack. As I said both localization and slam run properly, while I get the following log which seems to report a crash when issuing a goal: both bt_navigator and planner_server crash as I can not seen the respective logs into the default ros folder (which is also confirmed by monitoring the transition_event of the respective nodes). The following lines reporting a crash after issuing a goal while the robot was localized, i.e. it was given a map and an initial pose set via Rviz (notice that the launch file below from the turtlebot4 workspace below seems to just call the nav2 stack with the given config file).

Support questions are a better fit for since this discourse is more for general discussion, announcements or news. Or perhaps a issue report on the github of NAV2 itself if you are sure its an error in the package.

One hypothesis I have is that the LiDARs might be detecting parts of the robot (e.g., the truck) as obstacles, leading the robot to attempt to avoid its own "shadow". This behavior can be observed in this video Nav2 Smac Planner: Dubin Ackerman Local Planner Inadequate for Large Truck Robot

To address this, I attempted to filter out the scan beams that detect this part of the truck, hoping it would mitigate the issue. However, this approach didn't yield the desired results, as the robot still displayed the same erratic behavior, as shown in this video Laser Scan Filtering avoid false positives (Error) NAV2

Does anyone have insights or suggestions on how to effectively configure the local planner to deviate from the global plan for obstacle avoidance? Filtering the laser scan didn't seem to be effective. Are there other methods or configurations I should consider? Additionally, has anyone tried using TEB with nav2? Does it offer better performance in such scenarios? If yes, How to configure it/ integrate it with Nav2?

A planning module implementing the nav2_behavior_tree::ComputePathToPose interface is responsible for generating a feasible path given start and end robot poses. It loads a map of potential planner plugins to do the path generation in different user-defined situations.

A planning module implementing the nav2_behavior_tree::ComputePathToPose interface is responsible for generating a feasible path given start and end robot poses. It loads a map of potential planner plugins like NavFn to do the path generation in different user-defined situations.

In this tutorial, I will show you how to create a path planner plugin that will enable a robot to move in straight lines using the ROS 2 Navigation Stack (also known as Nav2). Here is the final output you will be able to achieve after going through this tutorial:

You can learn more about the nav2_straightline_planner plugin here.

The code that generates the straight-line path from the starting location to the goal location is the straight_line_planner.cpp file inside the src folder of the nav2_straightline_planner package.

In this part of the guide, we discuss how your robot can utilize different planner and controller algorithms to complete navigation tasks. We will discuss some of the available algorithm plugins you can use based on your robot type and environment.

Navigation algorithms are implemented in Nav2 through the use of plugins running on ROS action servers - the planner, controller and behavior servers (among others). For this section, we discuss the planner and controller servers, which are the heart of the navigation stack. These servers may implement one or more algorithm plugins each with its own configuration tailored for a specific action or robot state. This guide will highlight the different algorithms based on the type of robot and environment the robot is deployed in. This guide will not cover behaviors, smoothers, etc as those are dependent on application and not hardware/environment to offer generalized advice.

3a8082e126