If you have problems with ROS picking up the wrong openCV libs

Thought I’d found the cause of this problem but either I was wrong or there is more than one way to get things pointing at the wrong libs. If you install ROS and try to build something in it that requires OpenCV and it balks asking for opencv libs in the /usr/lib/arm-blah blah directory its pointing to the wrong place trying to use OpenCV instead of OpenCV4Tegra. Traced it to two packages in ROS cv_bridge and image_transport. If you install from source you can get around this easily. Grab cv_bridge and image_transport python packages from github and install them with the usual python setup.py install command. Then once you have built your rosinstall file edit that and delete the two sections relating to those two packages so it won’t try and build them again. For some reason if you let ROS build them during a binary install or source install they will want the standard OpenCV libs notably libopencv-ocl.so. Which is a lib for OpenCL which isn’t supported at all on the Jetsons. If you see that its trying to compile from the std OpenCV libs instead of the nvidia massaged version. I’m still beating around on it because I want to know exactly why it happens. And I’ve seen it happen under two different sets of circumstances. I’ve been told that you should be able to run the nvidia opencv version now with the sift and surf modules without going through any crazy gyrations. Which will give you the best performance and take advantage of the hardware to the fullest. Kinda looking like it might be the cmake-cache getting bashed. Not that familiar with cmake yet. Last time I was fooling around with this kind of stuff you had make and maybe if you were lucky a configure script to work with. I like what I see though. Just takes some time to become familiar with it all. Still don’t understand the kernel make system with Kconfig and make. I was trying to take out the vdso32 obj in the kernel to test full 64 bit kernel and filesystem and not needing a cross compile setup. But so far no go. I have all my other stuff working now. GPS Lidar Lite IMU and even the roboclaw on the otg-usb port. The whitelist works a little differently. If you enable it in the kernel it will read the header file and whatever is in that header is all it will recognize. So its a little confusing. Didn’t have to install a driver (FTDI) either. Its an Atmel chip similar to the ftdi I suspect. Seems to work the same way. Wifi has been flawless since the exchange of boards.

Had it out the other day for some pics prior to packing it up for the move.



Everyone have a great Christmas.