I am observing a few issues with the D435, and ROS wrapper.
When I run: "roslaunch realsense2_camera rs_camera.launch"
- I am seeing the following error printed every second or so:
- (backend-hid.cpp:1091) Failed to read busnum/devnum. Device Path: /sys/bus/iio/devices/iio:device0
- I am seeing that the function RS435Node::callback which configures the sensor at ROS node startup sometimes does not always completely configure the sensor. It errors out at times and leaves the configurations with higher indexes unset. I suspect this is related to issue 1.
The node appears to otherwise work normally.
I am using:
Camera firmware 18.104.22.168 (also tried with 5.9.9)
librealsense: 2.11.1 (also tried with 2.10.3)
ROS realsense wrapper: 2.0.3
The same issue does not appear when running the D435 from my laptop rather than the Up Board.
Any suggestions of what to try to alleviate those two issues?
A number of other people have experienced the busnum/devnum error with the 400 Series camera and Up Board. As unplugging and replugging the camera apparently sometimes clears the problem, there are indications that it may be related to the problem of the camera running in USB 2.0 mode (USB2) instead of the full USB 3.0 mode.
On desktop and laptop computers, if the camera is inserted into the USB port slowly then it has been prone to being read as a limited-functioning USB 2 device. The fix for this was to insert the camera into the USB port quickly and firmly. This would be harder to to on an Up Board, since its USB 3.0 OTG port is more awkward than a PC's port.
Intel are very aware of the USB2 issues and are working on providing a firmware fix for them, though the problem is still open in the current firmware. If you read the firmware release notes (below) and do a search for 'usb2' on the browser page to highlight all references to USB2, you can find out more about how the issue affects the camera.
You might be able to unplug-replug the camera more safely if you remove and re-insert the USB cable at the end where it plugs into the side of the camera instead of unplugging it from the OTG port.
I saw some references when searching about this issue related to the camera enumerating as USB 2.0 rather than USB 3.0. My perception was that in those cases the output of rs-eumerate-devices would indicate that USB 2.0 was detected while in my case I see the following output:
Name : Intel RealSense D435
Serial Number : 745412071413
Firmware Version : 05.09.11.00
Recommended Firmware Version : 05.09.09.02
Physical Port : /sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/video4linux/video0
Debug Op Code : 15
Advanced Mode : YES
Product Id : 0B07
Usb Type Descriptor : 3.1
My observation has been that no amount of unplugging / reconnecting the camera fixes the issue.
Another factor that can cause erratic performance on Up Board is the choice of USB 3.0 OTG cable / adapter. In Intel's Robotics Development Kit (a bundle deal of a RealSense R200 camera and Up Board), there was an adapter validated to work with the camera. Did you supply your own adapter when you purchased the Up Board separately from your D435, or was there one provided with the Up Board?
If you supplied your own OTG adapter, not all OTG connectors are equal apparently, just like USB port stability can vary between different models of PC. Up supply their own recommended OTG cable in their official online store.
I'm sorry that you are still having problems despite the new cable. Research indicates that a few other people have had this busnum/devnum issue with the 400 Series and Up Board. One person got the official Up OTG cable like you did and although it worked at first, their camera reverted to USB2 mode when they installed Librealsense.
Unfortunately, nobody on the RealSense or Librealsense forums has been able to find a solution yet, as far as I can tell. It is possible that the situation may improve when Intel manage to fix the 'camera detected as USB2' issue, which is on their to-do list for a future firmware update.
Hello Philipcase and Marty,
I had a customer asking and reporting about the same issue while using a D435 and an UP board with the OTG port.
After investigating the board and the USB OTG port I was able to find that the D400 cameras need a fully powered USB 3.0 port to work flawlessly. The USB OTG port does have the bandwidth for the camera to work (the same bandwidth as a USB 3.0 port) but the power it provides is lower than a fully powered USB 3.0 port.
This is the reason why the issue is only in the UP Board and in your laptop there is no issue, because your laptop does have a fully powered USB 3.0 port. Also this is the reason why the camera does not have an OTG port as other RealSense cameras. We always recommend to use the USB cable that comes with the camera.
Hope this helps to clarify your question.
To anyone experiencing the same problem, I also had this issue. The support agent, MartyG, replied in a github issues thread this solution. I tried it, aka checked out the most recent supported branch of realsense-ros,
and everything worked. I would recommend you try it. I copy and pasted it here for your convenience.
It is recommended that the RealSense ROS wrapper is matched with a particular version of the Librealsense SDK where possible. On the 'Releases' page for the wrapper, each version lists a recommended Librealsense SDK version to use it with.
It is sometimes possible to 'mix and match' non-recommended combinations of wrapper and SDK, but in general the best way to make a good match between wrapper and SDK is to follow the recommended SDK for a particular wrapper version.
In regard to stability, the RealSense SDK aims to run on anything and is extremely adaptable in regard to the hardware and software that it can be used with. There are sometimes hardware and / or software configurations that require a bit more work to achieve a stable RealSense setup on though. These cases are usually mostly resolved over time as the RealSense community, the RealSense team or both develop guides and code solutions to overcome problems.
It is also worth bearing in mind that the ROS wrapper and Librealsense are not developed in sync, so there may be a delay between the release of a new Librealsense version and a ROS wrapper version that officially supports it (though the ROS wrapper for the previous Librealsense version may still work with the newer Librealsense release).