Ros timestamp shows incorrect values

[ieperen3039]

Required Info
Camera Model	D435i
Firmware Version	05.11.15.00
Operating System & Version	Ubuntu 18.04
Kernel Version (Linux Only)	5.0.0-32-generic
Platform	PC
SDK Version	2.29.0
Language	-
Segment	-

Issue Description

As I was trying to calibrate the D435i IMU using the RGB camera, i found that the tool encountered an error concerning the timestamps. After a few days I found that the timestamps in the message headers of the RGB topic are corrupted.

I record a rosbag file using realsense-viewer, enabling the RGB camera on monochrome and including IMU data. If i then inspect the color channel using rostopic echo /device_0/sensor_1/Color_0/image/data --noarr I find that the 'secs' field fluctuates around 3 142 000 000.

This incidentally doesn't happen (once in 20 tries), and doesn't seem to relate to any circumstance in particular.

After some digging, i found that the header starts correctly, as seen here:

header: 
  seq: 0
  stamp: 
    secs: 1571230614
    nsecs: 927141428
  frame_id: "camera_color_optical_frame"
height: 480
width: 640
encoding: "rgb8"
is_bigendian: 0
step: 1920
data: "<array type: uint8, length: 921600>"

but quickly approaches double the value

header: 
  seq: 10
  stamp: 
    secs: 3091655493
    nsecs: 190211296
  frame_id: "camera_color_optical_frame"
height: 480
width: 640
encoding: "rgb8"
is_bigendian: 0
step: 1920
data: "<array type: uint8, length: 921600>"

It seems to shuffle with 1000 seconds at a time

I initially used an installation by the package manager, but recently installed the library from sources trying to mitigate this problem.
I also used roslaunch realsense2_camera rs_camera.launch unite_imu_method:=none to obtain the data, but the resulting topics have the same issue (it does not relate to realsense-viewer nor the bag file reader/writer)

The output when recorded with realsense2_camera is in topic.txt

[ieperen3039]

I have analyzed the frames using the C++ API to look at the raw data. The timestamps from rs2::frameset::get_timestamp also show the exact same problem.

Additionally, I checked with another realsense camera, and this gives the same problem. Hence, I think the problem is somewhere in the firmware or the API, in combination with Linux

[ieperen3039]

Looked into the metadata of the file, and I found that both the BACKEND_TIMESTAMP and the TIME_OF_ARRIVAL_TIMESTAMP do give the correct values, but frame::getTimestamp doesn't. Does this have to do with synchronization with some external clock?
At least i can work with the backend timestamps now.

[ieperen3039]

Found out that the problem can be remedied by disabling all global timestamps. More specifically, i repaced pipe.start() with:

const rs2::pipeline_profile &profile = pipe.start(callback);
const std::vector<rs2::sensor> &vector = profile.get_device().query_sensors();
for (const auto & i : vector) {
    if (i.is<rs2::roi_sensor>()){
        i.set_option(RS2_OPTION_GLOBAL_TIME_ENABLED, 0);
    }
}

which disables the global time for all camera-based, which then default to the (correct) hardware clock. The new value correspond to the original IMU timestamps

I don't consider this problem solved, but at least it is a workaround.

[ieperen3039]

Tested this on another laptop, and realized that the hardware clock of the color camera should not give you the current UNIX epoch... This is probably something in the library synchronizing the camera to the system time? Also, this apparently only occurs on my specific installation.

[RealSenseCustomerSupport]

---

I think this is similar to the issue that was reported in:
#4505
Glad to hear that you can use the workaround. Please let us know for any further question. Thank you.