need for a Time data type without a clock about rclpy HOT 11 CLOSED

Would Duration do for your use case? My understanding is that a point in time is a duration of time since an epoch. If there's no clock then it would just be a duration.

from rclpy.

Would Duration do for your use case?

Currently our operators don't work for that:

• No + or - operators defined for Duration
• But Time offers:
  • Time + Duration = Time
  • Time - Time = Duration

Also the to_msg / from_msg methods map to the same named builtin_interface.

So using Duration for a Time doesn't sounds viable to me (at least at the moment).

from rclpy.

I agree with @sloretz, a time point without a clock doesn’t have meaning since you don’t know the epoch. For from_msg it is implicitly going to use a clock with a Unix epoch.

from rclpy.

For from_msg it is implicitly going to use a clock with a Unix epoch.

Currently the from_msg function chooses ROS_TIME - not Unix epoch.

The point is when receiving a timestamp e.g. in the header field of a message which clock can we assume? There seems to be at least a mismatch atm.

from rclpy.

pitching in here that in the implementation (as of today), time points created from messages are going to default to ROS Time as the clock type (in rclcpp and in rclpy).

When I was writing tests such as this one I wondered if there should be an additional field in the Time message for the clock type. Without it, if you have a time point with, say, steady time, that info is lost when converting it to a message and sending it to someone else. (I imagine that @dirk-thomas may have been on the receiving end of this message in the use case that prompted this -- it is not so much that there isn't an clock type associated with it, but that it is unknown). I reasoned, however, that in that situation the clock type would be communicated out-of-band, so it wasn't necessary to add the field. But adding it explicitly to the message definition could be another approach to addressing this.

from rclpy.

adding it explicitly to the message definition could be another approach to addressing this.

This would result in diverging from the DDS builtin Time_t structure definition, that I think was the original motivation for not modifying the message definition (not saying it shouldn't be done, just writing down my recollection)

from rclpy.

Currently the from_msg function chooses ROS_TIME - not Unix epoch.

ROS Time uses the Unix epoch.

from rclpy.

The point is when receiving a timestamp e.g. in the header field of a message which clock can we assume?

In ROS 1 we assume ROS Time which assumes Unix Epoch, so I think that's appropriate for our time message in ROS 2 as well:

# * stamp.sec: seconds (stamp_secs) since epoch (in Python the variable is called 'secs')
-- https://docs.ros.org/kinetic/api/std_msgs/html/msg/Header.html

If we wanted to represent a different epoch (like for steady time) then I think we should have a SteadyTime.msg type. Similar to how we have both Vector3 and Point, same data structure but different semantic. We could also include the clock type as a data field in the message but that seems less efficient in my opinion since it usually would not change.

from rclpy.

ROS Time doesn't always use the unix epoch. It defaults to system time if sim time isn't active, but if sim time is active it may, for example, start at 0s and count up from that if the /clock is being published by e.g. Gazebo.

from rclpy.

ROS messages with the timestamps are implicitly using ROS Time. This is the time of the ROS system that's expected to be synchronized between nodes. Whether it's a realtime system which is passing through the wall clock, or running in simulation with a stepping /clock topic or any other clock synchronization method. We could easily define the other time types as @wjwwood suggests both steady time and system time to support sending them around. But so far we generally haven't had a strong need for sending times around explicitly.

from rclpy.

If we are fine with builtin times always being interpreter as ROS_TIME the snippet I recommended in ros2/ros2cli#139 (comment) should be sufficient. Thank you for the discussion.

I will go ahead and close this request then.

from rclpy.