Hi Tully!

> The choice to differentiate between Point and Vector3 was explicit.
> semantically they are quite different.  If you transform a point it both
> rotates and translates whereas if you transform a vector it only rotates.

OK, I see. When applying a transform to them the distinction makes 
sense. However, shouldn't that then happen at the level of mathematical 
operations (i.e. bullet, after converting from the message type)? If the 
distinction would be made during conversion, there could be only one "3D 
positional msg", be it Vector3 or Point.

>
> The semantic difference between pose and transform exists think what is
> the "product" of two poses? A transform can operate on a pose, but a
> pose can't really operate on anything.  At the level of the stamped
> objects this differentiation actually is represented by different data.
> A TransformStamped has more information than a PoseStamped.

Yes, and that's one additional source of confusion when trying to apply 
conversion functions between tf and messages, it's a pain to find the 
correct one and convert between some other formats afterwards. 
PoseStamped is a Pose + Header, while TransformStamped is a Transform + 
Header + ChildId. I know that makes perfectly sense because 
TransformStamped is the coordinate transform used for tf, the naming is 
just a little inconsistent or confusing.

>
> The one thing which could be considered is collapsing the Transform and
> Pose messages such that TransformStamped containes a Pose inside.
> However to do this sort of thing between Cturtle and Diamondback
> everything must be backwards compatable(There are over 4000 references
> to the string "Transform" excluding btTransform in released cturtle code
> and 121 references to TransformStamped.  Thus to do this It would
> require making TransformStamped2 or equivalent for backwards
> compatibility and then some fraction of the system would use
> TransformStamped and some fraction would use TransformStamped2.
>
> in general this is mostly a convenience for conversions between the two
> datatypes.  And that can be easily fixed by writing two functions.
>
> Based on this difference I would suggest that it is hard to make the
> case that the cost of converting between the two datatypes outweighs the
> cost of migrating all code and going through the ticktock.
>
> This level of a change would require a REP to be written covering the
> change, backwards compatability, data migration rules for all bagfiles,
> and code migrations approaches and proposed times for phase outs of the
> old data types.
>
> In general I think that most people would like to do this, but people
> also like stability.  If you would like to write a REP for this please
> post it to ros-developers to get feedback from the community.

As much as I would like to see that merge happening, that definitely 
won't be all in writing until Oct. 22nd, also considering that I'm 
currently at IROS in Taiwan...
But for now, having a clearer distinction outlined somewhere (msg header 
comments, tf function comments, wiki pages) should make life easier.

Cheers,
Armin

-- 
Armin Hornung                              Albert-Ludwigs-Universität
www.informatik.uni-freiburg.de/~hornunga   Dept. of Computer Science
HornungA@informatik.uni-freiburg.de        Humanoid Robots Lab
Tel.: +49 (0)761-203-8010                  Georges-Köhler-Allee 79
Fax : +49 (0)761-203-8007                  D-79110 Freiburg, Germany