Dynamic Window Approach (DWA)

Dynamic Window Approach (DWA) – definition

Dynamic Window Approach (DWA) is a local motion-planning method for mobile robots. It selects a collision-free linear and angular velocity command from a set of velocities that the robot can physically reach during a short control interval. The method was described by Dieter Fox, Wolfram Burgard, and Sebastian Thrun in 1997 for collision avoidance with dynamic constraints on mobile robots. Source: IEEE Robotics & Automation Magazine, 1997.

For a differential-drive UGV, DWA searches in velocity space rather than directly searching for a geometric path. At every controller cycle, it evaluates candidate commands (v, ω), where v is linear velocity in metres per second and ω is angular velocity in radians per second. The selected command should follow the global path, maintain clearance from obstacles, respect acceleration limits, and make measurable progress toward the navigation goal.

DWA is a local planner. It does not create a global map, perform SLAM, or replace global route planning. In a ROS 2 navigation stack, DWA typically consumes a local costmap, robot odometry, and a path produced by a global planner. It then produces velocity commands for the mobile base controller.

How DWA selects a velocity command

The “dynamic window” is the set of commands reachable from the robot’s current velocity within one control step. It is constrained by the drivetrain’s velocity limits, acceleration limits, and the ability to stop before a collision.

The admissible command set can be expressed as follows:

Vr = Vs ∩ Vd ∩ Va

In this model, Vs represents the platform velocity limits, Vd represents velocities reachable under acceleration limits, and Va represents velocities that allow braking before an obstacle. Vr is the resulting admissible velocity set. A candidate trajectory is simulated over a short horizon and scored. The exact score function is implementation-specific, but commonly includes path alignment, distance to the goal, obstacle cost, forward velocity, and oscillation penalties.

A DWA implementation therefore requires correctly configured kinematic and safety constraints. The main constraints are:

Maximum and minimum linear velocity.
Maximum angular velocity.
Linear and angular acceleration limits.
Robot footprint or collision radius.
Costmap obstacle inflation and sensor observation ranges.
Controller frequency, trajectory simulation time, and velocity sample count.

DWA in ROS 1 and ROS 2

ROS 1 provides the dwa_local_planner package, historically used with the ROS Navigation Stack. It implements a DWA-based local planner and publishes velocity commands for a mobile base. Its main configuration interface is based on parameters such as max_vel_x, max_rot_vel, acc_lim_x, acc_lim_theta, and cost-function weights. Source: ROS Wiki, dwa_local_planner documentation.

In ROS 2, the Navigation2 framework, commonly called Nav2, provides a Dynamic Window Approach-based implementation through the DWB controller plugin. The plugin is loaded by Nav2’s Controller Server and is commonly configured as dwb_core::DWBLocalPlanner. Source: Nav2 DWB Controller documentation.

Nav2 separates planning from control. The Planner Server generates a global path, while the Controller Server repeatedly evaluates that path against the local costmap and robot state. The controller normally receives pose, velocity, costmap, and path data through Nav2 actions, ROS topics, and TF2 transforms.

ROS interface	Typical message type	Purpose in DWA navigation
Odometry	`nav_msgs/msg/Odometry`	Current velocity; the robot pose is generally obtained through TF2.
Global path	`nav_msgs/msg/Path`	Reference path used by path and goal critics.
Velocity command	`geometry_msgs/msg/TwistStamped` or `geometry_msgs/msg/Twist`	Command sent toward the base controller; the message type depends on the Nav2 version and configuration.
Transforms	TF2	Transforms between `map`, `odom`, and `base_link`.

The frame relationship used by mobile ROS systems follows the conventions defined by REP 105. In particular, odom should provide continuous local odometry, while map may change after global localization or SLAM corrections. Source: ROS REP 105, Coordinate Frames for Mobile Platforms.

Example DWB configuration in ROS 2

The following fragment shows a simplified Nav2 DWB configuration. Values must be measured and validated for the specific drivetrain, payload, tyre condition, power system, and operating environment. They are not universal Leo Rover or Raph Rover specifications.

controller_server:
  ros__parameters:
    controller_frequency: 20.0

    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      min_vel_x: 0.0
      max_vel_x: 0.4
      max_vel_theta: 1.0
      acc_lim_x: 0.5
      acc_lim_theta: 1.0
      vx_samples: 20
      vtheta_samples: 20
      critics:
        - RotateToGoal
        - Oscillation
        - BaseObstacle
        - GoalAlign
        - PathAlign
        - PathDist
        - GoalDist

Nav2 documents the available DWB critics and plugin parameters, including obstacle, path-distance, goal-distance, alignment, and rotation-to-goal critics. Source: Nav2 documentation.

DWA on Leo Rover and Raph Rover

Leo Rover is a four-wheel, differential-drive mobile platform with an IP55 enclosure and an integrated Raspberry Pi compute unit. It supports ROS 2, including ROS 2 Humble, but autonomous navigation is not available without integrating localisation, obstacle sensing, transforms, a costmap, and a navigation stack. Source: Leo Rover technical documentation.

For Leo Rover, DWA is suitable when the robot operates at moderate speed in laboratories, corridors, indoor test areas, or controlled outdoor environments. The controller should receive wheel odometry and IMU-supported state estimation. A 2D LiDAR is commonly used to populate a local obstacle costmap. A depth camera can also contribute obstacle observations when its optical frame is correctly transformed to base_link.

Raph Rover can use the same ROS 2 and Nav2 architecture, but it uses Ackermann steering, which DWB does not model (it cannot enforce a minimum turning radius); an Ackermann-aware controller such as Regulated Pure Pursuit or MPPI is usually preferred. Its larger payload capability also changes the integration requirements. A heavier payload can alter stopping distance, acceleration, centre of mass, wheel slip, and effective footprint. DWA limits must therefore be tuned again after adding payloads such as LiDAR units, GNSS/RTK receivers, sensor masts, onboard computers, or inspection equipment.

Limitations and integration considerations

DWA depends on the quality of localisation, obstacle data, and motion constraints. It cannot compensate for an incorrect footprint, missing TF transforms, delayed odometry, or an incomplete costmap. A robot may appear to choose unsafe commands if obstacles are outside sensor coverage or if braking capability is configured unrealistically.

For outdoor UGV deployments, local obstacle avoidance should be combined with reliable state estimation. GNSS/RTK can support global positioning in open terrain, while wheel encoders and an IMU provide higher-rate local motion estimates. LiDAR-based SLAM or visual-inertial methods may be needed where GNSS is unavailable or insufficiently accurate.

Dynamic Window Approach (DWA)