[geometry_msgs] document inertia tensor reference point

[YannikMeinkenRosenxt]

Description

Currently it is not clear whether the inertia tensor in geometry_msgs::msg::Inertia means the inertia about the center of mass, or header.frame_id (in case of the stamped version).

Motivation

Consistent use of message type across components.

Design / Implementation Considerations

I assume it should be the inertia about the center of mass as that is used by URDF (https://wiki.ros.org/urdf/XML/link)
As the of diagonal blocks have to be computed from the COM position either way, it would be strange to have it precomputed for the rotation only part.

A simple comment in the message description should be enough.

Additional Information

No response

[YannikMeinkenRosenxt]

Strictly speaking should the com also be a point instead of a vector3

[ros-discourse]

This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.openrobotics.org/t/ros-news-for-the-week-of-january-5th-2026/51728/1

[ros-discourse]

This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.openrobotics.org/t/ros-news-for-the-week-of-january-12th-2026/51866/1

[asymingt]

Yes, let's definitely add the reference frame to the message documentation!

Strictly speaking should the com also be a point instead of a vector3

You are correct, but I this would result in new message hash. This would mean that all existing bags would need migration rules to bump the message structure, which is cumbersome. I unfortunately don't think this change is worth the turbulence it will cause, but if you feel stringly about it @YannikMeinkenRosenxt I can raise it at the PMC as a topic this week.

[YannikMeinkenRosenxt]

Strictly speaking should the com also be a point instead of a vector3

You are correct, but I this would result in new message hash. This would mean that all existing bags would need migration rules to bump the message structure, which is cumbersome. I unfortunately don't think this change is worth the turbulence it will cause, but if you feel stringly about it @YannikMeinkenRosenxt I can raise it at the PMC as a topic this week.

I totally understand that this is a breaking change and therefore I did not open a separate issue for it, but I also could not not mention it.
The main benefit that I would see in correcting it would be that tf2::doTransform() would apply the correct logic if applied to the com.
Maybe it could somehow be introduced over multiple versions (first depreciated) to be at least eventually correct someday.