how to remove forward bias in move_base

Question

I have a robot that senses and moves in reverse just as well as in forward. However, move_base trajectories are highly biased toward turning the robot around and moving forward. I tried setting prefer_forward_cost_function to 0.0 and also tied turning on and off DWA, but these have no apparent effect.

Is there some way to remove the forward bias in move_base?

Revised:

I tried the excellent suggestion of making min_vel_x negative and initially thought it worked, but in fact, it does not.

The output from move_base still does not generate negative x velocities. When given a goal to the rear, with a blank map, it turns 180 degrees and goes there. If I set max_vel_x = 0.0, then it just turns in place. Here is base_local_planner_params.yaml

Second revise: I swapped from TrajectoryPlanner to DWAPlanner (param file and move_base output shown below) but it does not seem to make any difference.

Third revise: I was entering DWAPlanner parameters, but did not select DWAPlanner as the local planner, so it was defaulting to TrajectoryPlanner. Adding this line to the parameter list fixed that and the bot now goes backwards.

base_local_planner: "DWAPlannerROS"

Many thanks to David Lu for his help with this.

controller_frequency: 4.0
recovery_behavior_enabled: true
clearing_rotation_allowed: false

DWAPlannerROS:
   max_vel_x: 0.3
   min_vel_x: -0.5
   max_rotational_vel: 0.5
   min_vel_theta: -0.5
   min_in_place_vel_theta: 0.2
   escape_vel: -0.1
   acc_lim_x: 2.3
   acc_lim_y: 2.3
   acc_lim_theta: 1.5

   holonomic_robot: false
   yaw_goal_tolerance: 0.1 # about 6 degrees
   xy_goal_tolerance: 0.2  # 20 cm
   latch_xy_goal_tolerance: false
   pdist_scale: 0.8
   gdist_scale: 0.6
   meter_scoring: true
   prefer_forward_cost_function: 0.0

   heading_lookahead: 1.0
   heading_scoring: false
   heading_scoring_timestep: 0.8
   occdist_scale: 0.1
   oscillation_reset_dist: 0.05
   publish_cost_grid_pc: false
   prune_plan: true

   sim_time: 1.5
   sim_granularity: 0.025
   angular_sim_granularity: 0.025
   vx_samples: 8
   vtheta_samples: 20
   dwa: true
   simple_attractor: false

Just in case it is useful, here is the output from move_base startup. Note that it is using rangefinders as sources and I thought maybe the rear sensors were creating an obstacle, but the behavior is unchanged with the hokuyo sensors removed.

SUMMARY
========

PARAMETERS
 * /map_server/frame_id: map
 * /move_base/DWAPlannerROS/acc_lim_theta: 1.5
 * /move_base/DWAPlannerROS/acc_lim_x: 2.3
 * /move_base/DWAPlannerROS/acc_lim_y: 2.3
 * /move_base/DWAPlannerROS/angular_sim_granularity: 0.025
 * /move_base/DWAPlannerROS/dwa: True
 * /move_base/DWAPlannerROS/escape_vel: -0.1
 * /move_base/DWAPlannerROS/gdist_scale: 0.6
 * /move_base/DWAPlannerROS/heading_lookahead: 1.0
 * /move_base/DWAPlannerROS/heading_scoring: False
 * /move_base/DWAPlannerROS/heading_scoring_timestep: 0.8
 * /move_base/DWAPlannerROS/holonomic_robot: False
 * /move_base/DWAPlannerROS/latch_xy_goal_tolerance: False
 * /move_base/DWAPlannerROS/max_rotational_vel: 0.5
 * /move_base/DWAPlannerROS/max_vel_x: 0.3
 * /move_base/DWAPlannerROS/meter_scoring: True
 * /move_base/DWAPlannerROS/min_in_place_vel_theta: 0.2
 * /move_base/DWAPlannerROS/min_vel_theta: -0.5
 * /move_base/DWAPlannerROS/min_vel_x: -0.5
 * /move_base/DWAPlannerROS/occdist_scale: 0.1
 * /move_base/DWAPlannerROS/oscillation_reset_dist: 0.05
 * /move_base/DWAPlannerROS/pdist_scale: 0.8
 * /move_base/DWAPlannerROS/prefer_forward_cost_function: 0.0
 * /move_base/DWAPlannerROS/prune_plan: True
 * /move_base/DWAPlannerROS/publish_cost_grid_pc: False
 * /move_base/DWAPlannerROS/sim_granularity: 0.025
 * /move_base/DWAPlannerROS/sim_time: 1.5
 * /move_base/DWAPlannerROS/simple_attractor: False
 * /move_base/DWAPlannerROS/vtheta_samples: 20
 * /move_base/DWAPlannerROS/vx_samples: 8
 * /move_base/DWAPlannerROS/xy_goal_tolerance: 0.2
 * /move_base/DWAPlannerROS/yaw_goal_tolerance: 0.1
 * /move_base/clearing_rotation_allowed: False
 * /move_base/controller_frequency: 4.0
 * /move_base/global_costmap/footprint: [[0.64, 0.63], [0...
 * /move_base/global_costmap/front_hokuyo_scan/clearing: True
 * /move_base/global_costmap/front_hokuyo_scan/data_type: LaserScan
 * /move_base/global_costmap/front_hokuyo_scan/marking: True
 * /move_base/global_costmap/front_hokuyo_scan/sensor_frame: hokuyo_front_link
 * /move_base/global_costmap/front_hokuyo_scan/topic: /scan
 * /move_base/global_costmap/global_frame: /map
 * /move_base/global_costmap/inflation_radius: 0.5
 * /move_base/global_costmap/max_obstacle_height: 0.6
 * /move_base/global_costmap/min_obstacle_height: 0.0
 * /move_base/global_costmap/observation_sources: front_hokuyo_scan...
 * /move_base/global_costmap/obstacle_range: 2.5
 * /move_base/global_costmap/publish_frequency: 0.0
 * /move_base/global_costmap/raytrace_range: 3.0
 * /move_base/global_costmap/rear_hokuyo_scan/clearing: True
 * /move_base/global_costmap/rear_hokuyo_scan/data_type: LaserScan
 * /move_base/global_costmap/rear_hokuyo_scan/marking: True
 * /move_base/global_costmap/rear_hokuyo_scan/sensor_frame: hokuyo_rear_link
 * /move_base/global_costmap/rear_hokuyo_scan/topic: /rear_scan
 * /move_base/global_costmap/resolution: 0.0943
 * /move_base/global_costmap/robot_base_frame: /base_footprint
 * /move_base/global_costmap/rolling_window: False
 * /move_base/global_costmap/static_map: True
 * /move_base/global_costmap/transform_tolerance: 2.0
 * /move_base/global_costmap/update_frequency: 1.0
 * /move_base/local_costmap/footprint: [[0.64, 0.63], [0...
 * /move_base/local_costmap/front_hokuyo_scan/clearing: True
 * /move_base/local_costmap/front_hokuyo_scan/data_type: LaserScan
 * /move_base/local_costmap/front_hokuyo_scan/marking: True
 * /move_base/local_costmap/front_hokuyo_scan/sensor_frame: hokuyo_front_link
 * /move_base/local_costmap/front_hokuyo_scan/topic: /scan
 * /move_base/local_costmap/global_frame: /odom
 * /move_base/local_costmap/height: 4.0
 * /move_base/local_costmap/inflation_radius: 0.5
 * /move_base/local_costmap/max_obstacle_height: 0.6
 * /move_base/local_costmap/min_obstacle_height: 0.0
 * /move_base/local_costmap/observation_sources: front_hokuyo_scan...
 * /move_base/local_costmap/obstacle_range: 2.5
 * /move_base/local_costmap/publish_frequency: 1.0
 * /move_base/local_costmap/raytrace_range: 3.0
 * /move_base/local_costmap/rear_hokuyo_scan/clearing: True
 * /move_base/local_costmap/rear_hokuyo_scan/data_type: LaserScan
 * /move_base/local_costmap/rear_hokuyo_scan/marking: True
 * /move_base/local_costmap/rear_hokuyo_scan/sensor_frame: hokuyo_rear_link
 * /move_base/local_costmap/rear_hokuyo_scan/topic: /rear_scan
 * /move_base/local_costmap/resolution: 0.0943
 * /move_base/local_costmap/robot_base_frame: /base_footprint
 * /move_base/local_costmap/rolling_window: True
 * /move_base/local_costmap/static_map: False
 * /move_base/local_costmap/transform_tolerance: 2.0
 * /move_base/local_costmap/update_frequency: 3.0
 * /move_base/local_costmap/width: 4.0
 * /move_base/recovery_behavior_enabled: True
 * /rob_st_pub/publish_frequency: 20.0
 * /robot_description: <?xml version="1....
 * /rosdistro: indigo
 * /rosversion: 1.11.10

---

Originally posted by dan on ROS Answers with karma: 875 on 2015-04-18

Post score: 2

Answer 1

You need to set min_vel_x to be negative (not 0)

---

Originally posted by David Lu with karma: 10932 on 2015-04-19

This answer was ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by dan on 2015-04-19:
that was it-- thanks!! Do you know if prefer_forward_cost_function has any effect and, if so, what are the ranges?

Comment by David Lu on 2015-04-19:
prefer_forward_cost makes it so that even if backwards trajectories are possible it prefers to go forwards. The value is just a weight on the weighted sum that calculates the best overall score, so the real range is 0-infinity (as helpful as that is)

Comment by dan on 2015-04-20:
turns out I spoke too soon. move_base is still not outputting negative x velocities-- see the details in the revised question.

Comment by David Lu on 2015-04-21:
I assumed from your initial question you were using dwa_local_planner. I don't know if TrajectoryPlannerROS can go backwards.

Comment by dan on 2015-04-21:
I tried with dwa_local_planner with no difference. See the revised question for the param file and the move_base output with dwa_planner Hmm, I am wondering if I set the dwa parameters but have not selected dwa as the planner. Is there a parameter to select the planner?

Comment by dan on 2015-04-21:
ah, there is indeed such a parameter and when I added base_local_planner: "DWAPlannerROS" to the param file, the bot now goes backwards. However, the trajectory is somewhat ragged, as if it is being dragged along in fits and spurts. That may be out of scope for this question. I'll look into it.

Comment by dan on 2015-04-21:
one last thought: if you have to have min_vel_x negative to get backwards planning motion, then do you use min_trans_vel to avoid getting velocity commands that are too small for the robot to move? That was the original point of min_vel_x I think.

Comment by hc on 2018-10-19:
Indeed how do you make sure that the min velocity (forward or backward) is enough to overcome friction?

Comment by RicoJ on 2020-09-07:
Overcoming friction is more related to the lower level motor controls of your application. If you're using Gazebo, there are ways to set joint controllers to achieve that. See here