Niccer's profile - activity

Hi,

does anyone still use the arm_kinematics package in hydro? Looks like some updates are needed, since the message location and types changed a little.

Thanks to moveit, there is no real need any more for this package, but it would be nice to run old code in hydro.

Cheers!

Maybe it helps to dump all the frames that are in your tf instance? There is the getFrames() method - not sure if it prints the timestamps though.

Well, the code requests transformPose with time t_b of the latest base pose. If you publish at different places of your node, time t_g of global would e.g. have a slightly earlier timestamp - and tf must fail. Same thing if one of the other tf-messages has not been received yet. Unless you enable extrapolation, this is how tf(2) should behave. In amcl - which would typically publish the map->odom or world->local transform - they timestamp the transform with 0.2s in the future. Maybe that's also a solution for you?

What's your transformation chain, and what node publishes the individual frames?

Have you actually verified it fails really at tf.lookupTransform? Because in this line, you are not requesting a lookup 40ms before now(), as the error message says. What is your tf chain from local to global?

Similar thread: http://answers.ros.org/question/106996/hydro-move_basetf2-extrapolation-error-into-the-future-errror/ . I posted my "solution" there. Could you check your transformation timings?

Hi,

there are many questions here about that error in different scenarios. I am using slam_karto and groovy, but the code in goal_functions.cpp has not changed much.

I also found that the exception is thrown in navigation/base_local_planner/src/goal_functions.cpp:transformGlobalPlan() - yet for me, tf.lookupTransform (line 110) is ok, but tf.transformPose (line 116) fails. My tf-tree is /map -> /odom -> /base_footprint. /odom is published with an average delay of 90ms, while /base_footprint has a delay of 35ms. Debugging the code shows that tf.transformPose is requested to transform the pose to /map at now()-35ms. That fails, since the /odom transformation is older, and tf apparently does not extrapolate so far into the future.

My solution was to change the tf.transformPose call, such that it takes the most recent time: tf.transformPose(plan_pose.header.frame_id, ros::Time(0), global_pose, global_pose.frame_id_, robot_pose);

While this works, I wonder how things should behave in the original code. Are delays between the different frames not accepted? Or does the extrapolation usually work, for whatever reason? Maybe someone who runs move_base successfully can comment on that.

@robotiqsguy: Could you verify where exactly the exception is triggered in your case? Also, what delays do you see for your frames, if you run rosrun tf tf_monitor?

Best Regards!