Deb package installs the temporary uEye drivers

[progtologist]

In DownloadUEyeDriversUnofficial.cmake you warn:

message(WARNING "The official IDS uEye drivers were not detected on your machine. A temporary version of the header/library will be downloaded locally to your ROS buildspace, to ensure that this package compiles. Nevertheless, you (or a system administrator) MUST still download and install the official IDS uEye drivers (http://en.ids-imaging.com/download-ueye.html). Also make sure that the IDS daemon (/etc/init.d/ueyeusbdrc) is running.")

but at the same time in CMakeLists.txt you are

if(USE_UNOFFICIAL_UEYE_DRIVERS)
  get_filename_component(UNOFFICIAL_UEYE_DRIVERS_LIB_REALPATH ${UEYE_LIBRARY} REALPATH)
  install(FILES ${UEYE_LIBRARY} ${UNOFFICIAL_UEYE_DRIVERS_LIB_REALPATH}
    DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION})
endif()

which results in the debian package including the temporary drivers that were only dowloaded for compiling. This causes error in environments were a newer version of the drivers is installed (or required) and the user has the debian package of the ueye_cam driver installed.

[anqixu]

If I understand correctly, you are referring to a scenario where:

1. install latest version of IDS drivers
2. install debian package of ueye_cam
3. error

Please confirm if this ordering is correct, and also specify more details regarding this error (e.g. apt/dpkg failed to install ueye_cam, or ueye_cam nodelet fails to run, or another process using uEye drivers fails to run, or something else). Furthermore, attach all relevant printouts.

(Also, I suppose it won't hurt to try inversing steps 1 and 2, and see if that solves the problem.)

As for a fix, a temporary stopgap would be to re-package the latest versions of the IDS driver, and update DownloadUEyeDriversUnofficial.cmake. I'm not sure how to fix this issue permanently (since ROS buildfarm needs the temporary drivers, and I don't know/think bloom has an option for conditional install / post-install script).

[progtologist]

To reproduce:

1. Install latest IDS Drivers, in my case uEye_4.62_Linux_64.tgz
2. Start the daemon
3. Start the idscameramanager (without sudo - everything works correctly)
4. Quit the manager and install the ueye_cam package through debian (sudo apt-get install ros-DISTRO-ueye-cam)
5. source /opt/ros/DISTRO/setup.*sh (bash/zsh/sh)
6. Start the idscameramanager (again without sudo - fails)

IDS Camera Manager V1.9.1 don't work with
libueye_api < 4.60!
use a newer libueye!

1. Remove ueye_cam (sudo apt-get remove ros-DISTRO-ueye-cam)
2. Run idscameramanager (without sudo - everything works)

As a suggested fix, remove the install directives for the UNOFFICIAL_UEYE_DRIVERS so as they will not be a part of the debian package. They will be compiled and linked against, but they will not be installed.

[anqixu]

I had considered your suggestion of not installing the unofficial drivers, but then people that had not installed the IDS drivers would see a generic "no shared library found" error when trying to run the ueye_cam nodelet, without instructions on how to download the official drivers...

Would you consider re-installing the latest IDS drivers, after installing ros-DISTRO-ueye-cam? I suspect that this would overwrite the ones included in the ueye_cam package.

(Note that historically, I was requested to package up ueye_cam because some users wished to batch-install via automated scripts, when configuring new robots.)

[progtologist]

The problem is not in overwriting, it's with dynamic linking. In a system where both the official and the unofficial driver are installed, two versions of the same library exist:

locate libueye_api.so
/opt/ros/DISTRO/lib/libueye_api.so
/usr/lib/libueye_api.so

The /opt/ros/... version is the library install by your package, while the other version is installed by the IDS driver. The executable upon runtime will try to link with the library that is first found in the LD_LIBRARY_PATH, which in the case of ROS, the ROS libraries are prioritized as shown here

echo $LD_LIBRARY_PATH 
/opt/ros/DISTRO/lib:/opt/ros/DISTRO/lib/x86_64-linux-gnu:/usr/lib32:/opt/ros/DISTRO/lib/python2.7/dist-packages

I believe that the solutions that can be applied are:

1. Distribute the package without any library and let the user install the drivers manually
2. Update (and keep updating) the UNOFFICIAL library (perhaps rename it to OFFICIAL?) and remove in the wiki page that the drivers are necessary (since they are not as they are included)
3. Try to convince uEye to create debian packages for their driver, then add a dependency on that package on your package.xml and CMakeLists.txt (doubt this will happen any time soon).

Overall your work is exceptional, thank you for all your effort!

[anqixu]

Ah I misread where CATKIN_PACKAGE_LIB_DESTINATION was linked -- I thought it was linked to /usr/lib, but given that it's not, clearly there won't be any overwriting possibilities.

I am still convinced that it is better to have ueye_cam guaranteed to run when apt-installed on any machine, at the cost of masking a newer version of the lib.

As a temporary fix, I will re-package .h/.so for v4.61 and upload those to the ros servers. In the mean time, please consider either removing libueye_api.so* and ueye.h* from /opt/ros/DISTRO/lib, or building ueye_cam from source.

P.S.:

1. the install of the libraries is makred UNOFFICIAL because it was repackaged with a bare minimum setup (e.g. .h and .so only)
2. I had sent a very lengthy email to IDS Imaging last fall, persuading them to consider releasing their drivers as debian packages. I got a late response from a support personnel, who said he will look into the matter, but I had not heard back from IDS, despite numerous pings.
3. Thank you for the koodos :smile:

[progtologist]

Just a final note - suggestion. I would agree 100% on your suggestion on keeping the library in the deb, if and only if the package would work without installing the ueye drivers. But since the package will not work unless the user has launched the daemon - and therefore installed the official library. Therefore, I still believe that there is no reason to provide the library in the ros-debian package. P.S.: I have used the source package version as soon as I have discovered the "bug".

[anqixu]

You do raise a good point -- installing ueye_cam without the underlying IDS drivers will allow the nodelet to (start to) execute properly, but will not be able to connect to any uEye cameras, given that the daemon is not present. On the other hand, not including the barebone version of the .so will cause the nodelet to fail to execute:

[ERROR] [1439772259.508635678]: Failed to load nodelet [/ueye_cam_nodelet] of type [ueye_cam/ueye_cam_nodelet]: Failed to load library /PATH/libueye_cam_nodelet.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library (Poco exception = libueye_api.so: cannot open shared object file: No such file or directory)

I wish that there's a way to warn the user in this case to install the IDS drivers...

In the mean time, I will remove the barebone IDS .h/.so from the debian package. Cheers :smile:

[progtologist]

There is a way, I will make a pull request with a proposed fix ;-) EDIT: Unfortunately you were right, there is no way of intercepting that exception, as it is thrown in the nodelet manager instance prior to the construction of the nodelet and the driver. I tested pretty much everything without any luck. :( Still, I made some cleanup on the code, so I will make a PR if you wish to integrate them, nothing major though.

[anqixu]

No worries. We'll deal with the fallout if and when it comes. In the mean time I've updated the barebones lib to 4.61, and pushed it to the buildfarms. Cheers.

[130s]

Has anyone thought of/tried subscribing rosconsole topics? http://answers.ros.org/question/33503/subscribing-to-rosout-info/

[ERROR] [1439772259.508635678]: Failed to load no...

This should be catch-able using rosconsole/rosout API.

[anqixu]

Seems like some work would be involved in running a daemon to check for this message on launch + give a more sensible warning message. I welcome pull request, but personally I'm happy with the current setup until IDS releases debs for their drivers.