Camera D455 not detected by librealsense on JETSON nano (Buildroot)

[FrGrQuim]

---

Required Info
Camera Model	D400
Firmware Version	05.12.15.50
Operating System & Version	Linux Buildroot
Kernel Version (Linux Only)	4.9.253
Platform	NVIDIA Jetson Nano + Buildroot
SDK Version	2.48.0
Language	Buildroot
Segment	Robot

Issue Description

Hi,

I currently try to build my own Linux version for a robotic application. I use a Nvidia Jetson Nano 2Gb and I need to connect 2 D455 to it. We use buildroot to build Linux with all the required packages.

During the build everything seems to work fine but when I connect the camera and try to enumerate it via rs-enumerate devices I've got the following output:

No device detected. Is it plugged in?

Here the output of dmesg:

[ 80.226804] usb 2-1: new SuperSpeed USB device number 3 using tegra-xusb
[ 80.255665] usb 2-1: New USB device found, idVendor=8086, idProduct=0b5c
[ 80.264801] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 80.274340] usb 2-1: Product: Intel(R) RealSense(TM) Depth Camera 455
[ 80.283259] usb 2-1: Manufacturer: Intel(R) RealSense(TM) Depth Camera 455
[ 80.292598] usb 2-1: SerialNumber: 032623061167
[ 80.300818] uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 455 (8086:0b5c)
[ 80.313750] uvcvideo: Unable to create debugfs 2-3 directory.
[ 80.322082] uvcvideo 2-1:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
[ 80.334096] uvcvideo 2-1:1.0: Entity type for entity Processing 2 was not initialized!
[ 80.344457] uvcvideo 2-1:1.0: Entity type for entity Camera 1 was not initialized!
[ 80.354667] input: Intel(R) RealSense(TM) Depth Ca as /devices/70090000.xusb/usb2/2-1/2-1:1.0/input/input3
[ 80.367532] uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 455 (8086:0b5c)
[ 80.379515] uvcvideo: Unable to create debugfs 2-3 directory.
[ 80.387760] uvcvideo 2-1:1.3: Entity type for entity Processing 7 was not initialized!
[ 80.397949] uvcvideo 2-1:1.3: Entity type for entity Extension 8 was not initialized!
[ 80.408024] uvcvideo 2-1:1.3: Entity type for entity Camera 6 was not initialized!
[ 82.490485] usb 2-1: usb_suspend_both: status 0
[ 82.497323] usb usb2: usb_suspend_both: status 0
[ 82.504014] tegra-xusb 70090000.xusb: entering ELPG
[ 82.511980] tegra-pmc: PMC tegra_pmc_utmi_phy_enable_sleepwalk : port 1, speed 0
[ 82.521595] tegra-pmc: PMC tegra_pmc_utmi_phy_enable_sleepwalk : port 2, speed 3
[ 82.532491] tegra-xusb 70090000.xusb: entering ELPG done

And the output of modinfo uvcvideo | grep ver :

filename: /lib/modules/4.9.253/kernel/drivers/media/usb/uvc/uvcvideo.ko
version: 1.1.1
description: USB Video Class driver
srcversion: 9A99EFA5F104A91638D7315
vermagic: 4.9.253 SMP preempt mod_unload modversions aarch64

As I use buildroot I cannot run the script patch-realsense-ubuntu-L4T.sh but I have applied the kernel patch:

• 01-realsense-camera-formats-L4T-4.4.1.patch
• 02-realsense-metadata-L4T-4.4.1.patch
• 04-media-uvcvideo-mark-buffer-error-where-overflow.patch
• 05-realsense-powerlinefrequency-control-fix.patch

The cmake arg that I provide to librealsense are:

BUILD_EASYLOGGINGPP:BOOL=OFF
BUILD_EXAMPLES:BOOL=OFF
BUILD_GLSL_EXTENSIONS:BOOL=OFF
BUILD_GRAPHICAL_EXAMPLES:BOOL=OFF
FORCE_RSUSB_BACKEND=false
CMAKE_BUILD_TYPE=release

Any idea what goes wrong and how to fix it?

[MartyG-RealSense]

Hi @FrGrQuim If you are using a Jetson Nano, Intel's official Jetson installation guide strongly recommends enabling the barrel jack connector for extra power. Have you done this, please?

https://github.com/IntelRealSense/librealsense/blob/master/doc/installation_jetson.md

If you do not have the barrel jack enabled, Intel's guide recommends the link below for doing so.

https://www.jetsonhacks.com/2019/04/10/jetson-nano-use-more-power/

[FrGrQuim]

As it is the NANO 2GB there is no barrel jack connector. Moreover The cameras are powered by an external supply

[MartyG-RealSense]

Could you try setting FORCE_RSUSB_BACKEND=true please to build librealsense with the RSUSB Backend method instead of the V4L Native Backend.

When librealsense is built with the RSUSB method, it is not dependent on Linux versions or kernel versions and does not require patching. If the D455 works with an RSUSB build then this would suggest that the camera detection problem may be occurring because of a conflict with Buildroot.

[FrGrQuim]

The camera is detected now :) Thanks a lot

Just two question:
1- Is the performances influenced by the method used to build librealsense?
2- We use the official linux version furnished by Nvidia and we apply the patch furnished by librealsense so what can be the problem by building via buildroot? (If you need more information I can send it)

[MartyG-RealSense]

Great to hear that you were successful :)

Although the same code will work with both backends, there may be some performance differences in the background. For example, by default the RSUSB backend checks for device changes every 5 seconds by default whilst V4L checks more often. This means that with RSUSB, if you try to change a setting with get_option then the SDK may miss the request. You can though reduce the checking time period to perform it more often at the cost of slightly higher CPU percentage usage. The subject is discussed in detail in #6952 and #6921 (comment)

Another difference is that a patch-based build is more suited to multiple camera projects than RSUSB, though improvements to multicam handling with RSUSB were made in SDK version 2.35.2. You may find that with 2 cameras your project still works fine with RSUSB.

In regard to other differences, #5212 (comment) discusses in detail the advantages and disadvantages of using an RSUSB installation (also known as libuvc backend) versus a patch-based installation. Please scroll down through the linked-to comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules?

In regard to your second question, as far as I am aware buildroot has only been asked about once before in 2019 in case #5497 and there is no information available on the subject. In general though, the Linux OS bypass provided by RSUSB is a good way to resolve problems that may be related to an exotic Linux version or kernel.

[MartyG-RealSense]

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

[MartyG-RealSense]

Case closed due to no further comments received.