As I see it (which is based on, well... only me)
This inconvenience is related to geometry_msgs being
"message" types. Messages are often autogenerated types.
They are not meant to do math with, they are a serialization wrapper.
I am guessing one should convert to tf (bullet) types with the
tf::<type>MsgToTf() family of functions as soon as they are not
messages anymore, but mathematical entities.
Then all the consistencies (Poses being only typedefs of transforms for
instance) and
math operator goodies are all there.
Best regards,
Andreas T.
Am 15.10.2010 11:02, schrieb Armin Hornung:
> Am 08.10.2010 19:51, schrieb Tully Foote:
>> If you want changes in common_msgs for diamondback please pay attention.
> I'm not sure if that's worth a review or change, or if I'm just unaware
> of some details. But I always wondered why there is a difference between
> geometry_msgs::Pose[Stamped] and Transform[Stamped]. The data fields are
> identical, the only difference I see is semantically (translation as
> "Vector3" vs position as "Point", rotation vs orientation). This makes a
> quick (& efficient) conversion between the two not possible, the single
> fields have to be copied instead (which I see myself doing quite often
> e.g. in a localization code; best example: [1]).
>
> This boils down to Point vs. Translation, is there a reason to have
> both? Mathematically this is really the same (a point is just a
> translation from the origin), with only a very small semantic difference
> (which could be expressed in the variable or topic name at hand, if needed).
>
> [1]
> http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom#Writing_the_Code
>
> Best regards,
> Armin
(text/plain)