ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

TF_OLD_DATA error when using gmapping with V-REP

asked 2018-10-06 17:31:01 -0500

GuiNar gravatar image

updated 2018-10-13 15:55:13 -0500

Hi,

I'm new to ROS (Kinetic) and dealing with a simulated robot (robotino) and SLAM. The problem is that when i try to launch gmapping by the command:

rosrun gmapping slam_gmapping scan:=/base_scan

I get the following error:

Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.53886e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 277 in /tmp/binarydeb/ros-kinetic-tf2-0.5.16/src/buffer_core.cp

I've already tried to send a empty message to the topic /reset_time but it didn't work.

I'm in a Ubuntu 16.04 and using the SICK_TIM310_fast laser in V-REP and I publish it's data using the following piece of Lua script:

laserInfo = {}
intensities = {}
data=sim.getStringSignal("measuredDataAtThisTime")
if data then
    measuredData=sim.unpackFloatTable(data)
    laserInfo['header'] = {seq=0,stamp=simROS.getTime(), frame_id="laser_lixo"}
    laserInfo['angle_min'] = -1.54
    laserInfo['angle_max'] = 1.54
    laserInfo['angle_increment'] = 0.017444444444444
    laserInfo['time_increment'] = 0.0666666667
    laserInfo['scan_time'] = 1.0
    laserInfo['range_max'] = 4.0
    laserInfo['range_min'] = 0.05
    laserInfo['ranges'] = measuredData
    for k=0,table.getn(measuredData) do table.insert(intensities, 0) end
    laserInfo['intensities'] = intensities
    simROS.publish(laserPub, laserInfo)
end

This is what i current get from the topic /tf: https://drive.google.com/file/d/1HTH1...

After i run gmapping a new /tf_static topic is created but i get nothing from it.

This is my current tf tree: https://drive.google.com/file/d/1vrI6...

Thanks for your help and if i'm missing some information that could be useful please tell me.

edit retag flag offensive close merge delete

Comments

Is use_sim_time set on the machine? If not, gmapping will try to use normal wall clock time but V-REP might be publishing simulation time (ie: starts from 0). That is not going to work.

You'll have to add more information about your setup to your question for others to be able to help you.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-08 01:17:19 -0500 )edit

Yes, it's set, if i don't do it i just get a seg fault error. I will try to add some more information but i don't exactly know what is important in this case, could you tell me? Thanks for your help.

GuiNar gravatar image GuiNar  ( 2018-10-08 08:19:05 -0500 )edit

This looks possibly related to: #q304824.

tfoote gravatar image tfoote  ( 2018-10-09 18:44:51 -0500 )edit

Could you make a minimal example of how to reproduce this error? I've seen several related reports recently but cannot reproduce it. Others have reported that the published tf timestamps are always at the same value.

tfoote gravatar image tfoote  ( 2018-10-10 18:36:59 -0500 )edit
1

I can't be sure this is related, but I recently (ie: yesterday) ran into a similar persistent TF_OLD_DATA situation which turned out to be an ABI break. I had a workspace compiled from before the recent ABI breakage (with rostime) and tried to use it on an updated system. All my Gazebo ..

gvdhoorn gravatar image gvdhoorn  ( 2018-10-11 01:30:20 -0500 )edit

.. plugins broke and I was confronted with a wall of TF_OLD_DATA errors. Nothing worked until I rebuilt my workspace.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-11 01:30:44 -0500 )edit

To reproduce this i just ran roscore, vrep and then tried to run gmapping, nothing else. I added an image of what i get from the /tf topic and an image of my current tf tree. I also rebuilt my workspace but it keeps getting the same error. Thanks again for the answers.

GuiNar gravatar image GuiNar  ( 2018-10-13 09:27:50 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
-1

answered 2018-12-08 20:15:39 -0500

ed gravatar image

updated 2018-12-15 11:28:59 -0500

The reason I posted this was to show that the issue was not related to using a simulation. The real answer was that some update and ABI break (i think to rostime) broke my system. I ran apt-get update then catin_make clean. I had to fix a bunch of issues until that completed correctly. Then I ran catkin_make and that error no longer occurred.

I am getting the same error only I am not trying to run a simulation. I have 2 launch files. minimal_baselink.launch which publishes odom and subscrbes to cmd_vel <launch> <master auto="start"/> <node pkg="bigbot" name="motorControl" type="motorControl" required="true" output="screen"> <rosparam command="load" file="$(find bigbot)/config/robot/motorcontrolbaselink.yaml"/> </node> </launch> and bigbotnavslam.launch which handles the URDF,RVIZ, move_base, gmapping, and the lidar. <launch> <include file="$(find bigbot_description)/launch/displaybigbot2.launch"/> <include file="$(find bigbot_nav)/launch/include/gmapping.launch"/> <include file="$(find bigbot_nav)/launch/include/move_base.launch"/> <include file="$(find ydlidar)/launch/lidar.launch"/>
</launch>

Note use_sim_time is set to false in both.

here are some errors from my log (not in order)

1544295978.191982261 WARN [/opt/ros/kinetic/include/tf/message_filter.h:496(MessageFilter<m>::checkFailures) [topics: /rosout, /tf, /slam_gmapping/entropy, /map, /map_metadata] MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_notifier] rosconsole logger to DEBUG for more information.

1544295978.192033769 WARN [/opt/ros/kinetic/include/tf/message_filter.h:501(MessageFilter<m>::checkFailures) [topics: /rosout, /tf, /slam_gmapping/entropy, /map, /map_metadata] MessageFilter [target=odom ]: The majority of dropped messages were due to messages growing older than the TF cache time. The last message's timestamp was: 1544295977.975927, and the last frame_id was: laser_frame

1544295843.425278847 WARN [/tmp/binarydeb/ros-kinetic-kdl-parser-1.12.11/src/kdl_parser.cpp:208(treeFromUrdfModel) [topics: /rosout] The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia. As a workaround, you can add an extra dummy link to your URDF.

1544296003.921623294 WARN [/tmp/binarydeb/ros-kinetic-costmap-2d-1.14.4/src/costmap_2d_ros.cpp:109(Costmap2DROS::Costmap2DROS) [topics: /rosout, /cmd_vel, /move_base/current_goal, /move_base/goal] Timed out waiting for transform from base_link to map to become available before running costmap, tf error: Lookup would require extrapolation into the past. Requested time 1544296003.923271802 but the earliest data is at time 3532084496.000032766, when looking up transform from frame [base_link] to frame [map]. canTransform returned after 0.101056 timeout was 0.1.

1544296195.027000729 WARN [/tmp/binarydeb/ros-kinetic-costmap-2d-1.14.4/src/costmap_2d_ros.cpp:109(Costmap2DROS::Costmap2DROS) [topics: /rosout, /cmd_vel, /move_base/current_goal, /move_base/goal] Timed out waiting for transform from base_link to map to become available before running costmap, tf error: Lookup would require extrapolation into the past. Requested time 1544296195.073266109 but the earliest data is at time 3532084496.000032766, when looking up transform from frame [base_link] to frame [map]. canTransform returned after 0.100911 timeout was 0.1.

1544296196.828247318 WARN [/tmp/binarydeb/ros-kinetic-tf2-0.5.19/src/buffer_core.cpp:277() [topics: /rosout, /initialpose ... (more)

edit flag offensive delete link more

Comments

Please don't use an answer to ask a question. This isn't a forum. Please create a new question and reference this question instead.

jayess gravatar image jayess  ( 2018-12-08 21:24:20 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-10-06 17:31:01 -0500

Seen: 1,547 times

Last updated: Dec 15 '18