Rotate recoveries thwarted

[stonier]

By the velocity smoother?

 WARN] [1402361798.444854073]: Clearing costmap to unstuck robot.
[ WARN] [1402361798.795447476]: Velocity Smoother : input got inactive leaving us a non-zero target velocity (0, -0.103867), zeroing...[navigation_velocity_smoother]

Note - the navigation is pumping out small rotational velocities. Either

• the velocity smoother is doing something odd (above) OR
• the kobuki just can't do rotational velocities that small.

End result is, when the robot is faced with a wall of obstacles in front and the goal is behind and no local path planning possible, it should start rotating till it can generate local paths. It doesn't.

[stonier]

Some discussion of this issue at https://github.com/yujinrobot/yujin_ocs/issues/33.

Zero'ing is certainly probably one cause of problems here if the navigation engine modifies it's command rate, however a more likely problem is the rotate in place velocities aren't big enough. Waiterbot can't really do anything less than 0.2 rad/s reliably.

[stonier]

Note also - dwa planner doesn't seem to have a min_in_place_vel_theta parameter like the TrajectoryPlanner does.

[stonier]

This particular line is the magic for dwa.

  if ((limits_->min_trans_vel >= 0 && vmag + eps < limits_->min_trans_vel) &&
      (limits_->min_rot_vel >= 0 && fabs(sample_target_vel[2]) + eps < limits_->min_rot_vel)) {
    return false;
  }

A min_trans_vel of zero automatically passes this check and allows trajectories of negligible rotational velocity.

[jihoonl]

I found why waiterbot was not rotate to clear the costmap at all. I have missed @corot's comment on move_base param configuration. How stupid I am.

# Waiterbot recovery behaviors; we avoid spinning, but we need a fall-back replanning

on Here