API review

NOTE: This is a preliminary brainstorming review conducted online

Proposer: Jonathan Bohren

Present at review:

• Jonathan Bohren

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.

Meeting agenda

Determine scope for a message type to capture the semantics of cartesian trajectories and streaming cartesian control in teleoperation.

Potential features include (in no particular order):

1. Multiple end-effectors
2. Variable impedance (stiffness/damping)
3. Path tolerances
4. Accelerations
5. Combinations of joint-space and cartesian-space movements
6. Nullspace posture
7. Nullspace impedance

The previous formal review notes are here: robot_mechanism_controllers/Reviews/Cartesian Trajectory Proposal API Review

The initial thread on ros-users is here: http://lists.ros.org/lurker/thread/20130605.124118.361c6da3.en.html

Proposals

Willow Garage (2010)

Details here: robot_mechanism_controllers/Reviews/Cartesian Trajectory Proposal API Review

[CartesianTrajectoryGoal]
CartesianTrajectory trajectory
  Header header  # A stamp of 0 means "execute now"
  PoseStamped tool  # The frame which is being controlled
  string[] posture_joint_names
  CartesianTrajectoryPoint[] points
    duration time_from_start
    Pose pose
    Twist twist
    float64[] posture
  JointTrajectory posture  # For determining the redundancy
CartesianTolerance path_tolerance  # Tolerance for aborting the path
  float64 position
  float64 orientation  # Permitted angular error
  float64 velocity
  float64 angular_velocity
CartesianTolerance goal_tolerance  # Tolerance for when reaching the goal is considered successful
bool queue

[CartesianTrajectoryResult]
int32 error_code  # 0 if successful
CartesianTrajectoryPoint cartesian_state
JointTrajectoryPoint joint_state
Twist pose_error
Twist twist_error
CartesianTolerance path_tolerance  # Current tolerance used for the path

[CartesianTrajectoryError]
int32 SUCCESSFUL = 0
int32 ROOT_TRANSFORM_FAILED
int32 TOOL_TRANSFORM_FAILED
int32 PATH_TOLERANCE_VIOLATED
int32 INVALID_POSTURE

Konrad Banachowicz

[CartesianTrajectoryGoal]
Header header  # A stamp of 0 means "execute now"
string[] effector_names
CartesianTrajectory[] trajectory
  Pose tool  # The frame (offset ?) which is being controlled or it can be treated as separate effector ? 
  CartesianTrajectoryPoint[] points
    duration time_from_start
    Pose pose
    Twist twist
CartesianImpedance[] impedance
    Pose center_of_compliance # or it can be treated as separate effector ? 
    TBD stiffness % cartesian stiffness 
    TBD damping % damping ratio
CartesianTolerance[] path_tolerance  # Tolerance for aborting the path
  float64 position
  float64 orientation  # Permitted angular error
  float64 velocity
  float64 angular_velocity
CartesianTolerance[] goal_tolerance  # Tolerance for when reaching the goal is considered successful
string[] joint_names
JointTrajectoryPoint[] posture  # For determining the redundancy
JointImpedance[] nullspace_impedance
  float64[] stiffness
  float64[] damping

Konrad Banachowicz 2

CartesianTrajectory

Express trajectory of frame target_frame_id in relation to frame header.frame_id .

Header header # stamp - trajectory start time, frame_id - trajectory reference frame 
string target_frame_id # target controlled frame
CartesianTrajectoryPoint[] points
  duration time_from_start
  Pose pose
  Twist twist

CartesianImpedance

Parameters of spring-damper located between frame header.frame_id and frame target_frame_id.

Header header # stamp - trajectory start time, frame_id - spring-damper base frame 
string target_frame_id # spring-damper end frame
CartesianImpedancePoint[] points
  duration time_from_start
  CartesianStiffness stiffness
    Vector3 translational
    Vector3 rotational
  CartesianDamping damping
    Vector3 translational
    Vector3 rotational

CartesianConstraints

Constraint the relation between header.frame_id and target_frame_id.

Header header # stamp - time of constraint activation
string target_frame_id
duration time_from_start # duration of constraint activation
TranslationConstraint translation
OrientationConstraint orientation
Twist twist
Wrench wrench

ActionGoal

[CartesianTrajectoryGoal]
CartesianTrajectory[] trajectory
CartesianImpedance[] impedance
CartesianConstraints[] path_constraints  # Tolerance for aborting the path
JointTrajectory[] posture  # For determining the redundancy
JointImpedance[] nullspace_impedance

Adolfo Rodriguez Tsouroukdissian

• +1 for adding Cartesian accelerations to the CartesianTrajectoryPoint message.

• The list of potential features mentions "Multiple end-effectors". I'd like to see how this looks like. We also need to decide where to draw the line, because when controlling multiple end-effectors, you're more likely to also want partial constraint specifications (< 6dof of a frame, like following orientation only), which seems out of the scope of the current proposal.

Konrad Banachowicz

The concept of multiple end-effectors is included in ActionGoal. We have multiple trajectories (CartesianTrajectory[] trajectory). It can express trajectories in general, it could be "end-effectors", "tool transforms", "center of complayance", "look at" frame for head ...

In my use-case the constraints are encoded in spatial springs between frames. I don't control position of the end-effector directly but by spatial springs between end-effector and an other frames.

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

---