Hi,
I’m having trouble running the path planning setup in my Rosject.
I have successfully done sections I & II. With my additions for part III generally a global plan is created, occasionally a local plan shows (rviz) and intermittently the robot will start following the plan. Most of the time however variations on the following output is produced.
INFO] [1647620863.973286977, 171.526000000]: Got new plan
[ERROR] [1647620863.973470418, 171.526000000]: Extrapolation Error: Lookup would require extrapolation -0.058000000s into the future. Requested time 171.500000000 but the latest data is at time 171.442000000, when looking up transform from frame [odom] to frame [map]
[ERROR] [1647620863.973536129, 171.526000000]: Global Frame: odom Plan Frame size 8: map
[ WARN] [1647620863.973585121, 171.526000000]: Could not transform the global plan to the frame of the controller
[ERROR] [1647620863.973638206, 171.526000000]: Could not get local plan
^C[ INFO] [1647620864.180819325, 171.721000000]: Got new plan
[ERROR] [1647620864.180992120, 171.721000000]: Extrapolation Error: Lookup would require extrapolation -0.059000000s into the future. Requested time 171.700000000 but the latest data is at time 171.641000000, when looking up transform from frame [odom] to frame [map]
[ERROR] [1647620864.181047301, 171.721000000]: Global Frame: odom Plan Frame size 8: map
[ WARN] [1647620864.181120250, 171.721000000]: Could not transform the global plan to the frame of the controller
[ERROR] [1647620864.181166328, 171.721000000]: Could not get local plan
To experiment I forked the ROS Navigation Real Robot Project provided by albertoezquerro which works fine. After some attempt to spot the difference without success I deleted my Rosject, created a clean new version and copied all the packages (my_turtlebot_mapping, localization, path_planning) from the working Rosject to mine.
The result of running this version, exactly the same errors as I was getting originally…
What am I missing?
It seems that your navigation node is asking for a TF that is not available yet. Do you have any other errors or output that could be helpful?
Can you share your configuration files from your package?
Pay special attention to the global_frame and the robot_base_frame parameters
Hi,
If this is the easiest way to share the config can perhaps be found here Rosject link
I have looked at the transform tree of the 2 setups described above and attached the results.
Output from my rosject
Output from example rosject
Transforms are similar, though I do note the rate differences between the two for the map & odom. Is there something in this?
Note: I tried changing the local_costmap global_frame from ‘odom’ to ‘map’ to match the global_costmap. This ‘resolved’ the error above, but the performance was not good in terms of calculation time or final positioning and I don’t feel that this is an acceptable solution.
Thanks for your input roalgoal.
I think I have found a/the solution by modifying the update rates of the turtlebot3_burger_controller and laser ‘scan’ in \turtlebot3\turtlebot3_description\urdf\turtlebot3_burger.gazebo.xacro
turtlebot3_burger_controller → odom / base_footprint transform
laser scan indirectly → map / odom transform
If this is the case there seems to be an issue with the project the ROS Navigation Real Robot Project is based on…
Hi Steven,
I will take a look at this, because the file that you modified comes from the official turtlebot github, so that shouldn’t be the solution.
What do you mean by “laser scan indirectly”? the map-odom transform is published by the amcl I believe, so the scan doesn’t have anything to do with it.
I’ll get back to you later today
Hi,
I was looking for a way to increase the publishing rate for the map-odom transform and couldn’t find any configuration options. I found this post https://answers.ros.org/question/192010/amcl-publish-frequency-map-odom/ linking the amcl published transform rate to the laser scan rate.
Checking rostopic hz /scan showed a rate of 5hz matching the odom/map rate reported.
Checking the scan rate in \turtlebot3_burger.gazebo.xacro showed a value of 5 in my version and a value of 1800 in the working example.
Changing the scan rate value to 1800 in my .xacro increased the map/odom rate from amcl to a value equivalent to the working example (i.e. around 300+)
I have been having the same issue here. I did find that increasing the laser update rate made at least this issue go away. But still: is this happening to us two alone?
I agree with @roalgoal : changing the predefined laser rate cannot be a solution. Also because, the laser has physical limitations that prevents exceeding 5-10 Hz.
I played around with the amcl params, and it turns out that transform_tolerance from 0.1 to 0.5 did the trick.
1 Like
