Hitesh,

Planning normally fails for one of two reasons:

1) There is an obstacle, or a perceived obstacle, that causes planning to fail. Look at the move_base_node/global_costmap/obstacles and move_base_node/global_costmap/inflated_obstacles topics in rviz to help debug this. Do you see any obstacles show up at all? Do you see the path blocked by the inflated obstacles? Also, visualize the goal that you're sending to move_base... check out the move_base_node/current_goal topic. You can find more information on using rviz with the navigation stack here: http://www.ros.org/wiki/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack

2) There is unknown space that prevents planning from succeeding. Look at the move_base_node/global_costmap/unknown_space topic in rviz. Do you see unknown space blocking the robot's path?

Also, a couple of suggestions from looking at your configuration:

1) You should probably set "raytrace_range" to be greater than "obstacle_range," otherwise you may have obstacles that do not clear out of the costmap as you'd expect.

2) If you're going to use a global_costmap that works in the odom frame, you'll probably want to set the "rolling_window" parameter to true. Otherwise, the robot will reach the edge of the map and not be able to continue.

Hope this helps,

Eitan

On Sat, May 15, 2010 at 5:35 AM, hitesh dhiman <hitesh.dhiman.1988@gmail.com> wrote:
Hi all,
I've been trying to troubleshoot the robot and running navigation stack on it. Earlier atleast the path was being planed and published, but we decided to migrate to a different laptop with a graphics card.
Now, our files are  the same, the tf's are also same, I've attached the file. ROS installation on the new laptop was done through svn, and that's the only change.
The odometry is transformed as follows:
odom_broadcaster.sendTransform((odom.pose.pose.position.x, odom.pose.pose.position.y , odom.pose.pose.position.z),tf.transformations.quaternion_from_euler(0,0,float(odo_returned[2]*0.001534)),rospy.Time.now(),"base_link","odom")

odo_returned[2] here is an element of a python list, and contains the odometry data with yaw values, that have a conversion factor of .001534.

The laser is being transformed as follows:
broadcaster.sendTransform(tf::StampedTransform(tf::Transform(tf::Quaternion(0, 0, 0, 1), tf::Vector3(0.0, 0.0, 0.2)),ros::Time::now(),"/base_link", "/laser"));

The values for move_base parameters are also shown below:
base_local_planner_params.yaml:
TrajectoryPlannerROS:
  transform_tolerance: 0.3
  sim_time: 1.7
  sim_granularity: 0.05
# dwa: true
  vx_samples: 3
  vtheta_samples: 20
  max_vel_x: 1
  min_vel_x: 0.2
  max_rotational_vel: 1.0
  min_in_place_rotational_vel: 0.4
  xy_goal_tolerance: 0.2
  yaw_goal_tolerance: 0.05
  goal_distance_bias: 0.8
  path_distance_bias: 0.6
  occdist_scale: 0.5
# occdist_scale: 0.05
  heading_lookahead: 0.325
  oscillation_reset_dist: 0.05
  acc_limit_th: 3.2
  acc_limit_x: 2.5
  acc_limit_y: 2.5
  holonomic_robot: false

costmap_common_params.yaml:
obstacle_range: 2.5
raytrace_range: 1.0
footprint: [[-0.2, -0.2], [0.2, -0.2], [0.2, 0.2], [-0.2, 0.2]]
#robot_radius: 0.4
inflation_radius: 0.2

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: /scan , marking: true, clearing: true}

global_costmap_params.yaml:
global_costmap:
  global_frame: /odom
  robot_base_frame: /base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false

local_costmap_params.yaml:
local_costmap:
  global_frame: /odom
  robot_base_frame: /base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05

I'm using simple_navigation_goals, and giving a goal of x=2 m and w = 1 in /odom frame.

On passing the goal, the robot starts rotating about the centre, and gives the following in the status:
Failed to find a valid plan. Even after executing recovery behaviors.
No messages for any global or local plan are being published. We also tried to start with running the robot straight, and then giving it a goal to see if anything works. But the velocity commands were still being pulished as (x =0, theta = 57), which means it still wants to rotate.
The action server reports that the The base failed to move forward 2 meter for some reason.

The test is being done in a corridor, approx 8-10 feet wide with no obstacles, so there is no reason why the plan should fail.

Any help or hints would be greatly appreciated. I've out all the possible problems i thought could exist, but no luck so far.
--
Regards,
Hitesh Dhiman
Electrical Engineering
National University of Singapore

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users