[ros-users] Merge of Point & Translation (was common_msgs API change proposals required to be reviewed by October 22nd)

Tully Foote tfoote at willowgarage.com
Tue Oct 19 18:53:05 UTC 2010

Hi Armin,
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.

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.

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

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.


On Tue, Oct 19, 2010 at 10:35 AM, Adam Leeper <aleeper at stanford.edu> wrote:

> In some fields (graphics?) some folks like to make a strong distinction
> between a point and a vector, but I agree that it is redundant to have both.
> I would also definitely vote for combining Transform and Pose, since the
> message type conversions are cumbersome. It raises the question of which
> name to keep... I would vote Transform, since it is more general.
> --Adam
> Adam Leeper
> Stanford University
> aleeper at stanford.edu
> 719.358.3804
> On Tue, Oct 19, 2010 at 7:11 AM, Armin Hornung <
> HornungA at informatik.uni-freiburg.de> wrote:
>> Alright, I changed the message title so that maybe there can be more
>> opinions on it. If you haven't read it, see full message below for
>> reference (which was a reply to Tully's notification of common_msgs API
>> changes)
>> Am 15.10.2010 13:57, schrieb Andreas Tropschug:
>> >    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.
>> That's all correct, but that still doesn't explain why there should be
>> both Pose[Stamped] vs. Transform[Stamped], and Point vs. Vector3
>> messages. In fact, it only creates more confusion because now there also
>> need to be more conversion methods to and from tf or bullet to do math.
>> And for some navigation-related things (see the example I mentioned
>> about Odometry), you even need to fill in *both* types of messages.
>> If there's only a historical reason that there are both, then I feel
>> like they should be merged for Diamondback (i.e. 22nd of October? What
>> else needs to be done until then for that?)
>> Best regards,
>> Armin
>> > 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
>> >
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users at code.ros.org
>> > https://code.ros.org/mailman/listinfo/ros-users
>> --
>> Armin Hornung                              Albert-Ludwigs-Universität
>> www.informatik.uni-freiburg.de/~hornunga<http://www.informatik.uni-freiburg.de/%7Ehornunga>  Dept. of Computer Science
>> HornungA at 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
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101019/90c0bf82/attachment-0003.html>

More information about the ros-users mailing list