renaming of wheel odometry API: uses translational velocity (measurem…

[schmidtp1]

…ents)

[azaparov]

Is there any documentation on contents of "calibration_odometry.json" ? What exactly "scale_and_alignment" etc....
Thanks

[ev-mp]

@schmidtp1 , thank you for the update.
Note that python and C# wrappers need to be updated as well.

[schmidtp1]

Hi @azaparov, sorry for the delay.
Here is a sample calibration with comments (not a valid file/format). Please note that this is an intermediate solution and a more unified interface will be coming.

{
    "velocimeters": [ // array of velocity sensors (currently max. 2 supported)
        {
            "scale_and_alignment": [ // 3-by-3 matrix, row-major (multiplies measurement)
                1.0,
                0.0000000000000000,
                0.0000000000000000,
                0.0000000000000000,
                1.0,
                0.0000000000000000,
                0.0000000000000000,
                0.0000000000000000,
                1.0
            ],
            "noise_variance": 0.004445126050420168, // measurement covariance (to be determined/tuned)
            "extrinsics": { // relative transformation of sensor frame w.r.t. T265 body frame (see T265 data sheet, sec. 4.3 "Coordinate System")
                "T": [ // translation (in meters)
                    -0.5059,
                    -0.6294,
                    -0.6873
                ],
                "T_variance": [ // currently not used, please ignore
                    9.999999974752427e-7, 
                    9.999999974752427e-7, 
                    9.999999974752427e-7
                ],
                "W": [ // orientation in axis-angle representation, axis x angle (in rad)
                    -1.1155,
                    -1.1690,
                    -1.2115
                ],
                "W_variance": [ // currently not used, please ignore
                    9.999999974752427e-5, 
                    9.999999974752427e-5, 
                    9.999999974752427e-5
                ]
            }
        }
    ]
}

[schmidtp1]

For completeness, here is the overview of the coordinate frames from the data sheet:

[https://www.intel.com/content/dam/support/us/en/documents/emerging-technologies/intel-realsense-technology/IntelRealSenseTrackingT265Datasheet.pdf, Sec. 4.3]

[azaparov]

Thank you, that moves in a right direction! What is the meaning of scale and alignment matrix ?
Am i correct to assume axis-angle 3 element vector represents unity length axis vector scaled by angle value in radians ?
Thanks!

[schmidtp1]

The scale and alignment matrix is used to multiply the translational velocity vector/measurement. It could be used to account for known/calibrated intrinsics, i.e. in form of a scale factor. (For the general case, we considered off-diagonal elements/crosscoupling but you could ignore it for now.)
You are correct about the axis-angle representation. Thank you for confirming!

[msadowski]

@schmidtp1 is the "sensor_frame" described in the config the frame in which the odometry is in?

As a trivial example let's say my wheel odometry is in base_link frame. If I interpreted the comments in the yaml file correctly then it means that the T becomes the transform from T265 Pose frame (center point between two lenses of T265) and W the rotation needed to align the frames.

If what I'm saying is true then for a setup where the base_link is aligned with Pose Frame such settings should be correct:

I'd appreciate if you could please let me know if I'm correct here. I think it does make sense but better safe than sorry!

[schmidtp1]

@msadowski, yes, the odometry frame is meant by "sensor frame" in this context.

Yes, T and W define the relative transformation between the two frames. Please note that is is expressed with respect to the T265 pose frame, i.e. the transformation that transforms a point from the odometry frame into the pose frame. (I think you that's what you also mean based on your diagram and the values, just making sure.)

Based on your diagram the translation is almost right, T should be +0.3 (z). The rotation would take a bit to check but might be wrong because there is no component wise mapping from Euler angles (?) to angle-axis components. I would recommend to express the rotation in whatever representation you are most comfortable with and then transforming to angle-axis using for example Matlab or the Python transformations module.

[msadowski]

@schmidtp1 thanks a lot for the clarification! You are right about the T(z) needing to be positive in my example!

As a tangent to this issue in realsense-ros we could add a 'sensor_frame' parameter and then fetch the tf transform between the pose_frame and the sensor_frame automatically. If we were to do that we could also add a boolean for publishing odometry in sensor_frame, allowing us to directly compare different odometry sources.

[schmidtp1]

@msadowski, yes, that's a good idea. The current API would still require to generate a json file and provide it at startup but I think it could already simplify the usage a lot.

[ihadzic]

Does anyone know what order of applying of Euler angles does the W transform assume? In the above example that @msadowski posted, rotations would be correct if the order were RXYZ (Relative X-Y-Z). Did these angles work for you?

[msadowski]

Actually these are not the Euler Angles (at first I thought they were) as the comment says:

orientation in axis-angle representation, axis x angle (in rad)

For my purposes I've found some RPY to axis-angle representation and converted RPY to it. It seemed to have worked in my case

[ihadzic]

Ah axis-angle. So in the case you are showing in the sketch, the right values for W would be [-1.2092, 1.2092, 1.2092]. 120-degree rotation about [-1, 1, 1] axis.