-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time drift between depth frame andHost PC #1373
Comments
Hi @gachiemchiep The subject of syncing between host computer time and ROS time is discussed in the link below, with advice provided by Doronhi the RealSense ROS wrapper developer. I note that you seem to be changing the value of the frame queue size in your settings. Is this correct please? If so, doing so is not recommended as you can end up accidentally breaking the streams with your chosen value. Dorodnic the RealSense SDK Manager describes this in the comment linked to below: IntelRealSense/librealsense#5041 (comment) I believe the default frame queue size is '1', with '2' being suggested by the librealsense frame management documentation if using both color and depth streams instead of just a depth stream. Also, do you have any Frame metadata isn't available! messages in your ROS log when you perform roslaunch? |
Hello @MartyG-RealSense . We didn't change the frame_queue_size value, so I think those values are default values of realsense-ros. Based on a comment here #937 (comment) . I think the value of frame_queue_size is totally fine. |
Hello @MartyG-RealSense [ WARN] [1599793582.728492795]: Frame metadata isn't available! (frame_timestamp_domain = RS2_TIMESTAMP_DOMAIN_SYSTEM_TIME) We used the default realsense launch file and now the latency is as : ---
# rostopic echo /joint_states/header
seq: 1853
stamp:
secs: 1599793858
nsecs: 846618389
frame_id: ''
# rostopic echo /camera_1/depth/image_rect_raw/header
seq: 498
stamp:
secs: 1599793858
nsecs: 822190046
frame_id: "camera_1_depth_optical_frame"
|
It is recommended to match a particular ROS wrapper version as closely as possible with a specific librealsense SDK version listed on the ROS wrapper's Releases page. It looks as though the best fit for SDK 2.32.1 (the one that you listed as being used by you) would be ROS wrapper 2.2.12 if you are not using it already. https://github.com/IntelRealSense/realsense-ros/releases/tag/2.2.12 In regard to the Frame metadata isn't available warning, Doronhi the RealSense ROS wrapper developer offers advice in the link below: I am not sure how to interpret the latency readings from using the default realsense launch file. Is it better or worse than the 0.3 seconds that you reported originally please? |
Hi @gachiemchiep Do you require further assistance with this case, please? Thanks! |
Frame metadata is needed for accurate time stamps. Without it the timestamps are approximately the host time when the frame arrived to the host which could be 0.3 seconds after it was taken. You should try to fix the Frame metadata isn't available warning. |
Hello @dorodnic and @MartyG-RealSense |
Thanks very much for the update of your progress @gachiemchiep |
Hello, using librealsense2 2.32.1 and realsense-ros 2.2.12 fix our problem. |
Great news @gachiemchiep - I'm very pleased that you found a solution. Thanks for letting us know! |
Hello guys
Recently, we're developing reconstruction software using D435 and UR5 robot.
The D435 is attached to UR5 and moved around the object to generate a 3d model of it.
As I understand theUR5 driver uses host PC clock for the timestamp.
And D435 should also use the host PC clock for the timestamp
Unfortunately, when we checked it, the D435 is 0.3 seconds behind the host PC clock.
This leads to wrong tf transformation and screw the reconstruction software.
The last frame of UR5 robot (Host PC clock) and D435 look like this.
I'm using v2.32.1 and the settings of depth look like this.
Is there any method to sync the clocks between D435 and the Host PC?
The text was updated successfully, but these errors were encountered: