udev rules should be bundled with ROS packages

[jarvisschultz]

On recent versions of the ROS packages there is a permissions issue when trying to run a camera. Running rs_rgbd.launch yields the following on both D415 and D435 on several different computers I've tried this on.

[1601676569.414524888] [/camera/realsense2_camera_manager] [ INFO]: Initializing nodelet with 12 worker threads.
[1601676569.479091193] [/camera/realsense2_camera_manager] [ INFO]: RealSense ROS v2.2.17
[1601676569.479112766] [/camera/realsense2_camera_manager] [ INFO]: Built with LibRealSense v2.38.1
[1601676569.479121777] [/camera/realsense2_camera_manager] [ INFO]: Running with LibRealSense v2.38.1
[1601676569.492100248] [/camera/realsense2_camera_manager] [ INFO]:
 02/10 16:09:29,498 ERROR [140538484209408] (handle-libusb.h:51) failed to open usb interface: 0, error: RS2_USB_STATUS_ACCESS
 02/10 16:09:29,499 WARNING [140538509387520] (rs.cpp:304) null pointer passed for argument "device"
[1601676569.499149454] [/camera/realsense2_camera_manager] [ WARN]: Device 1/1 failed with exception: failed to set power state
[1601676569.499166072] [/camera/realsense2_camera_manager] [ERROR]: The requested device with  is NOT found. Will Try again.

This exact issue was also reported in #1408 and #1228. In both of those cases, it was mentioned to download the udev rules and place into /etc/udev/rules.d/. While that is a workaround, it doesn't seem like the right solution. It would seem to me that bundling the udev rules with either ros-kinetic-realsense2-camera or ros-kinetic-librealsense2 would be much more appropriate. Alternatively, the librealsense2-udev-rules package could also be released as a ROS package and listed as a dependency of one of the above packages.

I can also confirm that installing librealsense2-udev-rules from http://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo also fixes the issue.

[MartyG-RealSense]

Hi @jarvisschultz Thanks very much for your feedback. I emphasise first that I am not a RealSense ROS wrapper developer and the developer viewpoint may be different. This is how I view the situation though ...

I can foresee the possibility of the multiple udev rules warning occurring if the udev rules were installed automatically as part of the ROS wrapper installation process. Whilst the Manual (source code) librealsense installation process places the udev rules in the etc folder, the package method of installaing librealsense places the rules in the /lib/udev/ folder.

So if a RealSense user had installed librealsense with the package method for example and then the ROS wrapper install process installed the udev rules to the etc folder then you would potentially end up with a rules conflict and the multiple udev rules warning.

It is therefore likely a better solution to make the manual udev installation workaround more visible (perhaps a paragraph in the documentation) rather than install the rules for all ROS wrapper users and risk numerous occurrences of conflicts to solve a problem that affects a small number of users.

More information about the conflicts caused by udev rules in two different locations is in the link below.

IntelRealSense/librealsense#6153 (comment)

[jarvisschultz]

Better documentation could definitely help this confusion, but I still think there are flaws with the reasoning. To me it seems the ROS package ros-<version>-realsense2-camera provides a compiled version of the ROS driver, and it always has a dependency on ros-<version>-librealsense2. From my reading, the version of librealsense2 provided by the ROS package has been compiled to use the RS-USB backend to be more compatible across various kernel versions where ROS users might be trying to utilize a RealSense. From standard behaviors of Debian packaging, I think there's a pretty reasonable expectation from users that if they use a package management tool like apt to install a package (e.g. ros-kinetic-realsense2-camera), and that tool is able to successfully download and install all required dependencies, then the package they were trying to install should work. Manual workaround steps seem like a packaging problem.

The multiple udev rules problem seems like an imaginary issue -- mostly caused because the realsense-viewer is programmed to complain about it. The udev rules files have a well-defined priority that could be leveraged in this case. In your example of installing librealsense with the package method, and then installing the ROS wrapper, the conflict only exists because the packages providing the udev rules were explicitly defined to install udev files to both /lib/udev/rules.d and /etc/udev/rules.d which causes realsense-viewer to complain.

I'm no debian packaging expert, but I do think that requiring manual steps feels very out of the ordinary. Here are a couple of thoughts on how one could solve this issue:

• In my original post, I suggested also releasing the udev package to the ROS buildfarm, then users of only the ROS packages would be able to get the dependency without requiring the http://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo package source. I would think Debian control file would be enough to allow apt to decide if users with both the ROS package sources and the realsense AWS package sources already had a proper version of the udev package installed.
• The udev rules for the ROS package could be handled with a postinst script (if valid rules don't exist, add them).
• It's not clear to me that the realsense-viewer warnings are actually a problem. Even though they are printed, I'm guessing this is just information to help users diagnose problems with their setup. The udev priority is still defining which rules take effect. Could the ROS package just install lower priority rules? Could the viewer warnings be updated to provide more context about how udev files get installed and how multiple versions could be a problem?

[MartyG-RealSense]

Thanks so much @jarvisschultz for your very detailed feedback about your viewpoint that the ROS wrapper should install the udev rules during its installation. As I am not a RealSense developer, I will refer your feedback first to @doronhi the RealSense ROS wrapper developer by tagging him to this discussion.

[MartyG-RealSense]

Reminder please to @doronhi to look at the suggestion of @jarvisschultz above about installing udev rules with the ROS wrapper. Thanks!

[MartyG-RealSense]

Reminder @doronhi please to look at the suggestion of @jarvisschultz above about installing udev rules with the ROS wrapper. Thanks!

[doronhi]

Thank you @jarvisschultz for your insight and @MartyG-RealSense for your persistent reminders. I think this is a good idea and will make sure to create a matching udev-rules debian package for the ROS installation.
This issue may remain open until such time.

[MartyG-RealSense]

Okay, thank you very much @doronhi - I will keep this case open.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Adding a note to keep this case open for a further time period.

[MartyG-RealSense]

Hi @doronhi Does this case, which acts as a reminder about the idea of creating a matching udev-rules debian package for the ROS installation, still need to be kept open please? Thanks!

[MartyG-RealSense]

Case closed due to no comments received since October 2020.