0
$\begingroup$

Rosanswers logo

I have been trying to create my own bot that could navigate. my tf tree is as follows:

map >> odom >> base_link >> hokoyo_link

whenever I select "base_link" LaserScan is fine but when set "map" as a fixed frame in LaserScan plugin (in rviz) shows error :

Message removed because it is too old (frame=[hokuyo_link], stamp=[4479.536000000])

I'm attaching tf tree for your reference link to tf tree

thanks in advance

EDIT -1 @gvhoorn by plugins do u mean that I should only have components which is inside the plugin tag and delete other components in my xacro file.Her is the xacro file for your reference

<gazebo reference="hokuyo_link">
<material>Gazebo/FlatBlack</material>
<sensor type="ray" name="lds_lfcd_sensor">
  <pose>0 0 0 0 0 0</pose>
  <visualize>false</visualize>
  <update_rate>5</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>360</samples>
        <resolution>1</resolution>
        <min_angle>0.0</min_angle>
        <max_angle>6.28319</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.120</min>
      <max>3.5</max>
      <resolution>0.015</resolution>
    </range>
    <noise>
      <type>gaussian</type>
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </ray>
  <plugin name="gazebo_ros_lds_lfcd_controller" filename="libgazebo_ros_laser.so">
    <topicName>scan</topicName>
    <frameName>base_link</frameName>
  </plugin>
</sensor>

Originally posted by sidharth.jeyabal on ROS Answers with karma: 38 on 2021-11-11

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Quick comment: you mention Gazebo, and a "driver". Gazebo doesn't use drivers, only plugins. If you're mixing Gazebo with real hardware, getting timestamps consistent is going to be challenging.

One of the symptoms would be really "small" timestamps (such as the value you show: 4479.536) and "normal" values (such as 1636617041.xyz), which is the current value of the wallclock.

Trying to lookup transforms across such a huge difference in time will cause errors such as the one you mention.


Edit 1:

@gvhoorn any ideas where to tune these time...and how to find what is causing it to happen??

No. I don't.

I'd suggest to make sure you have use_sim_time set everywhere.


Originally posted by gvdhoorn with karma: 86574 on 2021-11-11

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by sidharth.jeyabal on 2021-11-11:
thanks @gvdhoorn .I'm new to ros and have done a mistake while asking questions I'm not using this driver. But what I meant to mention was that I'm using HLS 2d scanner for my purpose. I have edited the details of question please help me

Comment by gvdhoorn on 2021-11-11:
In any case you want to make sure to only use either simulation time, or real time. Mixing will result in "transform too old" or "too new" problems.

Comment by sidharth.jeyabal on 2021-11-11:
@gvhoorn any ideas where to tune these time...and how to find what is causing it to happen??

Comment by sidharth.jeyabal on 2021-11-11:
@gvdhoorn sorry but when u say to add it everywhere, what do u mean by that in launch files?? ...or before running any launch file in command line...

Comment by gvdhoorn on 2021-11-11:
I didn't write add, but set.

It's indeed a global parameter. Setting it in the root of a .launch file should be sufficient (provided all your nodes are started after that parameter is set).

Comment by sidharth.jeyabal on 2021-11-11:
Thank you so much @gvhoorn..I will try it and give u feeback

Comment by sidharth.jeyabal on 2021-11-11:
thank you so much that worked!!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.