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

differential_drive_controller publishing with wrong timestamps

asked 2016-01-25 06:45:43 -0600

aba92 gravatar image

Hello,

I'm using the differential_drive_controller plugin in urdf of my robot:

  <!-- differential drive -->
<gazebo>
    <plugin name="differential_drive_controller" filename="libgazebo_ros_diff_drive.so">
        <alwaysOn>true</alwaysOn>
        <updateRate>100</updateRate>
        <leftJoint>right_wheel_joint</leftJoint>
        <rightJoint>left_wheel_joint</rightJoint>
        <wheelSeparation>1.2</wheelSeparation>
        <wheelDiameter>0.3</wheelDiameter>
        <torque>5</torque>
        <commandTopic>cmd_vel</commandTopic>
        <odometryTopic>stereo/odom</odometryTopic>
        <odometryFrame>stereoodom</odometryFrame>
        <robotBaseFrame>base_link4</robotBaseFrame>
    </plugin>
</gazebo>

Everything works fine, although its data topics are publishing with completely wrong timestamps (they're huge).

    header: 
  seq: 175517
  stamp: 
    secs: 1453724932
    nsecs: 329340743
  frame_id: stereoodom
child_frame_id: base_link4

How I'm using tf's this is being annoying. Can anyone help me on this? Please.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-01-26 04:00:58 -0600

gvdhoorn gravatar image

updated 2016-01-26 04:01:24 -0600

Everything works fine, although its data topics are publishing with completely wrong timestamps (they're huge).

header: 
  seq: 175517
  stamp: 
    secs: 1453724932
    nsecs: 329340743

The stamp looks fine to me.

Remember that it actually represents seconds since epoch (from docs.ros.org/std_msgs/Header):

Two-integer timestamp that is expressed as:

  • stamp.sec: seconds (stamp_secs) since epoch (in Python the variable is called 'secs')
  • stamp.nsec: nanoseconds since stamp_secs (in Python the variable is called 'nsecs')

time-handling sugar is provided by the client library

So in your case, 1453724932 is actually Mon, 25 Jan 2016 12:28:52 GMT and some nanoseconds (converted using epochconverter.com).

edit flag offensive delete link more

Comments

gvdhoorn gravatar image gvdhoorn  ( 2016-02-09 02:16:34 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2016-01-25 06:45:43 -0600

Seen: 329 times

Last updated: Jan 26 '16