API review

Proposer: Ken Conley

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.

kwc: As with any messages-related review, it's pretty gory. I've proposed and ticketed new manipulation, nav, and visualization message packages to offload some of the messages. I've also proposed to reinstate an experimental_msgs package to contain some future robot_msgs that are not ready for release yet. Of the remaining messages, about half I marked as 'ok' under my own intuition and half I'm still unsure about. robot_msgs has a tricky inclusion criteria that we should perhaps debate, but my general notion was:

robot-generic
common, shared concepts that are unspecific to a particular stack
actual, widespread use
stable

As prcore will necessarily need to be our most stable stack, it is important that robot_msgs not be a source of instability.

Naming Issue?:

Point vs. Point32 (point is 64-bit)

Messages that depend on deprecated_msgs:

OccMap2D (service-only message, can be changed)
MapMetaData (service-only message, can be changed)
Planner2DGoal (volatile message, can be changed, moving to nav_msgs)
Planner2DState (volatile message, can be changed, moving to nav_msgs)
Polyline2D (can be changed? moving to visualization_msgs)
VisualizationMarker (can be changed? moving to visualization_msgs) (Might be nice if it uses TransformStamped. --Stu)

ok for inclusion, though must be reviewed:

ChannelFloat32.msg
ControllerState.msg (conor, for highlevel_controllers API)
DiagnosticMessage.msg
DiagnosticStatus.msg
DiagnosticString.msg
DiagnosticValue.msg
MapMetaData.msg
OccMap2D.msg
Point.msg (Do we want separate Point and Vector3 messages? --Stu)
Pose.msg (Do we want to keep both Pose and Transform? --Stu)
PoseStamped.msg
PoseWithCovariance.msg
Quaternion.msg
QuaternionStamped.msg
Transform.msg
TransformStamped.msg
Vector3.msg
Vector3Stamped.msg
Twist.msg (Definite keeper. --Stu)
Wrench.msg (Definite keeper. --Stu)

Remove (difficult):

Acceleration.msg (Remove. Replaced by Vector3. --Stu)
AngularAcceleration.msg (Remove. Also replaced by Vector3. --Stu)
AngularVelocity.msg (Remove. Vector3. --Stu)
PoseDDot.msg (Remove. Replaced by Twist. --Stu)
PoseDot.msg (Remove. Replaced by Twist. --Stu)
PoseWithRatesStamped.msg (Replace with a message that uses the Twist msg instead of PoseDot. --Stu)
Velocity.msg (Remove. Replaced by Vector3. --Stu) -- I'm not sure I agree with all of this block. Stu's proposals lose a lot of type information. --Tully

TBD:

MechanismState:
- ActuatorState.msg (Add a 'zero_offset' field. Needed to convert encoder data into joint angles --Vijay)
- JointState.msg
AudioRawStream.msg (audio_capture?)
BatteryState.msg
CollisionMap.msg (manip?)
JointCmd.msg
JointTraj.msg (manip?)
JointTrajPoint.msg (manip?)
OrientedBoundingBox.msg (goes with CollisionMap)
ParticleCloud.msg
Point32.msg
PointCloud.msg
PointStamped.msg
Polygon3D.msg
PolygonalMap.msg
PoseConstraint.msg (manip?)
PositionMeasurement.msg (people tracking)
TaskFrameFormalism.msg

Messages to remove or find a home for:

VOPose

joint_qualification_controllers http://wgs10.willowgarage.com/trac/personalrobots/ticket/1025

TestData

experimental_msgs:

Ioan and Sachin will migrate to these, someday. When they do, they can be moved back to robot_msgs
- TrajectoryPoint.msg (unused)
- RobotTrajectory.msg (unused)

mocap_msgs (phase_space, openrave_planning):

nav_msgs http://wgs10.willowgarage.com/trac/personalrobots/ticket/1024