fixes for Ubuntu 20.04

[christian-rauch]

This PR incorporates a couple of fixes in an attempt to compile for Ubuntu 20.04:

• port to OpenCV 4
• replace deprecated API
• other compilation fixes

The issue of using Eigen in boost-python (#396, #404) remains. kalibr will not fully compile until this has been resolved, but this PR resolves other issues and should be compatible with previous versions.

[ethzasl-jenkins]

Can one of the admins verify this patch?

[christian-rauch]

@xqms Can you have a look at this? Is there interest in merging these Ubuntu 20.04 / noetic fixes?

[xqms]

I'm not affiliated with kalibr or ETH Zürich in any way, so I can't really do anything about the PR ;)

From a code review standpoint it looks good to me, although I haven't looked too deeply and the python issue remains (apart from the boost python wrapper, all the python scripts also need to be converted to Python3). I sadly don't have time to look further into that, and having a docker container with 18.04 to run the camera calibration is good enough for me.

Looking at the list of open issues and PRs I fear that kalibr is only sporadically maintained, so it might be a while until someone with commit rights reacts. The last commit was 11 months ago... I can understand that, since maintaining an open-source project at a university can be quite challenging.

[goldbattle]

This allowed me to build on 18.04 after also fixing via #283

$ dpkg -s libboost-dev | grep 'Version'
Version: 1.65.1.0ubuntu1
$ dpkg -s libeigen3-dev | grep 'Version'
Version: 3.3.4-4

[mcamurri]

I was able to isolate the problem to the following sections of code (i.e., if you comment them, the code compiles):

kalibr/aslam_cv/aslam_cv_python/src/CameraGeometries.cpp

Line 175 in e9453e0

.def("isValid", &ImageMask::isValid<Eigen::VectorXd>);

kalibr/aslam_cv/aslam_cv_python/src/CameraProjections.cpp

Lines 461 to 467 in e9453e0

	exportOmniProjection<NoDistortion>("OmniProjection");
	exportOmniProjection<RadialTangentialDistortion>("DistortedOmniProjection");
	exportOmniProjection<FovDistortion>("FovOmniProjection");
	exportExtendedUnifiedProjection<NoDistortion>("ExtendedUnifiedProjection");
	exportDoubleSphereProjection<NoDistortion>("DoubleSphereProjection");

I was able to fix the first section by manually specifying the template argument of the isValid function:
from:

kalibr/aslam_cv/aslam_cameras/include/aslam/cameras/ImageMask.hpp

Lines 34 to 35 in e9453e0

	template<typename DERIVED>
	bool isValid(const Eigen::MatrixBase<DERIVED> & k) const {

to:

  bool isValid(const Eigen::VectorXd & k) const {

I think the problem arises when you try to create a python binding with member functions that have template arguments.

I suspect the second section can be fixed in the same way by creating many variants of the various exportSomethingProjection<T> calls.
The first thing that comes into my mind though is the fact that the template functions are within the .cpp.

Maybe the templated methods are build with template arguments that don't make sense (and are not used)?

[johuber]

I was not able to compile this branch due to several issues.

this fork works with noetic though

[christian-rauch]

I was not able to compile this branch due to several issues.

Which issues did you encounter? The "boost-python" issue is known and mentioned in the introduction. Did you see other issues?

[johuber]

I was not able to compile this branch due to several issues.

Which issues did you encounter? The "boost-python" issue is known and mentioned in the introduction. Did you see other issues?

I encountered the issues described above by @mcamurri . is this what you describe as the "boost-python" issue?

[christian-rauch]

I encountered the issues described above by @mcamurri . is this what you describe as the "boost-python" issue?

Yes, I think it is the same.

@mcamurri Can you propose a PR based on the ORI branch and maybe get this merged upstream?

[mcamurri]

Unfortunately we have no bandwidth to accommodate any extra requested change that might come from upstream. If you are interested, I'd suggest to fork our fork and create the PR directly. Otherwise, I can do the PR but I'll have to delegate any extra requested change to the community.

[Eeppii]

I was not able to compile this branch due to several issues.

this fork works with noetic though

This I can confirm. clone the repo in the link in a new caktin workspace and it builds on 20.04.

[alexmillane]

Can also confirm that the link works.

Does anyone have any idea if the linked version works on 18.04?

[wxmerkt]

Does anyone have any idea if the linked version works on 18.04?

It should - we are running CI for Melodic & Noetic so it should be compatible with both 18.04 and 20.04.

[tkazik]

It should - we are running CI for Melodic & Noetic so it should be compatible with both 18.04 and 20.04.

We should then probably create a PR based on the linked version and support only 18.04 and 20.04. (I guess nobody still uses 16.04 or older :)). Also setting up github actions would make sense. Any strong objections?

[goldbattle]

Many thanks for the contribution! I have created PR #515 which supercedes this with some CI docker files to make sure things compile on older version still. Please checkout and provide feedback if you have time, thanks!