Running the base_local_planner with dwa=true isn't deprecated, its a valid configuration for the planner and should work. However, if you're considering using DWA, its probably worth checking out the dwa_local_planner package. The dwa_local_planner is a cleaner implementation of the algorithm (from a code structure standpoint) that includes other goodies like optionally scaling the robot's footprint as it drives and supporting dynamic_reconfigure.
As explained on the wiki, the difference between DWA and TR lies in the velocity space they explore while rolling out trajectories. DWA has a more restricted space since it only considers velocities that can be reached over one simulation step, corresponding to the controller_frequency
parameter which is used to calculate the sim_period
variable you've referred to. TR, on the other hand, explores velocities achievable over the entire trajectory simulation specified by the sim_time
parameter. So, if controller_frequency
is set to 10Hz and sim_time
is set to 1.5 seconds, DWA will explore the velocities reachable (given the acceleration limits of the robot) in the next 0.1 seconds, while TR will explore velocities reachable in 1.5 seconds.
The original DWA paper, I believe, scores trajectories based on the robot's heading relative to a goal point, distance to obstacles, and velocity. The WG implementation scores based on distance to a goal point, distance from a planned path, and distance to obstacles. There are a number of papers on using DWA in conjunction with global plans to avoid local minima, but I'm not positive that any of them use this exact method for scoring. I do know that the TR paper linked from the base_local_planner wiki page uses this scoring method, and that's where it comes from.
Originally posted by eitan with karma: 2743 on 2011-05-24
This answer was NOT ACCEPTED on the original site
Post score: 5
Original comments
Comment by Pablo Iñigo Blasco on 2011-05-24:
Thanks Eitan. I'm not sure yet. The velocity limits just define the velocity samples nearness. Since num_steps defines the dt if it is enough small (even for very slow velocities) v(t+1)=v(t)+a·dt <=v_sampled. Nonetheless I'll do a thorough analysis of the code and I'll do little debug to check it.
Comment by eitan on 2011-05-24:
The limits imposed on the velocities for DWA should lead to it being held constant during the simulation which, I believe, will lead to a circular trajectory. The computeNewVelocity method will return vx_samp every time because it should be achieved instantaneously.
Comment by Pablo Iñigo Blasco on 2011-05-24:
I say that they are non-circular trajectories since sampled velocities are also integrated (TrajectoryPlanner::computeNewVelocity) hence they are not constant during the simulation and then the trajectory is not circular. If we look at the dwa_local_planner we can see velocities are not integrated.
Comment by Pablo Iñigo Blasco on 2011-05-24:
Thanks Eitan. I understand that DWA uses the controller_period to set the dynamic window limits. However I interpret from the TrajectoryPlanner::generateTrajectory method that DWA is also simulated in a non-circular trajectory with "num_steps=sim_time/sim_granularity+0.5" times. What didn't I catch?