Unusable timestamps in D435i/D455 on Tinkerboard #1906
Comments
|
Hi @ramonvp I note from your log that you have already tried the most common approach for dealing with the Time is out of dual 32-bit range - initial_reset and enable_sync. If changing the reset or sync does not work, there are some less commonly used solutions that can be explored. A solution for some RealSense ROS users has been to clean their catkin workspace. A user of Raspberry Pi (an Arm device like your board) switched their Pi from Raspbian to the Pi version of Ubuntu and also used a more stable power connection. Whilst someone on the same discussion suggested checking that the time on the computer is up to date. |
|
Hi @MartyG-RealSense, thanks for your quick reply. Regarding the power supply, I already experienced that problem. At first, I was using an adapter that provided 5V-3A to the board, but I was getting these messages: I then switched to a power supply that was capable of providing 5V-4A and the message disappeared. Changing the OS is not an option and besides, Armbian Focal is the most similar thing to Ubuntu for the Tinkerboard. Cleaning the workspace: I did try that also, and even I created a separate workspace with only the necessary packages: realsense2_camera and realsense2_description. I cleaned and compiled from scratch several times. Finally, setting correctly the system date was also one of the first things I checked. I would however expect the published timestamps to be according to the system date, no matter how off it is from the real one. But again, just in case, I double-checked. The thing that I would like to try, but don't know how, is to disable the GLOBAL TIME feature and use instead the HARDWARE_CLOCK. Any recommendation on how to test this? I can't seem to find an option to pass to the roslaunch file. Thanks in advance. |
|
You should be able to disable global time in RealSense ROS by adding the command below to your roslaunch instruction. global_time_enabled:=false For example: roslaunch realsense2_camera rs_camera.launch initial_reset:=True enable_sync:=True global_time_enabled:=false |
|
I can't seem to find the argument 'global_time_enabled'. Even looking into the source code, there is no private parameter retrieved from the parameter server with a similar name or function. Is it possible that this argument/option was removed in a previous version? |
|
You should not need to look for this setting in the parameter server. It should just work if you include enable_global_time:=false in the roslaunch instruction. To be clear, I am not referring to adding a rosparam to the inside of the launch file but instead adding it to the launch command. If you would prefer to control the setting in ROS1 during runtime, the link below demonstrates its use in a dynamic reconfigure command. |
|
I tried passing the argument in the launch command as you suggested and it doesn't make any difference regarding the timestamp issue. The search returns empty. This argument is simply not used in current version, if I'm not mistaken. |
|
I am not aware of the status of enable_global_time having changed. My understanding from commentary in the past by Doronhi the RealSense ROS wrapper developer though is that disabling global time in ROS does not have as significant an effect on time drift as disabling it in librealsense does. |
|
Most of the options are derived directly from librealsense2 so they have no specific reference in the realsense2_camera code. Disabling the global time in ROS disables it in the librealsense library. What is left in ROS is just adding a constant to every frame to match the gap between the system time and the hardware time, The constant is set once, according to the time difference of the first frame arriving. Consequently, any time difference that will develop is caused by a different rate, if there is one, between the system clock and the device's inner clock. Global time tries to compensate for the difference between the system's progression rate and the device's. Although I can't see how it may cause the issue above, if disabling it makes a difference it could, perhaps, point us to a bug or to the origin of the problem. |
|
Hi @doronhi, thanks for your comments. I tried your suggestion but apparently it did not disable the global_time feature. However, after digging a little bit in the source code, I applied this simple change: And now I can see the confirming output trace: *** DISABLING GLOBAL_TIME FOR SENSOR RGB Camera *** DISABLING GLOBA_TIME FOR SENSOR Stereo Module [ INFO] [1622666558.159676355]: SELECTED BASE:Depth, 0 [ INFO] [1622666558.179594225]: RealSense Node Is Up! [ WARN] [1622666558.348953144]: [ WARN] [1622666558.349092563]: frame's time domain is HARDWARE_CLOCK. Timestamps may reset periodically. After this change, if I run my test node again, now I get: So yeah!! Now this looks better! However, I left the node running for a while and after 1 hour only, it had already accumulated a drift of aprox 300ms, which I guess that was the reason for implementing the "GLOBAL_TIME" feature in the first place! 🤣 So, is this behaviour hiding a bug? My guess is that there must be something during the initialization that fails in my platform when global_time is enabled, but works fine in x86. How can I help to discover this? I really need to make this work. Thanks again! |
|
I could not reproduce using USB2.1 connection but then again, I don't have a Tinkerboard S with me. |
|
Yes, you are right, frame timestamp and time of arrival are significantly off: 1622729172393.4 vs 1622756096241. What does it mean? |
|
We can determine that the origin of the issue is in the librealsense2 library but I don't know about the cause yet. |
|
Hi @ramonvp Do you require further assistance with this case, please? Thanks! |
|
Hi @MartyG-RealSense , sorry for the delay. I was last week out of the office and could not perform the test @doronhi suggested. Will report back probably tomorrow with the results. |
1 similar comment
|
Hi @MartyG-RealSense , sorry for the delay. I was last week out of the office and could not perform the test @doronhi suggested. Will report back probably tomorrow with the results. |
|
No problem @ramonvp - thanks very much for the update. I look forward to your test results. Good luck! |
|
Hi again @doronhi , I tried toggling the "Global Time Enabled" and when I enabled it back, the huge difference in timestamps still persists. I repeated several times just to make sure the effect is repeatable. |
|
I don't have an idea right now where the issue might stem from. |
|
@ramonvp When you see big off between frame time stamp and arrival time stamp and enable global time stamp is mainly for multicam usage that use time stamp to sync between different camera https://dev.intelrealsense.com/docs/external-synchronization-of-intel-realsense-depth-cameras |
|
Hi @ramonvp Do you require further assistance with this case, please? Thanks! |
|
Case closed due to no further comments received. |
|
Hi @ramonvp , |
|
Hi @doronhi, thanks for taking a deeper look into it.
|
|
Ok, I found my notes, here's a quick guide:
We need to tell CMake to use the latest OpenGL library. By default, it will detect 2 versions, legacy and new. Add the following lines to the beginning of the file:
|
|
Yes, thank you very much for the detailed description. I also try to reproduce the issue using rs-data-collect. |
|
I think I managed to reproduce on a NEO4 NanoPi machine. I need to be sure as this is indeed very weird and I'll keep you posted. |
|
That's great to hear @doronhi! Just let me know if there's anything I can do to help. |
|
There is a temporary "fix" that prevents raspberry PI from using the global timestamp. See here I still need time to investigate but I would like you to replace that line "#ifdef RASPBERRY_PI" with "#ifdef false", build and test again with global time stamp on. It seems like the correct solution to your issue but I don't know what to make of that remark so I'll appreciate your input. Other than that, it seems that the wrapper should have the option to use librealsense's "system_time domain" directly if one can't use "global time domain". This is not a 1-line change so I'll need some time to test it. I'll try to prioritize it as well. |
|
Hi again @doronhi, I have good news for you: your suggestion works! Running now the realsense-viewer with global time stamp enabled shows a match between the time of arrival and the frame timestamp. I am wondering why the code is being compiled with the -DRASPBERRY_PI in my platform, somehow it must have picked it up from somewhere. So, for future builds, should I remember to comment out these lines or do you think there will be a patch/commit in the near future? Running the script presented in my original post, I am getting now an time diff of around 100ms, which I still think is too much, but probably usable. This can now be really due to a hardware performance issue. The nodelet manager launched in package realsense2_camera is taking, according to This week I will try again to integrate with move_base (Navigation Stack in ROS1) and see how the real robot performs. If you are interested, I can report back with the results. Thanks for your time, I really appreciate your effort! |
|
Hi @ramonvp , As for the 100ms difference, I didn't try it on the rockchip. If you believe the source of the issue is realsense (either device, librealsense of the realsense2_camera wrapper) please open a new issue for it. |
|
The fix missed the upcoming librealsense2 version 2.49.0 and will be available in the next version - 2.50.0 |
|
Hi @ramonvp Do you require further assistance with this case, please? Thanks! |
|
Hello @MartyG-RealSense , the issue has been identified and resolved in the librealsense repo. Please see @doronhi 's PR here: IntelRealSense/librealsense#9595. |
|
Thank you very much @ramonvp |
Hi everyone, I am not sure if this issue should be posted here or in the librealsense repo, since I don't really know the origin of the issue. My platform:
Issue Description
I am trying to make a D435i work on the Tinkerboard S with Focal, which only offers USB2. I compiled both SDK v2.45 and RealSense ROS v2.3.0 from source. I also patched the kernel as indicated by the linux instructions. When launching rs_camera.launch, I can get the depth image as well as the RGB image. However, the timestamps look to me very odd and with a huge offset.
I have already read almost every issue posted in this forum and other ones as well, including:
To better observe the issue, consider the following Python script:
I first tried this script in my Intel workstation. I actually have tried with 2 different computers, both with USB3.2:
In both cases, I get all streams (depth, rgb, infra1, infra2, etc...) with the expected 30Hz, and the scripts outputs:
And then quickly stabilizes to a difference of around 10ms, which is a very reasonable value.
However, when I run this same script on the Tinkerboard, I get this very different output:
And after 15-20seconds, it stabilizes to a value of 13200secs = 3.7hours! It doesn't really stabilize, since the value keeps fluctuating. I am launching the ROS node with the following command, as suggested in other posts:
This is the full output when launched above commands:
The issue happens with both D435i and D455 cameras. I am hoping there is some way to fix the issue, considering that other users have reported to being able to make it work with Raspberry Pi 3 and Odroid platforms.
I have also tried with kernel 5.10.xx, with identical results. Anybody has any suggestion on how should I proceed? Suggestions are very welcome, thanks!
The text was updated successfully, but these errors were encountered: