Skip to content
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

frame metadata backend_timestamp = 0? #7972

Closed
amm385 opened this issue Dec 10, 2020 · 6 comments
Closed

frame metadata backend_timestamp = 0? #7972

amm385 opened this issue Dec 10, 2020 · 6 comments

Comments

@amm385
Copy link

amm385 commented Dec 10, 2020

Required Info
Camera Model D435
Firmware Version don't have it on me :(
Operating System & Version Ubuntu 18
Kernel Version (Linux Only) 4.9.140-tegra
Platform NVIDIA Jetson
SDK Version 2.36.0
Language python
Segment Robot

Issue Description

I'm getting a value of 0 for my frame's backend_timestamp value:
frame.get_frame_metadata(rs.frame_metadata_value.backend_timestamp)
frame.get_frame_metadata(rs.frame_metadata_value.time_of_arrival) and frame.get_timestamp() are both working correctly. What does this mean? From what I've read on this forum, sensor_timestamp and frame_timestamp require a kernel patch, but time_of_arrival should be supported universally.

@MartyG-RealSense
Copy link
Collaborator

MartyG-RealSense commented Dec 11, 2020

Hi @amm385 I extensively researched your issue with backend_timestamp being zero. My understanding is that backend_timestamp is a system time timestamp that is dependent on the OS, and not a firmware-generated timestamp. So there was no clear reason why the timestamp would be 0.

My research did find a case though where a couple of RealSense users encountered this zero result on Raspberry Pi 4, which like Jetson uses an Arm processor. There was also a case of a zero result for this timestamp on an Android device, which typically use Arm processors. So I wonder whether the zero result is Arm-related.

IntelRealSense/realsense-ros#1324

There was not a clear solution on the above case. One of the Pi 4 users used a laptop instead.

@amm385
Copy link
Author

amm385 commented Dec 11, 2020

Thanks for the response, I too was suspecting it might be related to the ARM architecture, or the kernel build specific to that architecture.

Interestingly, I have a separate arm computer that is working fine, so it must be something very specific to the instance i'm having issues with. (The computer I have that's functioning is a Jetson TX2, the one that's returning 0 is an industrialized TX2)

Either way, good to know this is not just a simple user error on my end, will continue to look into it

@MartyG-RealSense
Copy link
Collaborator

Thanks very much @amm385 for the update. Good luck with your investigations!

@MartyG-RealSense
Copy link
Collaborator

Hi @amm385 Do you require further assistance with this case, please? Thanks!

@amm385
Copy link
Author

amm385 commented Dec 19, 2020

tbh I've put this problem on the backburner for now. If I revisit and figure something out, I'll be sure to update, but no assistance needed for now

@MartyG-RealSense
Copy link
Collaborator

Okay, I will close the case for now. Please feel free to create a new case if you return to the problem and require assistance. Good luck, and thanks for the update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants