Hi Armin, <br>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. <br>
<br>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. <br>
<br>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. <br>
<br>in general this is mostly a convenience for conversions between the two datatypes. And that can be easily fixed by writing two functions. <br><br>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. <br>
<br>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. <br>
<br>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. <br><br>Tully<br>
<br><div class="gmail_quote">On Tue, Oct 19, 2010 at 10:35 AM, Adam Leeper <span dir="ltr"><<a href="mailto:aleeper@stanford.edu" target="_blank">aleeper@stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br>--Adam<br><font color="#888888"><br><br><br clear="all">Adam Leeper<br>Stanford University<br><a href="mailto:aleeper@stanford.edu" target="_blank">aleeper@stanford.edu</a><br>719.358.3804</font><div><div></div><div>
<br>
<br><br><div class="gmail_quote">On Tue, Oct 19, 2010 at 7:11 AM, Armin Hornung <span dir="ltr"><<a href="mailto:HornungA@informatik.uni-freiburg.de" target="_blank">HornungA@informatik.uni-freiburg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Alright, I changed the message title so that maybe there can be more<br>
opinions on it. If you haven't read it, see full message below for<br>
reference (which was a reply to Tully's notification of common_msgs API<br>
changes)<br>
<br>
Am 15.10.2010 13:57, schrieb Andreas Tropschug:<br>
> As I see it (which is based on, well... only me)<br>
><br>
> This inconvenience is related to geometry_msgs being<br>
> "message" types. Messages are often autogenerated types.<br>
> They are not meant to do math with, they are a serialization wrapper.<br>
><br>
> I am guessing one should convert to tf (bullet) types with the<br>
> tf::<type>MsgToTf() family of functions as soon as they are not<br>
> messages anymore, but mathematical entities.<br>
> Then all the consistencies (Poses being only typedefs of transforms for<br>
> instance) and<br>
> math operator goodies are all there.<br>
<br>
That's all correct, but that still doesn't explain why there should be<br>
both Pose[Stamped] vs. Transform[Stamped], and Point vs. Vector3<br>
messages. In fact, it only creates more confusion because now there also<br>
need to be more conversion methods to and from tf or bullet to do math.<br>
And for some navigation-related things (see the example I mentioned<br>
about Odometry), you even need to fill in *both* types of messages.<br>
<br>
If there's only a historical reason that there are both, then I feel<br>
like they should be merged for Diamondback (i.e. 22nd of October? What<br>
else needs to be done until then for that?)<br>
<br>
<br>
Best regards,<br>
Armin<br>
<br>
<br>
<br>
> Am 15.10.2010 11:02, schrieb Armin Hornung:<br>
>> Am 08.10.2010 19:51, schrieb Tully Foote:<br>
>>> If you want changes in common_msgs for diamondback please pay attention.<br>
>> I'm not sure if that's worth a review or change, or if I'm just unaware<br>
>> of some details. But I always wondered why there is a difference between<br>
>> geometry_msgs::Pose[Stamped] and Transform[Stamped]. The data fields are<br>
>> identical, the only difference I see is semantically (translation as<br>
>> "Vector3" vs position as "Point", rotation vs orientation). This makes a<br>
>> quick (& efficient) conversion between the two not possible, the single<br>
>> fields have to be copied instead (which I see myself doing quite often<br>
>> e.g. in a localization code; best example: [1]).<br>
>><br>
>> This boils down to Point vs. Translation, is there a reason to have<br>
>> both? Mathematically this is really the same (a point is just a<br>
>> translation from the origin), with only a very small semantic difference<br>
>> (which could be expressed in the variable or topic name at hand, if needed).<br>
>><br>
>> [1]<br>
>> <a href="http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom#Writing_the_Code" target="_blank">http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom#Writing_the_Code</a><br>
>><br>
>> Best regards,<br>
>> Armin<br>
><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br>
<br>
--<br>
Armin Hornung Albert-Ludwigs-Universität<br>
<a href="http://www.informatik.uni-freiburg.de/%7Ehornunga" target="_blank">www.informatik.uni-freiburg.de/~hornunga</a> Dept. of Computer Science<br>
<a href="mailto:HornungA@informatik.uni-freiburg.de" target="_blank">HornungA@informatik.uni-freiburg.de</a> Humanoid Robots Lab<br>
Tel.: +49 (0)761-203-8010 Georges-Köhler-Allee 79<br>
Fax : +49 (0)761-203-8007 D-79110 Freiburg, Germany<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com" target="_blank">tfoote@willowgarage.com</a><br>(650) 475-2827<br>