Charles's profile - activity

Brian Gerkey:

Thank you for answering my questions.

I did the sanity check as you said, I think the odometry is reasonable. I put the video here: http://youtu.be/nNgkgiUnA3M

I also did the sanity check as the Navigation Tuning Guide said. The video is here:http://youtu.be/cAbMLa1msEU

I found that the AMCL worked better with my robot when I drove my robot with a high speed than a low speed. I made two video for a comparison. The slow speed one.The high speed one.

I got two questions after I read the navigation tutorials again and again:

1.The AMCL node provide a service named "global_localization". Is it necessary to call this service before testing the AMCL node?

2.How can I determine to set the "odom_model_type" to "diff" or "omni"? And the "laser_model_type".

Below are some quick instructions fro clock synchronization. chrony has been found to be the best ntp client over lossy wireless.

1. manually sync NTP

   sudo ntpdate ntp.ubuntu.com

2. Install Chrony

   sudo apt-get install chrony

Have you tried joysticking the robot around with AMCL running to see if you can get reasonable results independent of navigation? Have you been careful to set an initialpose that is close to the actual position of the robot in the map? Have you verified your odometry and laser scans are reasonable?

The navigation tuning guide gives some tips on how you might check your odometry is working.

The navigation stack was running quite well in navigation stage with my navigation config file. From my understanding, the robot will try to match it's real position gradually, as long as it move around. But, in my physical robot, the robot don't try to match it's real position, when i give it a goal. The tf tree is OK. What is the problem maybe?

In addition, I can use my robot to built a good map. Does that means my odometry data is sensible ?

The navigation stack will not plan a path to a goal given in an inflated obstacle because a cell marked as such guarantees that any concave robot footprint would be in collision if the center-point of that footprint were placed at that cell. Basically, if the navigation stack were to attempt to achieve such a goal, it would hit something.

If you want the navigation stack to get as close to this goal as possible, you might want to check out the "default_tolerance" parameter that can be set on navfn documented here: http://www.ros.org/wiki/navfn#Parameters. Setting that parameter should allow you to specify goals inside of inflated obstacles where the robot will try to get close.

perhaps carrot_planner can solve this problem.

In my rviz, both of the fixed frame and target frame are '/map'. Following is my common costmap configuration:

map_type: costmap
transform_tolerance: 0.2
obstacle_range: 2.5
raytrace_range: 3.0
inflation_radius: 0.55
footprint: [[0.13, 0.35],
            [0.25, 0.15],
            [0.25, -0.15],
            [0.13, -0.35],
            [-0.13, -0.35],
            [-0.25, -0.15],
            [-0.25, 0.15],
            [-0.13, 0.35]]

observation_sources: base_scan

base_scan: {data_type: LaserScan,
            topic: /base_scan,
            expected_update_rate: 0.4,
            observation_persistence: 0.0,
            marking: true,
            clearing: true,
            min_obstacle_height: 0.08,
            max_obstacle_height: 2.0}

global_costmap:

global_costmap:
    publish_voxel_map: true
    global_frame: /map
    robot_base_frame: base_link
    update_frequency: 5.0
    publish_frequency: 0.0
    static_map: true
    rolling_window: false

local_costmap:

 
local_costmap:
    publish_voxel_map: true
    global_frame: odom
    robot_base_frame: base_link
    update_frequency: 5.0
    publish_frequency: 2.0
    static_map: false
    rolling_window: true
    width: 10.0
    height: 10.0
    resolution: 0.025
    origin_x: 0.0
    origin_y: 0.0

Yes, I have tried it by using navigation stage. When I set a goal in the inflated obstacles, the navigation stack didn't give a plan, and the robot began to rotate. After that, the stack threw an error.

[ERROR] [1303565646.145455982, 30.900000000]: Aborting because a valid plan could
 not be found. Even after executing all recovery behaviors

From my understanding, if we set a navigation goal in inflated obstacles, the navigation stack won't give a path plan. So, how can I configure the stack to let the it give a path plan, which navigate the robot to a position near the goal?

Hi everyone! I got a problem when I run the navigation stack with rviz. When setting the initial pose with rivz I got a warning :

[ WARN] [1302846487.971832409]: Failed to transform initial pose in time (You requested a transform that is 0.054 miliseconds in the past, 
but the most recent transform in the tf buffer is 21.216 miliseconds old.
 When trying to transform between /map and /base_link.)

[ INFO] [1302846487.971997932]: Setting pose (1302846487.971978): 1.194 6.348 -1.571

Here is the results of the run tf tf_monitor command:

RESULTS: for all Frames
 
Frames:
Frame: /base_link published by /we_base_odom Average Delay: 0.00026288 Max Delay: 0.000908351
Frame: /laser_link published by /base_laser_tf Average Delay: -0.024749 Max Delay: 0
Frame: /odom published by /amcl Average Delay: -0.175799 Max Delay: 0
 
All Broadcasters:
Node: /amcl 13.3557 Hz, Average Delay: -0.175799 Max Delay: 0
Node: /base_laser_tf 39.866 Hz, Average Delay: -0.024749 Max Delay: 0
Node: /we_base_odom 49.9598 Hz, Average Delay: 0.00026288 Max Delay: 0.000908351

header: 
  seq: 2
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: /map
pose: 
  pose: 
    position: 
      x: 1.19398033619
      y: 6.34785318375
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -0.707106781187
      w: 0.707106781187
  covariance: [0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.06853891945200942, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
  

Here is the frame.pdf:

How can I fix this problem? Thank you !