Of clocks and simulation, betimes and otherwise

[wjwwood]

Sorry it has taken so long for me to reply here, but I just wanted to make some short replies to help connect different parts of the discussion.

@BrannonKing

First, it appears that there has as yet been no attempt to support non-wall-clock time (er, simulator or playback time) in ROS2. True? It appears that rcl/time.c has some support for that, but I can’t see that this support is exposed in rclcpp::Time. Is there something I missed there or is anyone working on a newer use_sim_time? I feel a little bit late to the party. Sorry.

No you’re right about that. We’ve thought about it enough to start the design doc and to implement the parts we believe are necessary to support ROS 1 style sim time in rcl’s C code, but we’ve stopped short of implementing ROS 1 style sim time (using a /clock topic) or exposing it in C++ and making an example to demonstrate how it would work.

@BrannonKing

At ASI we’ve worked around this by publishing our own clock signal at high frequency, but I feel like arbitrary clock support needs to be built into the core framework. I believe that non-realtime playback is a critical feature because I believe simulation and playback should work out of the box.

I agree, this is a crucial feature in ROS 1 and I think we need it in the core of ROS 2 as well.

@BrannonKing

In addition to simulation, though, there is a need to support hardware platforms that don’t have (wall) clock chips. This is not mentioned in the design document. Although rare, there still exists plenty of embedded processor boards without clocks or batteries. On the other hand, there aren’t any remaining embedded devices without runtime frequency counters. I think we’re safe to assume that all platforms have timers accurate to the millisecond, and that 99% of the platforms have timers accurate to the microsecond.

Your right, and thanks for starting to discuss this related topic there (@tfoote already referenced it too): enhanced time article to include realtime factor by BrannonKing · Pull Request #128 · ros2/design · GitHub

I think we can continue to discuss the options for /clock (or a similarly named topic) in that pr.

There’s a lot more to comment on @BrannonKing’s original post , but I’ll get back to that in another post or on the reference pr.

@BrannonKing

The other thing I needed to mention about the time message that has to change: two fields for the timestamp. Two fields – really? Is there some advantage to it? A single 64bit nanosecond value would be infinitely more handy in my mind. I can read and write that atomically with no extra work on my common x64 platforms. I’ve had to resort to std:atomic for the current time message just so I don’t accidentally read a nanosec value with the wrong sec value. It’s not pretty.

I agree with you.

If you look in the implementation of time in rcl it uses a single uint64_t to store nanoseconds for a time point and a single int64_t to store nanoseconds for a duration. I did this after much research and talking with a few people at OSRF.

I did not, however, get the chance to write down all the justifications so that I could argue that the time message be switched from the current system of two 32-bit ints to a single 64-bit int. There are some trade-offs, but I think it’s a good path forward. Unfortunately there would be a lot of inertia to overcome when changing this, because changing the time layout would affect lots and lots of code in ROS 1 I think. This isn’t a reason in itself not to do it, but it does mean we need to be sure it is necessary and properly justify it and provide decent migration options.

@gbiggs

x64 platforms are increasingly common, but an explicit use case for ROS2 is small, embedded microprocessors that are not 64 bits.

This is true, but even those on machines without 64-bit instructions, the compiler will generate code to do the 64-bit math using 32-bit registers and it will almost certainly be faster and more correct than what we do. I think this is a commonly used but weak argument against using a 64-bit type for this.

Historically the time_t was 32-bit because it was conceived before machines and languages had 64-bit type support. This is an interesting read:

Unix time | Representing the number

Some OS’s have already expanded their underlying storage to 64-bit. Either way we have no good reason to stick with this layout for time in our messages.

But this is an argument that needs to be made formally, so I won’t dive deep into it now.

I’ll continue with @BrannonKing and @tfoote on the pr.