Extrapolation error using hector_mapping + move_base

asked 2013-05-23 05:54:56 -0600

385 ●18 ●27 ●27

updated 2013-06-05 03:16:34 -0600

Hello all,

I have a problem with my robot setup which I cannot resolve, even after reading all relevant posts on here. I really would appreciate your help.

Problem Description

The system starts up not generating any errors (see https://dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/start_up_log.txt), producing an accurate map, and localization working well, too. As soon as I select a goal in rviz, move_base reproducibly throws the following errors:

[  ...]
[ERROR] [1369321339.784772926]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321339.785409391]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321339.785726634]: Could not transform the global plan to the frame of the controller
[ERROR] [1369321340.434425166]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321340.434493357]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321340.434528719]: Could not transform the global plan to the frame of the controller
[  ...]

However, if I make the following change in the local_costmap_params.yaml file:

local_costmap: global_frame: /odom

to

local_costmap: global_frame: /map

I don't get any errors and move_base generates a plan to the goal, which is also displayed in rviz. Unfortunately, the generated cmd_vel commands are very shaky, oscillate and weird navigation behaviour is the result.

My Setup

Robot: Custom robot with chain drive, i.e. non-holonomic. I have written a base_controller node for it which sends drive commands to the motors and uses the encoder information to calculate odometry and publish as tf+nav_msg (as described http:// www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom). I have also created a *.urdf file and use robot_state_publisher to publish the tf's for the model.
Sensors: Hokuyo UTM-30LX laser scanner
Nodes: max_driver (custom base_controller), hector_mapping, move_base, hokuyo_node
hector_mapping config:

[hector_config.launch] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/hector_config.launch

move_base config:

[move_base_config.launch] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/move_base_config.launch

[base_local_planner_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/base_local_planner_params.yaml

[costmap_common_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/costmap_common_params.yaml

[global_costmap_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/global_costmap_params.yaml

[local_costmap_params.yaml] https://dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/local_costmap_params.yaml

Remote nodes: The hokuyo_node and the base_controller node run on an embedded PC, which is connected via ethernet to a powerful laptop running the remaining nodes. The time of both machines is synced via crony.
SW-Version: Ubuntu 12.04 + ROS Groovy, everything up to date

Debug Info

tf tree: [link] (https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/frames.pdf)
tf_monitor output:

ros@Base:~$ rosrun tf tf_monitor
RESULTS: for all Frames

Frames:
Frame: /base_frame published by /max_driver Average Delay: -0.00377412 Max Delay: 0
Frame: /base_laser published by /robot_state_publisher Average Delay: -0.476582 Max Delay: 0
Frame: /base_laser_cap published by /robot_state_publisher Average Delay: -0.476592 Max Delay: 0
Frame: /base_laser_mount_box published by /robot_state_publisher Average Delay: -0.476591 Max Delay: 0 ...

(more)

edit retag flag offensive close merge delete

Comments

it would be great if you could provide solution to your problem, because I believe most ppl like me is struggling to get the navigation stack to work. Thank you verymuch!

Gazer ( 2013-06-18 12:12:05 -0600 )edit

I have the same problem. I looked at the code, the lookup fails in transformGlobalPlan, https://github.com/ros-planning/navigation/blob/groovy/base_local_planner/src/goal_functions.cpp Either this is too strict about the timestamps or it has a bug which only surfaces in special cases.

Achim ( 2013-08-07 03:35:35 -0600 )edit

I tried move_base with gmapping last week and got a similar issue... the robot moved for a few centimeters sometimes, but stopped with the same messages. Comparing the TFs, I get 40Hz from hector_slam and 50Hz from gmapping. So it seams the local planner is too strict with timestamps.

Achim ( 2013-08-12 01:25:41 -0600 )edit

Hello Achim, I just saw your two recent posts. What are you suggesting to fix the problem? Increase the frequency of hector_slam? I still haven´t found a solution to make it work...

Huibuh ( 2013-08-12 01:43:06 -0600 )edit

add a comment

0

answered 2013-05-23 20:15:24 -0600

Stefan Kohlbrecher

24361 ●173 ●299 ●444 https://www.energy-rob...

That's a very exhaustive report - certainly very helpful for finding the cause for your troubles. That being said, the cause of the problem isn't immediately obvious to me, as things look fine from looking over them (at least from a published tf/hector_mapping POV). I assume the /odom frame moves around in rviz as expected? First guess would've been some time sync problem between computers, but looking at your exhaustive tf debugging output, that doesn't seem to be the case. If there's no other troubles regarding the state estimation (robot pose, map etc all look fine) my guess is that the culprit is the setup of move_base (which hopefully someone else can look at).

edit flag offensive delete link

Comments

Thank you for taking a look at this Stefan. Please see my updated post above regarding your odom frame question.

Huibuh ( 2013-05-23 21:07:15 -0600 )edit

That sounds like correct odom frame behavior. What you could try is setting the fixed frame to odom and see if LIDAR data with decay time drifts slowly when the robot is moving as described here in comments: http://answers.ros.org/question/9983/why-the-slam-have-more-than-one-maps-in-rviz/

Stefan Kohlbrecher ( 2013-05-24 07:46:10 -0600 )edit

add a comment

0

answered 2013-08-13 04:51:19 -0600

David Lu

10932 ●123 ●219 ●250 http://MetroRobots.com/

I am unfamiliar with hector_mapping, but can you temporarily replace it with a static transform publisher?

edit flag offensive delete link

Comments

1

Yes, unless the origin is set to something different, in which case the bottom left corner will be at the point specified in the origin.

David Lu ( 2013-08-18 09:46:25 -0600 )edit

also, I have one more question about the costmap2d. Currently, I am using Gmapping which produces a static map. The costmap2d takes in laserScan and static map to produce a costmap. If the static map already contains information about the unknown/free/occupied, why does costmap 2d still

Gazer ( 2013-08-18 13:40:38 -0600 )edit

needs the laserScan to reproduce the same information?

Gazer ( 2013-08-18 13:42:07 -0600 )edit

Answer 1: In case you're not GMapping. Answer 2: To make the local costmap which doesn't use the static map.

David Lu ( 2013-08-18 14:41:37 -0600 )edit

@david: Good idea, I will try to replace the map->odom transform generated by hector_mapping with a startic transform publisher and report back.

Huibuh ( 2013-08-18 22:41:36 -0600 )edit

@David Lu, so basically in the nutshell, Map published from Gmapping has almost the same structure as with the 2D Map from Costmap2D? Where could I find the detail structure of the Costmap2d?

Gazer ( 2013-08-19 13:07:04 -0600 )edit

For the most part. Addendum Answer 3: If you use the voxel structure, it is not the same information.

David Lu ( 2013-08-20 04:13:28 -0600 )edit

I have the same problem as the one stated in this question. Since Huibuh doesn't seem to be reporting back as he said, I have tried replacing map->odom with a static transform publisher myself. Nothing changed! Same error!(I even tried different frequencies: last param of the static publisher)

AbuIbra ( 2013-10-10 10:03:54 -0600 )edit

see more comments

0

answered 2013-08-17 18:18:43 -0600

Gazer
136 ●26 ●35 ●42

@David Lu I have a quick quesiton about the 2d Map of the nav::occupancy_grid message type Is the (0,0) point (ie, the origin of the map) represents the lower left corner of the map?

edit flag offensive delete link

add a comment