On Tue, Oct 19, 2010 at 7:11 AM, Armin Hornung
<HornungA@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
--
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
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users