ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Local planner behaves unordinary

asked 2019-01-22 06:22:47 -0500

stevemartin gravatar image

Hello,

I am using base_local_planner (TrajectoryPlannerROS with DWA enabled) and it works in general, it sends the commands to cmd_vel and my robot interprets them quite good using this simple inverse kinematics formula (I am cancelling negative velocities as my robot cannot handle them well):

v_right = (cmd_angular_z*self.ROBOT_BASE_LENGTH)/2.0 + cmd_linear_x
v_left = cmd_linear_x*2.0 - v_right

if v_right < 0:
    v_right = 0
    v_left *= 2
elif v_left < 0:
    v_left = 0
    v_right *= 2

But when I set a goal, the local planner publishes short and strange plans. Even though it does like that, sometimes my robot is able to get to the goal and stop but sometimes it collides to the objects.

Here is the video: LINK

The red line is the local planner and green line is the global planner.

Here is my TrajectroyPlannerROS params:

recovery_behavior_enabled: true clearing_rotation_allowed: true

TrajectoryPlannerROS:
  acc_lim_x: 1
  acc_lim_y: 0 # as we have a differential robot
  acc_lim_theta: 1.6
  max_vel_x: 0.6 # configure, was 0.2
  min_vel_x: 0.2 # was 0.4
  max_vel_y: 0.0  # zero for a differential drive robot
  min_vel_y: 0.0
  max_vel_theta: 1.6 # 0.35
  min_vel_theta: 3.0 #-0.35
  min_in_place_vel_theta: 3.0 #0.25
  min_rot_vel: 3.0
  escape_vel: 0.0

  holonomic_robot: false

  meter_scoring: true

  xy_goal_tolerance: 0.3 # 0.15, 0.3->about 20 cm
  yaw_goal_tolerance: 0.20 # 0.25, about 11 degrees
  latch_xy_goal_tolerance: true  #false

  sim_time: 3 # <2 values not enough time for path planning and can't go through narrow
  sim_granularity: 0.05 # How frquent should the points on trajectory be examined
  angular_sim_granularity: 0.025
  vx_samples: 20
  vy_samples: 0 # 0 for differential robots
  vtheta_samples: 5 # 20
  controller_frequency: 15

  pdist_scale: 0.8
  gdist_scale: 0.4
  occdist_scale: 0.01
  oscillation_reset_dist: 0.2
  heading_scoring: true
  heading_lookahead: 1 # how far to look ahead in meters
  heading_scoring_timestep: 0.8
  dwa: true
  publish_cost_grid_pc: false
  global_frame_id: odom
  simple_attractor: false

  reset_distance: 4

  prune_plan: true
edit retag flag offensive close merge delete

Comments

1

The behaviour is a result of preventing negative velocities. For a differential drive to turn clockwise in place, you will need positive left wheel velocity and negative right wheel velocity. The local planner is drawing an arc towards the goal but because it isn't being executed, it has to replan.

curi_ROS gravatar image curi_ROS  ( 2019-01-22 06:55:46 -0500 )edit

@curi_ROS But how can I enable negative velocities and also state that small values (both negative and positive) should be greater than 1.2? Because if I put min_vel_theta -1.2, it produces angular velocities like 0.08 and my robot does not move (too low velocity)

stevemartin gravatar image stevemartin  ( 2019-01-23 04:08:11 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-12-19 19:44:00 -0500

ed gravatar image

I ran across you question because regardless of what I put in for min_vel_theta and min_vel_trans it always gets reset to 0. This is despite what the the website says the default value is ie -1. You are correct that in order to turn clockwise your cmd_vel needs to have z a negative value. if you can not produce a negative the planner will not turn that way. I am going to try to hard code some values.

Also I see your min_vel_theta: 3.0 this should be negative or at least less than max_vel_theta: and your min_vel_x should also be negative or at least less than max_vel_x: Also note that if you have dwa: true then sim_time parameter is not used but it used the controller_frequency instead.

Now for the question of needing 1.2 or -1.2 versus .08 or -.08. I think this may not be a planner issue but a base controller issue. What I mean by that is your robot is not correctly translating a requested velocity to the correct PWM value to make the robot move. Most examples for motor control that I have seen assume that pwm values are linear. Its not. there is a minimum value needed get the robot to overcome inertia. then a usually lower minimum value to keep it moving. The problem is these values are not constant. They depend on the type of surface your robot is moving on and the state of your battery. I was experimenting with my large outdoor bot on both a indoor surfaces (smooth concrete and thin carpet) and outdoor (driveways and pathways) and on the indoor surface a value of 235 out of 124 would get the bot rolling but outdoors it would require 350 to 375 on flat and over 400 for any kind of incline.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2019-01-22 06:22:47 -0500

Seen: 512 times

Last updated: Dec 19 '19