Revision history [back]

Here we have to analyse two different points. 1 - Parametrization problems (where you are focused) 2 - Theoretical limits of the navigation methods (used in the ROS navigation architecture)

1 - Concerning the parametrization you could try many many things. For instance you could make sure that the dynamic window limits for the angular velocities are wide enough to guarantee the exploration of the onself-rotation action.

2 - However, from my taste you are struggling with the theoretical limits of the navigation architecture. From my taste a non-holonomic the default navigation algorithms used in ROS are limitated. The global path plan computed by the disktra algoritm (like navfn does) won't be in many cases a good path to be followed by non-holonomic local-planners like the Dynamic Window Approach or the Trajectory Rollout algorithm.

In general, this approach works, specially when you have enough free space. But it shows serveral problems when there are obstacles in the surroundings of the initial path (where the robot has to turn back)

You could try to use the sbpl planner to avoid these situations. It takes into account the kinodynamic capabilities of the vehicle for computing the path during the global planning process (while the NavFn doesn't)

Here we have to analyse two different points. 1 - Parametrization problems (where you are focused) 2 - Theoretical limits of the navigation methods (used in the ROS navigation architecture)

1 - Concerning the parametrization you could try many many things. For instance you could make sure that the dynamic window limits for the angular velocities are wide enough to guarantee the exploration of the onself-rotation action.

2 - However, from my taste you are struggling with the theoretical limits of the navigation architecture. From my taste a non-holonomic the default navigation algorithms used in ROS are limitated. The global path plan computed by the disktra algoritm (like navfn does) won't be in many cases a good path to be followed by non-holonomic local-planners like the Dynamic Window Approach or the Trajectory Rollout algorithm.

In general, this approach works, specially when you have enough free space. But it shows serveral problems when there are obstacles in the surroundings of the initial path (where the robot has to turn back)

You could try to use the sbpl planner to avoid these situations. It takes into account the kinodynamic capabilities of the vehicle for computing the path during the global planning process (while the NavFn doesn't)

Here we have to analyse two different points. 1 - points.

1. Parametrization problems (where you are focused) 2 - focused)
2. Theoretical limits of the navigation methods (used in the ROS navigation architecture)

   1 -

Concerning the parametrization you could try many many things. For instance you could make sure that the dynamic window limits for the angular velocities are wide enough to guarantee the exploration of the onself-rotation action.

2 - However, from my taste you are struggling with the theoretical limits of the navigation architecture. From my taste a non-holonomic the default navigation algorithms used in ROS are limitated. The global path plan computed by the disktra algoritm (like navfn does) won't be in many cases a good path to be followed by non-holonomic local-planners like the Dynamic Window Approach or the Trajectory Rollout algorithm.

In general, this approach works, specially when you have enough free space. But it shows serveral problems when there are obstacles in the surroundings of the initial path (where the robot has to turn back)

You could try to use the sbpl planner to avoid these situations. It takes into account the kinodynamic capabilities of the vehicle for computing the path during the global planning process (while the NavFn doesn't)