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;
    spline.segments.resize(num_segments);
    for(unsigned int i=0; i < num_segments; i++)
    {
     spline.segments[i].a.resize(num_joints);
     spline.segments[i].b.resize(num_joints);
     spline.segments[i].c.resize(num_joints);
     spline.segments[i].d.resize(num_joints);
     spline.segments[i].e.resize(num_joints);
     spline.segments[i].f.resize(num_joints);
    }

With the new proposed structure

•    SplineTraj spline;
     int num_segments = 4;
     int num_joints = 5;
     
     spline.segments.resize(num_segments);
    for(unsigned int i=0; i < num_segments; i++)
    {
     spline.segments[i].joints.resize(num_joints);
    }

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

JointLimits.msg

• # 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

WaypointTrajWithLimits.msg

• # 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

IKRequest.msg

• 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.

Sachin

• 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.

Mrinal

• 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.

Stu

• 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

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved