Handling USB problem when reading frames using Realsense API
I have a C++ application running on the Jetson Nano that uses three D455 cameras. The Nano has 4 USB ports but they are all on a single USB controller. Sometimes while the app is running, at least one port shuts down due to overcurrent, at which time all 3 cameras stop updating and my application just hangs. It does not terminate with an exception even though I have logic to look for polling taking more than 2 seconds and generate an exception. If I use the Realsense Viewer to turn on all 3 cameras via the Nano instead, using the same frame rates and resolutions as my application, and if I manually load down one of the USB ports to overcurrent as it does in my app, only the camera on the one port I overloaded stops communicating. The other two cameras continue to operate. I am updating frames in my app using the Intel API function "poll_for_frames()". What does the Realsense Vewer use to update frames, and how does it avoid all 3 cameras from dropping out when one port shuts down?
Hi Jsaunders In program scripts that use multicam code, multiple cameras can each be assigned to their own individual pipeline. It can automatically build a list of all attached cameras when the program is launched and auto-retrieve their unique serial numbers. When a camera is unplugged or disconnected, only the pipeline associated with that particular camera is affected.
The RealSense SDK C++ example program rs-multicam.cpp demonstrates these principles.
When rs-multicam is launched with more than one camera, multiple stream panels from all attached cameras are displayed. When a particular camera is disconnected, the stream panels associated with it freeze whilst the panels of the other cameras continue streaming.
At the link below an Intel RealSense team member provides detailed advice about how multicam in the RealSense Viewer works.
Hi MartyG Thank you for your response. I used the rs-multicam demo several months ago to get my application working initially. Only as I add more features and start taxing the hardware (Jetson Nano) does it appear that I have a problem with the USB controller. I know the Nano USB is power limited, and that a separate powered USB hub added to it would take care of my problem. The part I am not understanding is why the entire Nano seems to hang.
I will read through the rs-multicam code example again to ensure I didn't skip something in my app, but since it works most of the time I think I must be generally doing things correctly. Also, as a test I just unplugged one camera while my app was runnig. In that case the app terminates with an exception that I purposely generate, but does not hang. So my problem seems to be tied to the USB controller somehow getting locked up rather than losing communication to a single camera.
Intel strongly recommend for Jetson Nano specifically if your model of Nano has a barrel jack power connector then it is enabled using the instructions at the link below.
Please sign in to leave a comment.