Going to LogiMat 2025? Meet Us There.
At Nomagic, we work extensively with RealSense D400 series cameras (primarily the D415). These cameras are popular due to their ability to provide RGB and depth input at a reasonable cost — tens of times cheaper than industrial depth cameras. As a stereo vision camera with a static pattern, the D415 allows multiple cameras to operate simultaneously without interference. While the depth quality could ideally be better (on the other hand, the RealSense computes depth in real-time at high frame rates), the main issue we encountered was the cameras intermittently refusing to work. These problems were often exacerbated by the complexity of our vision system, which involves multiple cameras connected to the system at once. Here, we share some effective ways to address these issues.
Often, after the ROS node process for the camera terminated, the camera would fail to run the next time we attempted to use it. Occasionally, the camera would also stop working during execution. In such cases, we encountered error messages related to I/O or protocol errors, or the camera would simply disappear from rs-enumerate-devices and lsusb. Replugging the camera usually resolved the issue (though in one instance we had to reboot the computer, as described below). We used powered hubs, and replugging the cable between the camera and the hub was always a reliable fix. Replugging the cable between the hub and the PC, however, only worked in some cases. This suggests there are at least two different types of problems at play — see the next section for more details.
In one experiment, we connected four cameras to a system and restarted their ROS nodes 6,631 times consecutively. We observed 45 cases where one of the four cameras failed to reappear (approximately 1%). Details of this issue can be found in this bug report, though results can vary significantly — on some days the cameras performed much better, while on others they performed worse.
Since unplugging cameras remotely isn’t feasible, we employ two additional tricks:
While these workarounds help in the short term, they are not suitable for production environments. Therefore, we sought more robust solutions.
The default 5.8.15 firmware that ships with the cameras tends to cause problems with intermittent failures. Upgrading to the 5.9.x series resolves many of these issues, with the 5.10.x series offering even greater stability.
Occasionally, a camera will connect in USB2 mode (even when plugged into a USB3 port), resulting in significantly reduced functionality. For example, capturing both depth and infrared images or achieving higher resolutions and frame rates becomes impossible. To verify the connection type, run lsusb -t. Each camera should appear as four entries with a speed of 5000M. If you see only three entries at 480M, replugging the camera is necessary.
As detailed in this document, RealSense cameras consume a significant portion of the USB3 theoretical bandwidth of 5000Mbps (with real bandwidth typically around 3200–3600Mbps). Connecting too many cameras to a single USB port via hubs can cause failures due to bandwidth limitations. Even with separate USB ports, many motherboards have only one or two internal USB hubs, meaning ports may share the same 5000Mbps bandwidth. The lsusb -t command can reveal how many hubs are in use (look for lines marked 5000M).
To increase bandwidth:
Resetting the camera before use proved highly effective, particularly with older firmware versions. Many issues were resolved by programmatically resetting the camera, as demonstrated in this commit. Adding such code to the camera startup process greatly reduced cases of failure to initialise.
Resetting or unplugging cameras can expose a bug in some Linux kernels, including the version used in Ubuntu 16.04 LTS. As described in this report, certain kernel versions leak /dev/media* devices upon disconnection. Once all 255 devices are used, RealSense cameras stop functioning.
Symptoms include:
lsusb -t showing Driver= instead of Driver=uvcvideo.ls /dev/media* showing 255 entries.The only workaround is a system reboot, though upgrading to a kernel version unaffected by this bug (e.g., 4.18 or later) is preferable.
If your depth stream starts appearing distorted, it may indicate corrupted depth calibration data. The “Dynamic Calibration Tool” can restore calibration data using Intel.Realsense.CustomRW -g, followed by running the calibration procedure.
Some problems stem from faulty cables, particularly when the camera is mounted on a moving robotic arm. Symptoms include a specific camera failing more frequently over time until it ceases functioning entirely. Replacing the cable usually resolves this. While we don’t yet have a reliable method for detecting failing cables, counting incomplete frames or using the GetPortErrorCount command (introduced in USB 3.1) could help.
Note: USB3’s theoretical bandwidth of 5000Mbps can interfere with 2.5GHz radio equipment. For example, we had a wireless keyboard stop working when plugged in near a RealSense camera. Shielded USB cables or avoiding such devices nearby may mitigate this issue.
Many of the tricks described here were discovered through interactions with Intel RealSense Support, for which we are grateful. You can open tickets there and expect a prompt response.
Mikołaj Zalewski
Przemysław Walczyk
Get in touch with Nomagic to see how our innovative technology can take your fulfillment processes to the next level.