send_timestamp and receive_timestamp are not comparable

[JWhitleyWork]

When eCAL::rmw::Publisher::Publish is called, it calls this version of the Send() function which defaults the time_ argment. That means that here the write_time that gets passed to CDataWriter::Write is populated with eCAL::Time::GetMicroSeconds().

However, when the eCAL::rmw::Subscriber::OnReceiveData callback is triggered, it sets the receive_timestamp using eCAL::Time::GetNanoSeconds().

[JWhitleyWork]

However, after digging through what ROS2 RMW is expecting, these should both be in nanoseconds. Here rmw_time_point_value_t aliases rclutils_time_point_value_t which is defined here as being nanoseconds since the Unix epoch.

[KerstinKeller]

So, in general, the eCAL level records timestamps in microseconds, while the ROS world works with nanoseconds.

In general, eCAL timestamps both when sending, and when receiving the data, both in microseconds.
E.g. these values make it into eCAL measurements.

On the other hand, in ROS userland, nanoseconds are used. This is why, as you noted, eCAL::rmw::Subscriber::OnReceiveData timestamps again in the receive function, to provide the user with the nanoseconds. (I guess here, we could also use the originally timestamp at the lowest level receive and multiply by 1000, instead of querying again).

Sooo... I guess the user need to be concerned with the way eCAL timestamps intenally, and just use the ROS userland timestamps in nanoseconds? And where / how are you accessing the eCAL internal send_timestamp, if you say that they are not comparable with the receive ones?

[JWhitleyWork]

@KerstinKeller Thanks for the quick reply! The subscriber data queue in the RMW populated here when a message arrives contains both the sent timestamp (pulled from the message received on a CSubscriber) and the receive timestamp (generated when the message is enqueued). We want to compare them for statistics analysis but ran into the issues with units. However, I think have a solution (#66). Please review if you have time.