Throwing an error of "rs2::invalid_value_error" when using D455

[AMLIFY]

• Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

  • Consider checking out SDK examples.
  • Have you looked in our documentations?
  • Is you question a frequently asked one?
  • Try searching our GitHub Issues (open and closed) for a similar issue.

• All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

---

Required Info
Camera Model	D435i/D455
Firmware Version	(Open RealSense Viewer --> Click info)
Operating System & Version	Ubuntu 22
Kernel Version (Linux Only)	Linux 5.15.148-tegra
Platform	NVIDIA Jetson Orin NX Engineering Reference Developer Kit
SDK Version	2.55.1
Language	{C++}
Segment	{SLAM }

Issue Description

Recently I'm depolying ORB_SLAM3 on the Jetson developer kit, and I tested the codes seperately with Intel RealSense D435i and D455(with their specific intrinsics). The program ran succesfully with D435i. However, it faced some errors when using D455.:

terminate called after throwing an instance of 'rs2::invalid_value_error'
  what():  get_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable

And I found that the error would appear when running the codes below:
get_sensor_option(sensor);
and:
rs2_intrinsics intrinsics_cam = cam_stream.as<rs2::video_stream_profile>().get_intrinsics();
I'm wondering why the same API can't work with D455, and I didn't find similar problem in the previous issues. Thanks in advance!

[MartyG-RealSense]

Hi @AMLIFY Do you have access to the RealSense Viewer tool, please? If you do then please try using the instructions at #10182 (comment) to reset the camera's calibration to its factory-new settings to see whether it resolves your problem.

[AMLIFY]

Hi @AMLIFY Do you have access to the RealSense Viewer tool, please? If you do then please try using the instructions at #10182 (comment) to reset the camera's calibration to its factory-new settings to see whether it resolves your problem.

Thanks for your resolution. I've got the RealSense Viewer tool, and I'll try to recalibrate it. I'll update soon.

[AMLIFY]

Hi @AMLIFY Do you have access to the RealSense Viewer tool, please? If you do then please try using the instructions at #10182 (comment) to reset the camera's calibration to its factory-new settings to see whether it resolves your problem.

Hello, I tried the resolution you mentioned, and the same error appeared

[AMLIFY]

Hi, my colleague used another D455 to run the same code, and it went well without throwing the error I mentioned. Both of our devices are brand new, so is it the problem of my specific device?

[MartyG-RealSense]

Does it make a difference if you unplug the micro-sized end of the USB cable from the base of your D455, turn the connector around the other way and re-insert it? Sometimes the camera will work better when the micro-sized connector is inserted in one particular orientation of the two insertion directions available.

Do you have access to your colleague's D455? If so, have you tried swapping their USB cables to test whether the problem is with your camera's USB cable?

[AMLIFY]

Does it make a difference if you unplug the micro-sized end of the USB cable from the base of your D455, turn the connector around the other way and re-insert it? Sometimes the camera will work better when the micro-sized connector is inserted in one particular orientation of the two insertion directions available.

Do you have access to your colleague's D455? If so, have you tried swapping their USB cables to test whether the problem is with your camera's USB cable?

Hi @MartyG-RealSense I've tried different USB cable and both side of the connect inserted, and it turned out to be no improvement, so I think it has nothing to do with the USB cable. But it confused me that the camera worked well in realsense-viewer, and the image and depth topic published via ros2 can be successfully subscribed and visualized in rviz2. As an implement, I 'm using Jetpack 6.1 installed by another colleague, and the colleague who successfully ran the code is using Jetpack 6,0. Would this caused the different performance?

[MartyG-RealSense]

The JetPack 6 support is for JetPack 6.0 specifically. When support for new JetPack versions is added, it is for exact L4T versions rather than JetPack 4, 5, 6 etc in general.

A RealSense user recently commented though that their Nvidia SDK Manager was no longer offering JP 6.0 though, just 6.1.

Is your colleague using librealsense 2.55.1 or a newer version such as 2.56.1

[AMLIFY]

The JetPack 6 support is for JetPack 6.0 specifically. When support for new JetPack versions is added, it is for exact L4T versions rather than JetPack 4, 5, 6 etc in general.

A RealSense user recently commented though that their Nvidia SDK Manager was no longer offering JP 6.0 though, just 6.1.

Is your colleague using librealsense 2.55.1 or a newer version such as 2.56.1

Thanks for your patient reply. He is using a newer version.

[MartyG-RealSense]

I note that realsense-viewer and ROS2 are working well on your Jetson with 2.55.1, which suggests that it is mostly working okay with your JetPack 6.1 and older librealsense version than your colleague aside from the mentioned errors.

Did your colleague run the code on your Jetson or their own one? If your colleague's D455 works well with ORB_SLAM3 on your Jetson and your D435i works well with it too then it would suggest that the issue is with that one particular D455 rather than a software problem.

[AMLIFY]

I note that realsense-viewer and ROS2 are working well on your Jetson with 2.55.1, which suggests that it is mostly working okay with your JetPack 6.1 and older librealsense version than your colleague aside from the mentioned errors.

Did your colleague run the code on your Jetson or their own one? If your colleague's D455 works well with ORB_SLAM3 on your Jetson and your D435i works well with it too then it would suggest that the issue is with that one particular D455 rather than a software problem.

Thanks for your reply! I tried two other D455 cameras on my Jetson, and they both ran well, so I think it was the problem of my particular D455.

[AMLIFY]

I note that realsense-viewer and ROS2 are working well on your Jetson with 2.55.1, which suggests that it is mostly working okay with your JetPack 6.1 and older librealsense version than your colleague aside from the mentioned errors.
Did your colleague run the code on your Jetson or their own one? If your colleague's D455 works well with ORB_SLAM3 on your Jetson and your D435i works well with it too then it would suggest that the issue is with that one particular D455 rather than a software problem.

Thanks for your reply! I tried two other D455 cameras on my Jetson, and they both ran well, so I think it was the problem of my particular D455.

Another update: I could use D435i to run ORB_SLAM3 successfully a week ago, but now it would stuck on the "Waiting for images" window and failed to continue. I tried to use the identical D435i on my colleague's Jetson. However, the "rs2::invalid_value_error" was thrown(as the same as the D455 issue on my Jetson). It was very confusing because none of my devices could work ;(

[MartyG-RealSense]

It sounds as though the common cause of all of your problems is that the cameras stop delivering new frames, causing messages such as "waiting for images" and "Resource temporarily unavailable".

[AMLIFY]

It sounds as though the common cause of all of your problems is that the cameras stop delivering new frames, causing messages such as "waiting for images" and "Resource temporarily unavailable".

Exactly. But when I checked it with realsense-viwer or rviz2, it could work and publish color and depth stream.

[MartyG-RealSense]

If the cameras function correctly in all applications except when you use your C++ code, it could suggest that there is an issue in the C++ code that can cause instability of frame delivery.

A way to check your code's stability would be to run the program and then immediately use an Ubuntu system monitoring tool such as htop to monitor CPU % usage (how much processing load is placed on the CPU) and the available free computer memory. If the free memory capacity quickly declines over time then it would indicate that the code has a memory leak, which progressively reduces memory until instability and possibly a freeze or crash of the code occurs.

[AMLIFY]

If the cameras function correctly in all applications except when you use your C++ code, it could suggest that there is an issue in the C++ code that can cause instability of frame delivery.

A way to check your code's stability would be to run the program and then immediately use an Ubuntu system monitoring tool such as htop to monitor CPU % usage (how much processing load is placed on the CPU) and the available free computer memory. If the free memory capacity quickly declines over time then it would indicate that the code has a memory leak, which progressively reduces memory until instability and possibly a freeze or crash of the code occurs.

Thank you for the rapid and detailed reply! I'm using the original ORB_SLAM3 code, and I can only figure out that the error is thrown by the encapsulated function in realsense SDK. I will check the memory status tomorrow working hour :)

[AMLIFY]

I used htop to check the CPU and memory capacity when running the code with D435i(stuck on "waiting for images" window), and the CPU % usage and memory capacity almost stayed still.

[MartyG-RealSense]

When frame delivery stops, does it start if you unplug the camera from the USB port and plug it straight in again? If the camera is disconnected after the pipeline has been started then it should resume streaming without having to use the pipeline start() instruction again if reconnection occurs within 5 seconds.

If a quick unplug-replug does make a difference then you could try automatically resetting the camera when the C++ script is run by using the hardware_reset() instruction.

rs2::context ctx;
rs2::device dev = ctx.query_devices().front();
dev.hardware_reset();
rs2::device_hub hub(ctx);
dev = hub.wait_for_device();

[AMLIFY]

When frame delivery stops, does it start if you unplug the camera from the USB port and plug it straight in again? If the camera is disconnected after the pipeline has been started then it should resume streaming without having to use the pipeline start() instruction again if reconnection occurs within 5 seconds.

If a quick unplug-replug does make a difference then you could try automatically resetting the camera when the C++ script is run by using the hardware_reset() instruction.

rs2::context ctx;
rs2::device dev = ctx.query_devices().front();
dev.hardware_reset();
rs2::device_hub hub(ctx);
dev = hub.wait_for_device();

Thanks for your advice. I tried it with D435i, and the unplug-replug didn't make a difference. The red light in the lens kept glittering when running the code, and stopped flashing after I unplugged and replugged it within 5 seconds.

[MartyG-RealSense]

Researching the ORB_SLAM3 "Waiting for images" aspect of this case, some who had experienced the same problem (realsense-viewer works, ORB_SLAM3 does not) suggested moving the camera around in case the scene being observed by the camera had insufficient detail in it to correctly initialize the camera. Use of the resolution 640x480 in the RealSense ROS wrapper launch was also suggested if 640x480 is not already being used.

UZ-SLAMLab/ORB_SLAM3#511
UZ-SLAMLab/ORB_SLAM3#757

[AMLIFY]

Researching the ORB_SLAM3 "Waiting for images" aspect of this case, some who had experienced the same problem (realsense-viewer works, ORB_SLAM3 does not) suggested moving the camera around in case the scene being observed by the camera had insufficient detail in it to correctly initialize the camera. Use of the resolution 640x480 in the RealSense ROS wrapper launch was also suggested if 640x480 is not already being used.

UZ-SLAMLab/ORB_SLAM3#511 UZ-SLAMLab/ORB_SLAM3#757

Thank you for searching resolution in the ORB_SLAM3 issue. Actually I have checked the similar issue in the original program, but none of them helps. And my D435i could run the code before 2nd Jan., so I think the problem is more likely to associate with the device? And my colleague's D435i was able to test the code on my Jetson. Now I'm trying to write ros2 node to make use of my D435i stream, avoiding directly calling the API in realsense SDK.

[MartyG-RealSense]

Okay, thank you very much for the information. I look forward to hearing the outcome of your ROS2 node script.

[AMLIFY]

I wrote a ros2 wrapper script for another SLAM project, and I tested with the cameras, D455 and D435i, which could not work properly with the API in SDK. It turned out to be successful when I used the publisher-subscriber system of ros2 to get the image and depth stream. So for the time being I will leverage the cameras this way. Thanks for your information!

[MartyG-RealSense]

You are very welcome, @AMLIFY - it's excellent news that your scripting was successful. Thanks very much for the update!

[MartyG-RealSense]

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