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
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
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
  • could make service to provide 3D to 2D conversion for viewing.
  • rostopic plugin methods
  • convenience functions

• The question is how much does a person need to know to use the system.
  • Users 2dnav converter -- are they expected to be able to learn to do 3D geometry?
  • Random non coding user -- won't see code/API/message
  • power developer -- they will know/should learn
• Three variants
  • Full 2d support (convert everything which is natively 2D) --- Can't do this.
  • Only 3D support (status quo)
  • Find places where a novice would want to use 2d and provide template/convenience functions
    • Define message type that would be shared across other users
      • Pose2D Pose2DWithCovariance and Odom2DStamped
      • not stamped (explicitly no tf support in 2d, assuming a single frame, no timing)

    • Write a node Odom2D -> Odom3D

    • Write a node to provide 2D interface to 3D nav stack
      • set param for frameid of the interface

Action Items

• make covariance into fixed axis not euler

• create geometry_msgs::TwistWithCovariance

• Choose Wim's proposal for 3D odometry (vslam etc) as nav_msgs::Odometry
• Create Pose2D (as confluence of integration)
• Lay out plans for 2D interface for nav stack (do not initially release)
• Eric is writing an email to warn not to update and announcing the schedule.
• Friday is do everything in common msgs
• Try to release common_msgs-0.9 on monday.