C++20 concepts for common robotics/computer vision datatypes and algorithms

[bergercookie]

This is an early attempt to define a set of C++ robotic constructs to encourage code reuse and interoperability among the various open-source robotic projects.

These can be implemented in the form of the C++20 concepts TS

More specifically concepts can be used to define and enforce specific behavior (e.g., methods to be present in a class) for all the classical robotic constructs that need to be implemented in any new project. As an example these may include:

• Pose (2D, 3D, etc.)
• Graph
• PointXD / Landmark
• SensorMeasurement
• PointCloud
• ...

Having these constructs in place will allow to define a standard among the different implementations; one will know what to expect from a Point instance regardless if they deal with an MRPT CPoint2D, a JDERobot CPoint3D a custom implementation of theirs or anything else that could abide to that concept. It will also help to reason about and benchmark the various implementations.

An example boilerplate code for e.g., a pose would be the following (does not compile):

// forces every pose object to implement specific methods
template<typename T>
concept bool PoseAble = requires(T a){
	{ a.isPDF() } -> bool;
	{ a.dims() } -> std::size_t;
	{ a.translation() } -> VectorisAble&;
	{ a.rotation() } -> RotationMatAble&;
	// ...
};

void compose(const PoseAble& p1, const PoseAble& p2)
{
	// compose the two poses by calling methods that should
	// be present since they implement the `PoseAble`
	// concept
}

int main(int argc, char *argv[])
{
	PoseAble& p1 = mrpt::poses::CPose2D(1.0, 2.0, M_PI/4.0);
	PoseAble& p2 = mrpt::poses::CPose2D(2.0, 3.0, 0.0);

	compose(p1, p2);
	return 0;
}

P.S. The latest update is that concepts are to be included in C++20 version. There is also a concepts implementation in gcc6 and can be used by compiling with -fconcepts -std=c++1z

Links

• TS Document
• Concepts - cppreference
• Minimal concepts example

Next actions

To get this going I can create a separate repo and then transfer ownership to the MRPT org. There we can also discuss the specification and format of the concepts to be implemented in separate gh-issues (issue per concept).

How does this all sound to you?
Any ideas for the name? how about robot-concepts?

@jolting, @jlblancoc, @EduFdez,

Also adding @eperdices, @okanasik from the JDERobot project and @rcintas from Robocmp

[jlblancoc]

Thanks for putting all the first draft ideas together! As briefly mentioned in private, of course I like this initiative. 👍

Another byproduct of it, if gets finally done, if that we would be able to implement generic ROS node wrappers for families of algorithms: navigation, mapping, localization, egomotion data fusion, etc. which could then be linked to each particular library.

We'll probably find hard times when we reach the point of particularizing how to refer to mid-to-large objects: references? shared ptrs? something that could be both? ROS-like msgs?

On the name: robot-concepts is good! I only miss a way to get the computer vision guys to feel included... However, I don't have a better proposal for now!

That's all my contribution for now, will get back...

[bergercookie]

Boilerplate code: https://github.com/bergercookie/robot-concepts

[jolting]

Wow. You really ran with it. Cool

[jolting]

What about a convention like APose?

[jlblancoc]

Wow. You really ran with it. Cool

Absolutely, he did! I'm simply out of spare time to check it for now in detail, sorry, will do it asap.

But here's another idea: what about adding ROS REP-like draft documents to the robot-concepts repo? They should be the "rationale" behind:

• the entire "concepts" system (!)
• one document per "concept" or family of related "concepts"

[jlblancoc]

Project title tiny change proposal:

- C++20 concepts for common robotics/computer vision datatypes
+ C++20 concepts for common robotics/computer vision datatypes and algorithms

[bergercookie]

Absolutely, he did! I'm simply out of spare time to check it for now in detail, sorry, will do it asap.

Nah, nothing to check yet, it's just the directory sturcture and a README for now :)

What about a convention like APose?

LGTM, I used .*Able in the example but A.* is better

But here's another idea: what about adding ROS REP-like draft documents to the robot-concepts repo? They should be the "rationale" behind:

I was thinking of the same, but with the rust rfc in mind.

If we do decide to go for this I 'd argue one doc per concept. Also we might as well put it in a separate repo (e.g., robot-concepts-rfc) to track it separately from the code changes

[jolting]

isPDF should be a pose trait

template <typename T>
inline constexpr bool mrpt::pose_traits::isPDF_v<T>

[bergercookie]

isPDF should be a pose trait

I was under the impression that C++ concepts are traits-like cosntructs enforced in compile time. What's the benefit of having it as an independent trait?

[jolting]

An APosePDF is composed of a mean and a covariance. The mean is an APose and the convariance could have some concept like ACovariance and can be some kind of matrix.

isPDF is essentially the same as saying the type is required to be an APosePDF. I think that's a better way to express it and avoid the whole isPDF thing. Just treat them as two concepts.

CPose2DPDF and CPose2D are fairly disparate types and you really can't generalize algorithms any further than that anyway. This also is in line with the object-oriented composition over inheritance principle.