New factor FactorKfLmkPose3dWithExtrinsicsPtr

Factor created by a sensor giving 6d pose measurements like a camera detecting an known shape (a QR code for instance). Relates:

• A KF
• A Landmark
• The sensor extrinsics

Refactoring of the previous factor_apriltag.h

created merge request !416 (merged) to address this issue

mentioned in merge request !416 (merged)

Currently, in wolf there are some generic factors already implemented:

• FactorPose2d
• FactorPose3d
• FactorPose3dWithExtrinsics
• FactorRelativePose2d
• FactorRelativePose2dWithExtrinsics
• FactorRelativePose3d

I miss:

• FactorPose2dWithExtrinsics
• FactorRelativePose3dWithExtrinsics

This last factor would be the one that you need, isn't it? If the first pose is a KF and the other one is a landmark is not so important and can be handled by the processor that emplaces this factor.

What is the status of this? @mederic_fourmy

The factor was implemented as factor_kf_lmk_pose_3d_with_extrinsics.h in "wolf" and is tested by gtest_factor_kf_lmk_pose_3d_with_extrinsics.cpp which is an adaptation of previous apriltag factor. If we agree with the name and we decide to merge it, apriltag/14-refactor-factor-apriltag-to-devel also has to be merged. This is also used in the objectslam plugin.

Done! I changed some things, mostly API (order of parameters). There are two constructors for the generic FactorRelativePose3dWithExtrinsics, one for Frame-Frame and another for Frame-Landmark. The MR is ready to be merged.

Great! We should propagate these changes to aprilag and objectslam before merging. Also, do you have an example in mind for the API with Frame to Frame factor or is it for exhaustivity?

Merging: But this factor is not in devel currently, it is just in the branch to be merged... so we could merge to devel (without removing the branch after merge). You have all the time you want to propagate the changes, right?

Frame-Frame: It is the typical case of a loop closure in 3D..

closed with merge request !416 (merged)

mentioned in commit 8db51eec