Ask Your Question
2

move_base and extrapolation errors into the future

asked 2014-05-14 13:42:07 -0600

updated 2014-05-22 14:42:41 -0600

I'm trying to launch the navigation stack in a PatrolBot from an external computer. From the internal computer, I have RosAria reporting odometry, sicktoolbox_wrapper reporting laserScans (using laser_filters::LaserScanFootprintFilter to remove laser points inside the robot's body), and a TF publisher for the laser to the robots frame (base_link). I had some problems with extrapolation errors, which were remedied by modifying the rate of the laser TF publications, as well as running chrony in both machines with having the internal computer syncing with the chronyd in the external computer.

I've been able to create a map with the instructions published in the MappingFromLoggedData tutorial.

I've created the move_base launch file, with the appropriate yaml files and map files, as explained in the "Creating a Launch File for the Navigation Stack" section of the RobotSetup tutorial.

Running rosrun tf tf_monitor shows apropriate transform delays (including a negative one from AMCL).

I run the navigation stack, and with rviz succesfully propose an initial 2D estimate. If at this point, I manually move the robot (via joystick), its position is refreshed adequately (with some minimal error) in rviz, meaning that AMCL is doing its job.

Everything is well up until this point.

However, when I propose a Navigation goal through rviz, the following error appears in the terminal where I run the move_base launch file:

Extrapolation Error: Lookup would require extrapolation into the future. Requested time ... but the latest data is at time ..., when looking up transform from frame [/odom] to frame [/map]. Global Frame: odom Plan Frame size ...: map Could not transform the global plan to the frame of the controller

I've narrowed down the error to the base_local_planner when trying to execute the transformGlobalPlan function in goal_functions.cpp

After a couple of days of searching for a solution it appears as though a waitForTransform would be required in this function right before doing the lookupTransform. However, before I go in and start modifying the source code and compiling the whole of move_base to do this, I was wondering if anybody has encountered this issue and can recommend me a workaround.

I'd attach my yaml and launch files, to see if I've missed something, but I don't have the karma points for it.

I can copy and paste them in the comments below if need be.

Thanks.

EDIT 2014-05-22:

I have downloaded the move_base git, and compiled the base_local_planner agent (which requires to gitclone cmake_modules from github as well, by the way).

I've added the following in line 110 in goal_functions.cpp (right before the lookuptransform call) and compiled:

tf.waitForTransform(global_frame, ros::Time::now(), plan_pose.header.frame_id, plan_pose.header.stamp, plan_pose.header.frame_id, ros::Duration(0.5));

The error of future extrapolation has disappeared, however the base is still not moving.

The following warning is now repeatedly shown:

Control loop missed its desired rate of 20.0000Hz... the loop actually took XXXXX seconds

XXXXX is a value between 0.11 and 0 ... (more)

edit retag flag offensive close merge delete

Comments

Hey, I have the same problem. What did you finally do to solve it?

peterwe gravatar imagepeterwe ( 2017-04-19 06:48:38 -0600 )edit

It's been a while. The version of move_base in Kinetic (and Indigo I think) have the correction in goal_functions.cpp. As for it not moving, a student that knew his way around move_base fiddled with the amcl and the costmaps configuration, but I don't remember what did he do exactly. I apologize.

balkce gravatar imagebalkce ( 2017-04-20 13:38:24 -0600 )edit

2 Answers

Sort by » oldest newest most voted
4

answered 2014-05-14 20:35:49 -0600

This bug appears to be around since quite some time, I opened a ticket about it: navigation issue 166. You´ll also find other people´s similar experiences linked there. If you modify the code and make it work, you can contribute your fix at github (or describe it at least).

edit flag offensive delete link more

Comments

Thanks for the opened ticket. So the next step is to amend the code in goal_functions.cpp I've downloaded the move_base source code from github and have confirmed that the absence of waitForTransform. Would I be able to compile only base_local_planner or would I need to recompile all of move_base?

balkce gravatar imagebalkce ( 2014-05-15 05:03:49 -0600 )edit
1

answered 2014-05-14 21:02:22 -0600

zsbhaha gravatar image

updated 2014-05-14 22:25:58 -0600

I have same problem with python scripts . when I instanced a TransformListener object , and immediately called the waitForTransform function , it would throw a Extrapolation .

see my question ,please punch here

the code like this:

listener = tf.TransformListener()
listener.waitForTransform("/goal_in_picture","/map",rospy.Time.now(),rospy.Duration(5.0))

but After I referred to @Pi Robot scripts , I add a delay line to give tf some time to fill its buffer,like this:

listener = tf.TransformListener()
# Give tf some time to fill its buffer
rospy.sleep(2)
listener.waitForTransform("/goal_in_picture","/map",rospy.Time.now(),rospy.Duration(5.0))

and amazing happened . I hope it will help .

edit flag offensive delete link more

Comments

1

This is only remotely related to the issue at hand. Note that you should generally instantiate your Listener only once at node startup (as opposed to creating a new object before looking up transforms).

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2014-05-15 01:09:27 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2014-05-14 13:42:07 -0600

Seen: 3,780 times

Last updated: May 22 '14