API review

Proposer: your name here

Present at review:

• List reviewers

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting. We currently are using RobotBase2DOdom which is deprecated.The thought was to move to PoseWIthRatesStamped

There is a proposed pr2_msgs::Odometry

Header header
geometry_msgs/Pose odom
robot_msgs/PoseDot odom_vel
float64 distance
float64 angle
float64 residual

I'd like to propose: nav_msgs::Odometry

Header header
geometry_msgs/PoseWithRates position
float64 residual

We need to choose one. And it needs to be in common messages.

Wim

The 'residual' is an ugly way to represent a covariance (it's currently used to scale all elements of a covariance matrix in the robot pose ekf). I'd like to propose the following:

xxx_msgs/PoseAndTwistWithCovariance

Header header
geometry_msgs/PoseWithCovariance
geometry_msgs/TwistWithCovariance

Vijay

Covariance of a Pose BR I'm not convinced that the covariance of a pose is a common or well defined thing. Is this a covariance on the actual parameters defining the orientation? Does it make assumptions about what type of representation we use for the orientation (quaternion vs RPY, etc)?

2D vs 3D BR I understand that we're trying to "plan ahead" for when we have a 3D odom & planners, but I feel like this is significantly complicating the 2D case. It seems a little ambitious to choose the best 3D odom format when we don't have any 3D odom yet. Also, 2D vs 3D odometry and planners could very well be considered solving completely different classes of problems, and might not even be very inter-operable.

• In my opinion, it seems much more reasonable to choose a message that best serves the class of odometry & planners that are currently in existence.

• If anyone can tell me how to convert a pose into a xy position and yaw (without looking it up online), then I'll drop my entire argument.

* I think Stu or Eitan noticed this: Bosch created their own 2D Pose type, possibly because they didn't like out 3D message definition.

• http://bosch-ros-pkg.svn.sourceforge.net/viewvc/bosch-ros-pkg/trunk/common/geom/include/geom/Pose.h?revision=14&view=markup

• (I apologize for maybe opening a passionate debate that may have already previously occurred)

Meeting agenda

Decide on the new form of Odometry.

Conclusion

Stack status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

• Need a simple solution for making 3D/quaternion into a human readable form.

  • Look at making a topic tool shape shifter node which will dynamically generate a 3D->2D node which would allow dynamically generated 2D messages.

  • It's hard to debug if the wire is semi opaque.
  • maybe make a display method plugin for rostopic
  • It's a trade off between consistency and being explicit
• For M3 we need to be able to release soon
  • Would like the quaternion deafult to a valid output by default (maybe custom serializer and deserializer)
  • work on solving visibility using tools available