IMU correction quaternion option

[ojura]

If one wants to apply the correction quaternion from Cartographer's IMU auto-calibration, this per-trajectory option enables using it verbatim, without having to modify the TF tree.

[gaschler]

Sorry for the delayed review.
I see the point in offering the user a way to take the IMU correction log print out and pass it to the Cartographer ROS config.
Yes, I have copy-pasted the quaternion from Cartographer's log output and converted it to a urdf-readable roll-pitch-yaw angle using tf python and I didn't enjoy it.
However, this is really unrelated to ROS and it can be implement in Cartographer alone.
In my opinion, the proper way to implement this feature is to change the output of Cartographer (not _ros) to print urdf-compliant RPY angles in addition.
Essentially, Cartographer would suggest to the user: How about adding this small rotation between from your imu data frame to your tracking frame, on the side of the tracking frame?
However, such implementation should not introduce additional dependencies as the benefit does not outweigh the complexity.
Is that feasible?

[gaschler]

No, I don't like the idea of adding a rotation to the cartographer_ros config.
So far, we leave transforms to tf and almost all users have their extrinsics in a nice urdf file (which cartographer does not need to parse itself).

[ojura]

Yes, I have copy-pasted the quaternion from Cartographer's log output and converted it to a urdf-readable roll-pitch-yaw angle using tf python and I didn't enjoy it.

We're on the same wavelength 😄 I like your idea as well. In that case, we can open an issue or even an rfc for this in the libcartographer repo.

[gaschler]

Sounds good. For additional log output and no new dependencies we don't need an rfc.

[ojura]

Replaced by cartographer-project/cartographer#1516

[Ellon]

Hi @ojura,

I'm trying to understand the meaning of imu_calibration quaternion estimated by Cartographer and outputted in the optimization logs. From what I see on this PR it seems that you understood well its meaning, so would you mind confirming if the following is correct?

1. From this line in your commits I understood that imu_calibration represents the "IMU frame to IMU calibrated frame", in a way that if I apply this rotation to data expressed into the IMU frame I would have the data in the IMU calibrated frame. Is that so?

2. If I want to correct my TF tree by hand with this calibration, could it be done by setting the new IMU frame to be the old IMU frame composed with the inverse of the rotation contained on imu_calibration?

Thanks in advance!

[ojura]

Hi @Ellon,

you are correct about 1). About 2, it’s always a PITA to determine if it is indeed that transform or its inverse. The way I would verify would be to compare imu_correction * old sensor_to_tracking * imu_ data vs new sensor_to_tracking (with correction) * imu_data.

[RonaldEnsing]

I agree that it would be good to have the extrinsics configured on a single place. Having the extrinsics both in the URDF file and a lua file can be confusing.

Is there any plan to fix this in cartographer [1]? Master branch moved forward and is conflicting with the branch of this PR in the mean time. I really think this is a very useful feature.

[1] cartographer-project/cartographer#1516