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

Rostime convention: sec+nsec vs microsec

asked 2016-11-01 13:39:03 -0600

dejanpan gravatar image

Hi there! Current ros::Time represents time in a form of sec and nsec. Was there any particular reason for choosing this representation or are there any particular advantages of it?

We currently discuss time representation in our group and the feel is to go with microsec only since this is the resolution that modern hardware for Unix supports ( ). Does anyone see any obvious disadvantage in doing it so?

edit retag flag offensive close merge delete


Just pasting in some comments from @tfoote: for ROS1 I don't think we have design documentation. We wanted at least nanosecond resolution and wanted at least 64bit resolution. We've been thinking of just using just uint64. I think in the early ROS iterations we didn't consider uint64 as standard.

dejanpan gravatar image dejanpan  ( 2016-11-02 11:15:52 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-11-02 14:03:30 -0600

tfoote gravatar image

Thinking back a little bit more. The choice of sec and nsec was to keep the timestamps human readable on introspection. Reading a sec, nsec tuple is relatively easy for human readability and understandability. You loose some amount of time representation into the future since not all 64 bits of data are useable. But human readability is valuable.

There are things that can provide higher accuracy than the unix timers. Some sensors etc rely on that level of precision.

Clearly in most cases you will not need the full resolution. But how much do you save if you use microseconds? If you use a 64bit representation nano-seconds will work for more than 500 years past the epoch, while microseconds will last more than 500000 years past the epoch. A 32bit representation is not adequate for either microseconds or nanoseconds to represent the current date past the epoch. Picking a width between 32 and 64 is likely to just need padding for most operations and the additional complexity is makes it undesirable.

Since you cannot really make the data more compact by dropping 3 significant figures, I would suggest that supporting the higher resolution has more potential uses than being able to plan millenniums into the future.

edit flag offensive delete link more

Question Tools



Asked: 2016-11-01 13:39:03 -0600

Seen: 3,230 times

Last updated: Nov 02 '16