Ask Your Question
1

Differential drive favor backwards movement teb_local_planner

asked 2016-12-15 13:55:01 -0500

andrewl gravatar image

updated 2016-12-16 21:10:01 -0500

We have a differential drive robot, and we are using the teb_local_planner with the navigation stack. Overall, it works great, but we'd like to tune the planner so that it puts equal weight on being able to drive backward and forward. For example, one scenario that we see is the robot backing out in a straight line -- ideally, we would like to have the robot only drive backwards, without any change in driving angle. However, we are seeing the robot back up initially, turn around so that it drives forward, then once it reaches its destination, turn around again, effectively giving us a 360 degree rotation.

The parameters that we have found relevant and have set: weight_kinematics_forward_drive: 0 allow_init_with_backwards_motion: true We have also changed weight_kinematics_turning_radius but have not found a good set of parameters for our desired motion.

Is this possible with the teb_local_planner?

Update:

For anybody interested, I set the global planner's orientation_mode to 2 (interpolate), and global_plan_overwrite_orientation to false, and I'm happy with my results.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
4

answered 2016-12-16 02:46:12 -0500

croesmann gravatar image

The current behavior is intended. Let me try to explain:

The local planner follows the global reference plan by tracking the farest available intermediate pose from the global plan within the local costmap (and also not exceeding max_global_plan_lookahead_dist).

Ideally, the global plan already contains reasonable and valid orientations since the global planner is aware of the complete map. Since some global planners do not even provide the orientation part for intermediate poses (NavFcn) or just support forward orientations (default in GlobalPlanner) the teb_local_planner may overwrite orientations by default (global_plan_overwrite_orientation) except the final orientation.

The following strategy is implemented currently for global_plan_overwrite_orientation==true:

Reference goal orientation:

  • if global goal (last pose of the global plan): take desired final orientation
  • if intermediate goal: the reference orientation of local goals is chosen according to the tangential vectors between pose k and pose k+1 in the global plan (always forward).

Initial Trajectory (TEB) for optimziation

The local trajectory is initialized to the current reference goal (see above, within local costmap). Note, the optimizer just finds local minima, hence the initialization is quite important.

  • if allow_init_with_backwards_motion==true and goal is located behind the robot (w.r.t. heading): initialize all orientations backwards for the subsequent optimization.
  • Else: initialize with forward orientations.

This strategy has the following implications: If the global goal is close to the robot (within the local costmap window) and is located behind it, the robot drives backwards. Otherwise, the robot always tries to drive forward.

In my opinion, if you would also initialize backwards for goals outside of the local costmap window, you would have to drive backwards along the complete global plan until you reach the global goal. Otherwise, we would need to add more assumptions and heuristics which is not appropriate for a local planner that has just a limited view of the environment. I think, this might be better decided by a global planner in general as mentioned above. Furthermore, most robots have more sensors in their front hence keeping the default strategy to drive forwards for long distances and backwards just for short ways is reasonable in my eyes. But I would be happy to discuss whether better or more intuitive strategies exist.

Note, weight_kinematics_turning_radius defines the penalty weight for satisfying min_turning_radius for carlike robots.

edit flag offensive delete link more

Comments

Great, that was really helpful! Tried picking a global goal within the local costmap window and behind the robot, and verifying that it drives backwards.

andrewl gravatar image andrewl  ( 2016-12-16 13:27:13 -0500 )edit

Sounds like our options are to: (1) explore global planners that do not have a bias towards forward motion, or (2) play around with changing the intermediate goals to depend on the robot's current orientation.

andrewl gravatar image andrewl  ( 2016-12-16 13:27:39 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2016-12-15 13:55:01 -0500

Seen: 1,544 times

Last updated: Dec 16 '16