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