SDK 2.43 with usb 2.1 issue

[tugbakara]

Hi @MartyG-RealSense !
I faced this issue before. Then I passed SDK 2.43 now in every log I looked at I saw realsenses connected Jetson AGX via USB port 2.1. But it has to be USB 3.2 because of USB 2.1 I guess I cannot use realsense full efficient. Does SDk cause this issue? If yes, how can I solve it and another question is about inital_reset param. Does it delete all calibration datas when setted true?

[MartyG-RealSense]

Hi @tugbakara Yes, the camera's performance will be limited on a USB 2.1 connection. USB2 has a slower data transfer speed than USB3 and the range of supported resolution and FPS modes is more restricted. Information about this can be found at the link below.

https://www.intelrealsense.com/usb2-support-for-intel-realsense-technology/

A camera may be more likely to be mis-identified as a USB 2.1 device if the USB cable's connector is inserted slowly into the USB port instead of with a quick, firm insertion.

If a camera is consistently identified as USB 2.1 even when the connector is permanently plugged into a port then it may be related to the particular USB controller on a computer rather than an issue related to the camera or SDK. There are different brands of USB controller, so using a USB hub (which will likely have a different brand of built-in USB controller to the one used for the computer's built-in USB ports) may make a difference if the camera is being mis-indentified when plugged directly into the computer.

If you are already using a hub, changing the hub could also make a difference. A brand that has been tested as working well with RealSense cameras is Amazon's AmazonBasics USB 3 mains electricity powered hubs.

I would also recommend using the official 1 meter USB cable supplied with the computer, or a high-quality cable if you need to use a longer cable of your own choice. When choosing your own cable, an inexpensive cable suited to device charging instead of data transfer could increase the chances of problems occurring. The self-chosen cable also needs to be a USB 3 cable if the camera is being used with a USB 3 port, as accidentally using a USB 2 cable would cause the camera to be treated by the computer as being on a USB 2 connection.

The initial_reset parameter is not the same as the Gold Reset (which resets the camera's calibration). initial_reset simply reboots the camera in the same way that physically unplugging and re-inserting it does.

[tugbakara]

Hi Marty I bought 4 different usb cable and tried three of 'em but we saw it becomes USB2.1 and 3.2 depends on the cables when we command out in terminal lsusb -v | egrep "^Bus|MaxPower" we saw it USB2.1 takes 496mA and USB3.2 takes 180mA and when we used USB3.2 we looked at point cloud topics they were fine but other datas coming too slow or sometimes didn't come. But USB 2.1 frequency got lower but ampere that take was fine and there is not any lack of data or any slowness only frequency becomes low as normal but we need 30 fps.
Briefly:
USB 3.2 frequency high (almost 30) but ampere reading from terminal is low.
USB 2.1 frequency low (almost 15) but ampere reading from terminal is high.
Is there any suggestion that we can do?
Have a nice day @MartyG-RealSense ! :)

[MartyG-RealSense]

I am not familiar with the subject of USB cable amperages, though some references found during my research suggested that if you purchase your own choice of cable then using long and thin cables instead of short and thick ones may increase resistance and result in a loss of power. An example of such a discussion is at the link below.

https://electronics.stackexchange.com/a/281812

[tugbakara]

Hi @MartyG-RealSense ! I glanced your link you inserted above but I faced with sth different :
I looked at the topics hz in ros side. I attached all o/s here, me and my colleague suggested that our one camera has an hardware problem about working with USB3.2 here is screen shoots of the USB2.1 and USB3.2 related topics and their hzs (also we powered them externally not from usb anymore but problem continues) :

cameras are connected to USB3.2 cables but run as USB2.1 and frequency decreases ~2 times but there is not any frequency difference between them and there is not any no new message warning:
(labeled as I and II shows that front and back cams and command as : rostopic hz /camera_1/depth/color/points and rostopic hz /camera_2/depth/color/points)

cameras are connected another USB3.2 cable and run as USB3.2 and sometimes frequency of one of the cam looks nice (~30hz) but the other stays ~15 fps and the camera with 15fps sometimes no new message comes up in terminal and sometimes two camera run with 15 fps with no new message but we expect 30fps :

Is it a hardware problem as we suggest or anything else?
Have a nice day! :)

[MartyG-RealSense]

Hi @tugbakara Was the RealSense ROS wrapper installed from packages using the Method 1 apt-get procedure of the wrapper instructions, please?

https://github.com/IntelRealSense/realsense-ros#method-1-the-ros-distribution

Since December 2020 the packages installed by Method 1 have been based on a type of librealsense build called RSUSB backend which does not work as well with multiple cameras that are enabled on the same computer simultaneously, as advised at #1515 (comment)

[tugbakara]

We installed it from source w/o RSUSB backend here our cmake cache:

[MartyG-RealSense]

Which RealSense ROS wrapper version are you using with librealsense 2.43.0 please? The wrapper version that should be matched with 2.43.0 is 2.2.23 for ROS1 or 3.1.5 for ROS2.

https://github.com/IntelRealSense/realsense-ros/releases/tag/2.2.23

https://github.com/IntelRealSense/realsense-ros/releases/tag/3.1.5

If you have already installed librealsense 2.43.0 from source then the ROS wrapper should be built from source afterwards using Method 2.

[tugbakara]

I mean from source we cloned github link with adding flags but you mean from source with method 2 is : link , right? then if you meant this installation we have to install following these steps for source installation for SDK firstly. Then we have to pass wrapper side in method 2 also?

[MartyG-RealSense]

Cloning the librealsense GitHub (the first link) and installing with CMake (the second link) are two different methods of building librealsense but both are valid approaches.

Method 2 involves first building librealsense with whatever installation method works best for you and the computer / computing device that you are using.

Once librealsense is installed then you should then build the ROS wrapper from source code secondly after that by following Step 2 of the Method 2 instructions.

https://github.com/IntelRealSense/realsense-ros#step-2-install-intel-realsense-ros-from-sources

[tugbakara]

build the ROS wrapper from source code

ah, thanks then we built wrapper as you mentioned. There is not any confusion about SDK and wrapper versions. So could you advice anything else,please?

[MartyG-RealSense]

Which RealSense camera model are you using? My apologies for not asking earlier.

If it is a D405, there is another currently open case at #2486 where 30 FPS is achievable with a D435 but not with a D405.

Also, earlier at #2497 (comment) I asked whether you were attaching the camera to a USB hub. If you are and the cables that you chose are definitely USB 3, then attaching a USB 3 device with a USB 3 cable to a USB 2 hub could result in the attached USB 3 device being treated as USB 2.1.

[tugbakara]

I asked whether you were attaching the camera to a USB hub.

We connected directly to the AGX and via hub nothing changed, everything is same. Also we tried 4 different brand USB3 cable. Hub is USB3 and AGX has USB3. We are using d435i

[MartyG-RealSense]

As you have tried multiple cables and with direct connection and USB hub, that would make the most likely remaining possibility an issue with the camera, since if it was a problem with the Jetson's USB port then the camera would likely work on a hub (unless the Jetson's USB port was treating the hub as a USB 2 device, and so any device attached to the hub would be detected as USB 2 too).

Have you updated the D435i's firmware driver since the camera was purchased? The D435i has an old firmware version by default, so should be firmware-updated after it is purchased. In early firmwares the chance of the camera being mis-detected as USB 2.1 was greater. Fixes to reduce the likelihood of this issue occurring were implemented in a later firmware version.

The firmware version currently installed in the camera is listed on the Device FW version: line of the ROS launch log.

[tugbakara]

we have already 5.13.0.50 firmware with SDK 2.43, cams have a problem with or without hub and also agx (we have two kinda connection : cam<-->hub<-->agx and cam<-->agx )

[MartyG-RealSense]

As you are on Jetson, are you using 2.43 because it has been recommended on this forum as the best SDK version for using pointclouds or depth-color alignment on Jetson, please?

If you are using ROS1, an alternative means of generating a pointcloud in the ROS wrapper would be to use the rs_rgbd launch file, which has been able to generate a good pointcloud in modern wrapper versions newer than 2.43.0 because it uses a different method to the pointcloud filter of rs_camera.launch.

On ROS1 you can try an rs_rgbd pointcloud launch by following the procedure below:

1. Install support for an rgbd launch. Use the appropriate command for the ROS1 branch being used:

KINETIC
sudo apt-get install ros-kinetic-rgbd-launch

MELODIC
sudo apt-get install ros-melodic-rgbd-launch

NOETIC
sudo apt-get install ros-noetic-rgbd-launch

2. Perform an rs_rgbd roslaunch:

roslaunch realsense2_camera rs_rgbd.launch

[tugbakara]

As you are on Jetson, are you using 2.43 because it has been recommended on this forum as the best SDK version for using pointclouds or depth-color alignment on Jetson, please?

Yes, you suggested before in this link.
I will install 2.51 SDK and try to use rs_rgbd.launch.

[MartyG-RealSense]

Hi @tugbakara Do you have an update about this case that you can provide, please? Thanks!

[tugbakara]

Finally, we decided that issue comes from CPU overload, without using rtapmap fps is nice, if there will be any other inference, we can provide. But if you have any suggestion related CPU issue I am willing to listen, and other problem happened related to that issue I will reopen issue, thanks .
Have a nice day :)

[MartyG-RealSense]

On Jetson boards, CPU percentage usage will be reduced for color conversion, pointcloud and depth-color alignment operations if the CUDA support of the librealsense SDK is enabled.

If librealsense is installed from packages or from source code using the Jetson-specific instruction at the link below then CUDA support will be included. The Jetson packages include CUDA support automatically, whilst for a source code build with CMake it can be enabled by including -DFORCE_RSUSB_BACKEND=true in the CMake build instruction.

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

Once librealsense has been confirmed as working successfully then the RealSense ROS wrapper can be built from source code afterwards with 'Method 2'.

[tugbakara]

Hi @MartyG-RealSense I reinstalled SDK with -DFORCE_RSUSB_BACKEND=true by using source installation but with this flag realsense hust gave this issue. That's why I installed back to SDK without this flag.
Have a nice day!

[tugbakara]

Hi @MartyG-RealSense again! :) To be sure about instructions I followed 4th step of jetson installation. That means I have default CUDA support right? As you mentioned here I don't see any reduce in CPU usage, that's why come and ask again. If installation has CUDA support, then I suppose I need to reinstall all depended libs with CUDA support now I don't have PCL, OpenCV and many other with CUDA support.

[MartyG-RealSense]

If you install the librealsense SDK from packages using the Jetson installation instructions then CUDA support is included, as confirmed by a RealSense team member at IntelRealSense/librealsense#10911 (comment)

The SDK's CUDA support is only applied to RGB color conversion, depth to color alignment and pointcloud generation. Types of processing other than these three will not be assisted by CUDA and will be processed on the CPU. It will not provide CUDA support for non-SDK tools such as PCL and OpenCV.

You do not need to install any additional software in order for CUDA support to work. It will be applied automatically if color conversion, depth to color alignment or pointclouds are being processed.

[MartyG-RealSense]

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

[tugbakara]

No thanks Marty! Sorry for the late response.

[MartyG-RealSense]

No problem at all, @tugbakara - thanks very much for the update!