API review

Proposer: Sachin Chitta

Present at review:

  • List reviewers

API Proposal

  • Remove JointTraj.msg and JointTrajPoint.msg

SplineTraj.msg - retained to define spline coefficients

  •   Header header
      string[] joint_names
      SplineTrajSegment[] segments

SplineTrajSegment.msg - define a single spline trajectory segment

  •   duration duration
      SplineCoeff[] joints

SplineCoeff.msg - define a single spline

  •   float64 a
      float64 b
      float64 c
      float64 d
      float64 e
      float64 f

This structure is easier than the existing structure where the spline coefficients are defined as arrays of type a,b,c,d,e,f, etc. E.g., with the existing structure, to define a spline with 4 segments for 5 joints, this would be the code

  •   int num_segments = 4;
      int num_joints = 5;
      SplineTraj spline;
      for(unsigned int i=0; i < num_segments; i++)

With the new proposed structure

  •    SplineTraj spline;
       int num_segments = 4;
       int num_joints = 5;
      for(unsigned int i=0; i < num_segments; i++)

Waypoint.msg - used to specify a single waypoint

  •  float64[] positions
     float64[] velocities
     float64[] accelerations
     float64 time

WaypointTraj.msg - used to specify a path

  • # A complete trajectory specified as a set of waypoints.  Since each waypoint
    # contains the pos/vel/acc for many joints (or other dimensions), the names array
    # is used to specify joint names
    string[] joint_names
    Waypoint[] points


  • # This message contains information about limits of a particular joint (or control dimension)
    uint8 has_position_limits
    uint8 angle_wraparound
    float64 min_position
    float64 max_position
    uint8 has_velocity_limits
    float64 max_velocity
    # min_velocity is assumed to be -max_velocity
    uint8 has_acceleration_limits
    float64 max_acceleration
    # min_acceleration is assumed to be -max_acceleration


  • # Same as the WaypointTraj message, but contains information about joint limits
    string[] names
    Waypoint[] points
    JointLimits[] limits

  • A generic IK request message that contains the name of the link for which the IK request is being made, its pose (stamped), and the initial guess for an IK solution


  • string link_name                       #The link for which this IK request is being made
    geometry_msgs/PoseStamped pose_stamped #The stamped pose of the link 
    float64[] positions                    #The current positions of the joints
    string[] joint_names                   #The names of the joints

IKRequest.srv - A generic IK service request - Will rename to GetIKSolution.srv

  • manipulation_msgs/IKRequest data
    float64[] solution

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.


  • These message currently overlap with some of the definitions in motion_planning_msgs, e.g. Waypoint in motion_planning_msgs is defined as:
    • JointState[] joints
      float64 time
    • We should think about combining them.


  • In SplineCoeff.msg, can we use an array of coefficients: coeff[6], where coeff[i] is the coefficient for the i-th power of time. This would simplify a lot of code where the variable names a through f are currently enumerated.


  • Consider renaming SplineCoeff to SplineCoefficients, QuinticSpline, or Spline

  • Document whether the coefficients are ordered lowest degree to highest or highest to lowest.
  • It seems like we need the following set of stuff:
    • A message for a joint trajectory parameterized by time, specifying boundary conditions at each point.
    • A message for a joint path where only the positions (and velocities?) matter
    • [maybe] A message for a joint trajectory specified as spline coefficients.
    • Some way to specify joint constraints (limits can be treated as constraints). I would prefer the parameter server over a message.
  • Perhaps we should pull out a set of stuff that describes movements. movement_msgs? arm_msgs, chain_msgs?

Meeting agenda

To be filled out by proposer based on comments gathered during API review period


Package status change mark change manifest)

  • /!\ Action items that need to be taken.

  • {X} Major issues that need to be resolved

Wiki: manipulation_msgs/Reviews/10-09-2009_API_Review (last edited 2009-10-09 00:59:30 by StuartGlaser)