Rosanswers logo

Hi there,

I'm new in ROS nav_stack. Currently, I'm working on navigation of a mobile robot (vehicular robot) and I am searching the "best" local planner for our application.

Currently, we are using TEB local planner and I am working on improving its performance of avoiding obstacles (dynamic and static obstacles).

But still it is not clear for me that beside of the mathematical algorithm to find the most optimized path, what is the difference between the DWA local planner (or the base local planner) and the TEB local planner? According to this question, they should have the same approach. Thus, I would like to know for a user that asks the robot to go from point A to point B, what is the difference, in user point of view, and the developer point of view, between the TEB local planner and the DWA local planner?

Also, according to this question there is no local planner for Dynamic obstacles and the only solution is to work on additional tracking and motion prediction on top of the costmap in TEB and DWA local planner. Do you have any other idea?

Thanks in advance,

Originally posted by Mobile_robot on ROS Answers with karma: 264 on 2017-10-30

Post score: 9

Original comments

Comment by aarontan on 2018-06-07:
hello, have you found a solution for this? I would like to know as well. Please share if you do.

Comment by Mobile_robot on 2018-07-05:
Not yet, unfortunately.


2 Answers 2


Rosanswers logo


the overall idea of both DWA and TEB is to predict/plan the motion of the robot along a given horizon while minimizing a given objective function and while adhering to kinodynamic constraints of the robot. After commanding only the first control action to the robot, the whole prediction/optimization is repeated. This principle is well known in control theory as receding horizon control or model predictive control. However, computing the optimal solution is computationally demanding and thus both approaches approximate the optimal solution in different ways and the actual optimization strategy differs.

Dynamic Window Approach (DWA)

The DWA performs a sample based optimization. It samples a control action in the feasible velocity space (usually a translational/angular velocity pair) and rolls out the trajectory for these particular sampled actions. Rollout means, that the trajectories are simulated according to the specified horizon length based on the robots motion model. One important detail is: the control action is kept constant along the whole prediction horizon. Hence it cannot predict motion reversals etc. After rolling out predictions for all samples, the best candidate is selected based on a specified cost function and constraints (including distance to global path, smoothness, obstacle clearance, ...).

Consequently, DWA includes two simplifications in order to keep the computation times low while achieving a certain amount of control performance. I will not go into the details regarding stability and recursive feasibility arising from the inherent suboptimality, but the approach works pretty well for differential-drive and omnidirectional robots. A benefit is, that the cost function can be non-smooth and so it is well-suited for grid-based evaluations. E.g. trajectories can be rasterized into the costmap in order to evaluate the cost (considering lethal grid cells and inflation cost). Furthermore, the DWA does not get stuck in local minima based on its initialization (of course, the robot can still get stuck due to a limited horizon length and fewer degrees of freedom in terms of control actions). Since DWA assumes constant control actions along the prediction horizon, the control of car-like robots is rather limited. There are some basic extensions to restrict the velocity search space to car-like compatible actions. But motion reversals are still not subject to optimization and hence parking maneuvers in confined spaces are intractable. Note, of course, motion reversals can occure during closed-loop control, but they are not part of the open-loop solution / prediction.

In Summary:

  • Suboptimal solutions without motion reversals (control actions are kept constant along the prediction horizon)
  • Well-suited for diff-drive/omnidirectional robots, but not for car-like robots
  • Supports non-smooth cost functions

Timed-Elastic-Band (TEB)

The TEB primarily tries to seek for the time-optimal solution, but you can also configure it for global reference path fidelity. The approach discretzies the trajectory along the prediction horizon in terms of time and applies a continuous numerical optimization scheme. Consequently, depending on the discretization resolution, the degrees of freedom along the prediciton horizon can be very high and motion reversals are supported. Furthermore, the constrained optimization problem is transformed into an unconstrained optimization problem to gain shorter computation times. This also implies that constraints (e.g. obstacle avoidance, velocity bounds, ...) can not be guaranteed in any case, so I suggest to check emergency cases in the robot's base driver or a dedicated node. Furthermore, the optimizer only finds local solutions, e.g. if the trajectory is initialized on the left side of an obstacle it remains there. The teb_local_planner is able to optimize multiple trajectories in different topologies (e.g. left and right) at once in order to find the solution. Since the approach relies on continuous optimization, the cost function must be smooth. It cannot cope with grids and costmaps for function evaluation. Currently, every lethal obstacle cell is considered as point-shaped obstacle which limits the approach to small/mid-sized local costmap sizes (and a fairly coarse costmap resolutions). The planner also copes with polygon-shaped obstacles (see the costmap_converter package to convert the costmap to more primitive obstacles, but it is still experimental). However, given a certain amount of computational power and a mild problem size, the planner achieves a much better controller performance, resolves more scenarios and also supports car-like robot motions.

In a recent version of the teb_local_planner, support for dynamic obstacles has been introduced. The performance highly depends on the obstacle tracking and state estimation accuracy. However, the costmap-converter package tries to track dynamic obstacles from the local costmap (experimentally).

In Summary:

  • The planned trajectories are closer to the actual optimal solution, but constraints are implemented as penalties only.
  • Suited for all robot types
  • Planning of multiple trajectory candidates in multiple topologies
  • Dynamic obstacle support (experimental)
  • Large computational burden


  • D. Fox, W. Burgard, S. Thrun: The dynamic window approach to collision avoidance. In: IEEE Robotics & Automation Magazine. 1997, pp. 23–33.
  • C. Rösmann, F. Hoffmann, T. Bertram: Integrated online trajectory planning and optimization in distinctive topologies. In: Robotics and Autonomous Systems, vol. 88, 2017, pp. 142–153.

Originally posted by croesmann with karma: 2531 on 2018-06-08

This answer was ACCEPTED on the original site

Post score: 36


Rosanswers logo

Just leaving my 2 cents here...

Strictly speaking from my experience using the 2 planners on a diff drive robot.

It seems TEB provides more "intelligent" paths around obstacles whilst DWA sometimes get stuck at a local optima, especially when the the path around the obstacle requires the robot to temporarily move away from the goal.

Also I found that configuring DWA to perform rotation on spot properly was a pain, with tuning to the point that it felt like it was a hack, while TEB achieved it out of the box. DWA seemed to struggle particularly when the current orientation of the robot is around 90 degrees to the global plan it needs to move towards.

However, I did have to tune TEB to reduce the computation cost in order to have it running at a reasonable frequency. (I was running on a medium-sized local costmap and TEB was running at 1Hz out of the box, though other factors may have affected it)

Tweaks I made to have it work at a reasonable frequency (I was relying on the global planner for more sophisticated obstacle avoidance to I could afford less exploring in the local space):

no_inner_iterations: 1
no_outer_iterations: 1
enable_homotopy_class_planning: false
max_number_classes: 1

I might be doing something wrong with both planners, would gladly discuss further / appreciate any pointers!

Originally posted by Rufus with karma: 1083 on 2020-04-30

This answer was NOT ACCEPTED on the original site

Post score: 5

Original comments

Comment by croesmann on 2020-04-30:
1 Hz out of the box sounds really slow to me. Should be between 10 and 100 Hz on a reasonably recent i5/i7 CPU. What specs do you have? Also the costmap resolution is important as each occupied cell is treated as single obstacle by default.

Comment by Rufus on 2020-05-03:
I was running it on a fairly powerful i9 CPU, on a 160x160 costmap.

Comment by hashirzahir on 2020-05-03:
Hi, yes I can definitely verify the rotation problem with DWA planner. It was so hard to get it to perform spot turns and always seemed to prefer moving back and forth like a car until it aligned itself to the new orientation, which feels much slower than a spot turn. It achieved less than 5Hz for DWA planner on an intel celeron based SBC that was mounted on my small robot (many other nodes were running on the SBC as well).

Comment by artemiialessandrini on 2020-05-11:
I'm facing completely the same issues, as @Rufus mentioned. Especially when you don't want robot moving backward and setting min_vel_trans to positive, things never get resolved. Also, no in-place velocity theta offered, as It's offered in TrajectoryPlannerROS. Btw, there's something called DWB_local_planner, maybe this could be helpful if you are still considering going for DWA.

Comment by Rufus on 2020-05-11:
@artemiialessandrini I updated my answer on the tweaks I made to have it work at a higher frequency, not sure if it would be helpful for you. Also, I believe the documentation states that enforcing forward motion is done by penalizing backward motion via the weight_kinematics_forward_drive parameter.

Comment by artemiialessandrini on 2020-05-11:
Thanks for a quick response, @Rufus Initially I was talking about dwa_local_planner, but I'm likely to migrate to teb_local_planner, since I'm not satisfied with dwa performance, your advice is more than helpful!

Comment by distro on 2022-01-11:
@Rufus Hi, it seems you have a decent grasp on teb_local_planner, could you please spare some of your time to help me with this question here


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.