[Documentation] [TitleIndex] [WordIndex

API review

Proposer: your name here

Present at review:

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.


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:


Header header


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.

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

Meeting agenda

Decide on the new form of Odometry.


Stack status change mark change manifest)

* For M3 we need to be able to release soon

Action Items

2024-06-15 12:54