Add missing dependency on libceres-dev

[mintar]

No description provided.

[gavanderhoorn]

I think this was left out on purpose, as it's not clear whether the Ceres this rosdep rule resolves too is recent enough. At least on Indigo the rule resolved to a version packaged by Mike Ferguson, which did not track the upstream repository for Ceres.

See also #32 and #62 (comment).

[mintar]

Thanks, I wasn't aware that there were already those discussions about Ceres. So don't merge this PR.

On Ubuntu Trusty-Wily, this rosdep rule indeed resolves to libceres-dev 1.8.0 by Mike Ferguson. On Ubuntu Xenial, libceres-dev 1.11.0 is in the Ubuntu upstream repositories, and the rosdep rule resolves to that.

I fully agree with your comment on #62. It's a bit unfortunate that nobody answered your question though. So:

1. Is the libceres-dev 1.8.0 by Mike Ferguson recent enough? If yes, we should simply merge this PR.
2. If not, we should figure out which minimum version is required, and put that into the find_package line so that compilation fails on 1.8.0.
3. Bonus points for upgrading the libceres-dev in the ROS debian repository to the required version. Optimally, simply backport the official package from Xenial for those Ubuntu distros that don't have it. That would allow us to simply add a rosdep rule like in this PR.
4. Also, in your comment you refer to "the current instructions" (for installing libceres). Where are they? Perhaps in the .travis_ceres.sh?
5. And yes, some documentation on this point would be nice. :)

[gavanderhoorn]

@mintar wrote:

4 . Also, in your comment you refer to "the current instructions" (for installing libceres). Where are they? Perhaps in the .travis_ceres.sh?

I'm referring to the instructions on the wiki here.

re: the rest of your comment: I don't think we can resolve this without some input from @drchrislewis.

[drchrislewis]

@mintar Sorry I have not chimed in. At this point I have nothing to offer. I've not looked at nor installed Ceres in a while. Installing the correct version was always a challenge for me. The last time I developed any new code for the cal-package I had to install from src in order to get the covariance computation features I wanted. I fought something having to do with -fPIC. I always just followed the Ceres install from src instructions. They don't always work. Others with more know how have updated the CMakelist well beyond my understanding of how the build system works. My vague understanding is that with the PR, one should be able to start with a fresh ROS install, git clone the calibration package, type rosdep install industrial_calibration, and the correct version of Ceres should magically appear? If this is true, then to test this, I need a computer without Ceres, and one that we can afford to break its configuration. I'd like to do this. I still feel less than confident that I would know if the changes in the build files was right. I'm not ignoring the PR, I'm just incompetent when it comes to build system nuances.

[mintar]

My vague understanding is that with the PR, one should be able to start with a fresh ROS install, git clone the calibration package, type rosdep install industrial_calibration, and the correct version of Ceres should magically appear

Yes, almost. The command is rosdep install industrial_extrinsic_cal, but you'll still get an error because camera_aravis can not be found. So just ignore the build system details and whatever this PR does and do everything by hand (see below). The important question that we would like your input on is whether everything works with libceres-dev 1.8.0 by Mike Ferguson. I don't have a working calibration setup (yet), and I don't know what things to look out for in order to judge whether "everything works", so that's why we need your input.

How to install ceres 1.8.0

• Use Ubuntu Trusty (or perhaps Utopic, Vivid or Wily, but ROS indigo has no binaries for those). Xenial already comes with libceres-dev 1.11.0, so we already know it works on Xenial.

• Uninstall glog, gflags and ceres that were installed from source:

  sudo rm -rf /usr/local/bin/gflags_completions.sh \
              /usr/local/include/ceres/ \
              /usr/local/include/gflags/ \
              /usr/local/include/glog/ \
              /usr/local/lib/cmake/gflags/ \
              /usr/local/lib/libceres.a \
              /usr/local/lib/libgflags.so.2.1.2 \
              /usr/local/lib/libgflags_nothreads.so.2.1.2 \
              /usr/local/lib/libglog.a \
              /usr/local/lib/libglog.la \
              /usr/local/lib/libglog.so.0.0.0 \
              /usr/local/lib/pkgconfig/libglog.pc \
              /usr/local/share/Ceres/ \
              /usr/local/share/doc/glog-0.3.4/
  

• Install libceres-dev 1.8.0. This assumes that you have added the ROS apt repository to your sources.list (if the following command passes, you did):

  sudo apt-get install libceres-dev
  

• Compile the indigo-devel branch of industrial_calibration using catkin_make. This should work without problems (it did on my machine).

• Test it and report back here. :)

How to switch back to ceres 1.11.0

• First:

  sudo apt-get remove libceres-dev
  

• Then follow the wiki instructions to install the stuff from source.

[gavanderhoorn]

@mintar wrote:

The command is rosdep install industrial_extrinsic_cal, but you'll still get an error because camera_aravis can not be found

That is actually one of the outstanding issues. See @drchrislewis in #62 (comment):

4 . the package aravis_camera_driver is unique to me. We should remove all refs to it.

[gavanderhoorn]

@mintar wrote:

• Test it and report back here. :)

This is actually the main thing: without knowledge of what should happen, it's hard to know whether the Ferguson-port is recent enough. I certainly don't feel qualified to say whether 1.8 should/would work.

Unless @drchrislewis actually means that it shouldn't even compile if 1.8 is used, that would be easy to check.

[mintar]

The camera_aravis problem is fixed in #83, and that should be merged then (which will close #82).

[drchrislewis]

@mintar I installed libceres-dev recompiled and it ran at least one demo. However, I don't know how to know that it linked to the latest Ceres, and not the one I installed from source. Both Ceres libraries are installed on my machine now, just in different locations. I'll try to remove the source install, but I won't have time today.

[VictorLamoine]

Chris you can use ldd on the binary to know what it links to; eg:

$ ldd test_gcc | grep gcc
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5e433df000)

man ldd will give you more info but it is fairly easy to use.

[drchrislewis]

@VictorLamoine for some reason libceres does not show up in the ldd list for any of my ceres executables. Perhaps its statically linked?

[mintar]

@drchrislewis libindustrial_extrinsic_cal.so is linked against libceres, and all the executables are linked against that.

Which libceres is it linked to (on my machine)?

$ ldd ./devel/lib/libindustrial_extrinsic_cal.so | grep -i ceres
    libceres.so.1 => /usr/lib/libceres.so.1 (0x00007f2326471000)

Aha, the one from /usr/lib, so it should come from a deb package. Which one?

$ dpkg -S /usr/lib/libceres.so.1
libceres: /usr/lib/libceres.so.1

Ok, show me the version of libceres and where it came from:

$ apt-cache policy libceres              
libceres:
  Installed: 1.8.0-1+trusty2
  Candidate: 1.8.0-1+trusty2
  Version table:
 *** 1.8.0-1+trusty2 0
        500 http://packages.ros.org/ros/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

It's 1.8.0 from packages.ros.org.

[drchrislewis]

@mintar Thanks for the detailed instructions, but this old man is still perplexed
clewis@clewisDesktop:/catkin_ws$ ldd ./devel/lib/libindustrial_extrinsic_cal.so | grep -i ceres
clewis@clewisDesktop:/catkin_ws$
I even looked through the list of so's manually for both the library and an executable that runs using ceres. I suspect that this means that when I compiled ceres from source I did compile it as a shared object. Therefore, I'm still running against my old installation of ceres. I think I will uninstall the deb, then remove all things ceres(my install from src), and then re-install the deb.

[mintar]

@drchrislewis Sounds like a plan. Note that I've included instructions above on how to uninstall glog, gflags and ceres that were installed from source (the stuff starting with sudo rm -rf).

[VictorLamoine]

To uninstall a CMake project you should use make uninstall or if it's not implemented;
xargs rm < install_manifest.txt

https://cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F

[mintar]

@VictorLamoine Yes, you're right in general; but since some of the projects are non-CMake projects without an uninstall (that I could find, at least), I thought I'd keep the instructions simple.

[drchrislewis]

@mintar I un-installed ceres, installed libceres-dev, neither your branch, nor my branch now compile due to a missing ceres dependency:: Eigen version 3.2.0. I did "sudo apt-get install libeigen3-dev", and can see the eigen header files in /usr/include/eigen3. Sorry, I'm not getting anywhere. @shaun-edwards is back today. Perhaps he will be kind enough to help.

[mintar]

That is weird. I also have libeigen3-dev and nothing else. Perhaps setting up a new catkin workspace from scratch solves the problem? You're also on Ubuntu Trusty, right?

[drchrislewis]

@mintar Sorry its taken me so long to figure this one out. I could not get this change to compile correctly until I added
FIND_PACKAGE(Eigen3)
IF (EIGEN3_FOUND)
MESSAGE(STATUS "Eigen3 found in ${EIGEN_INCLUDE_DIRS}")
ENDIF(EIGEN3_FOUND)

to all the CMakelist.txt files
The error reported occurred in the find ceres cmake file. It indicated that it could not find eigen even though the latest version was installed. I believe this is because it is a header only "library." My understanding of cmake and catkin is poor, so perhaps there would be another way. Please let me know what you think. I would love to be able to use the ceres debian.

[mintar]

@drchrislewis : I cannot reproduce your problem, it must be a problem on your local machine.

As proof, I've written a Vagrantfile. You can try it like this:

sudo apt-get install vagrant
vagrant up    # must be run in the directory that holds the Vagrantfile

This will create a clean virtual machine, install everything required and build industrial_calibration. You can also look at the "script" section in the Vagrantfile and execute that locally.

Further proof: I've removed the script that installs ceres and friends from source from the Travis config. It still builds with my changes, and as a nice side-effect the build time drops from 12:09 min to 5:39 min on the Travis servers.

So in summary, this PR compiles everything correctly. The versions are a bit older than the ones from source, but that doesn't seem to matter - at least we don't have any indication that it would hurt.

[gavanderhoorn]

Just a note: apparently @mikepurvis has a deb of 1.11 in his PPA (from discourse post).

[gavanderhoorn]

I'm guessing this got closed in favour of #94?

[AustinDeric]

@gavanderhoorn you are correct, but we want to make sure we can also build against a binary/debian as well.

We are going to continue to do testing in the near term and make sure this all runs. We are also going to look at the issues and address them. If you have anything in particular, please send me an email [email protected].

Thanks!