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

Revision history [back]

click to hide/show revision 1
initial version

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).

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).