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

[Adam Leeper]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101019/2aa0c505/attachment-0003.html>