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::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