API review

Proposer: Stuart Glaser

Present at review:

• Wim, Matei, Kaijen, Eric

Review for the head and gripper interfaces:

• pr2_head_controller

• pr2_gripper_action

Question / concerns / comments

Stu

• Do we want a "point frame on head" behavior? What should the message look like?
• Should the parameter server contain the joints or the links?
• Should "point_head" be an action of some form?
• From Kaijen/Matei:
  • The gripper should abort when it stops moving and hasn't reached the desired position.
  • A "min_force" should also be specified. This will be the force necessary to overcome static friction.
  • The action should provide feedback as to the current position and effort.

Gunter

• For head controller: I'm confused that the joint command is a joint state message. Yes, I would imagine that users will want to specify not only locations, but also velocities, but that doesn't necessarily imply state message?
• Same for the target point, can we also specify a rotational max speed? Do vision folks want this?
• For grip: admittedly the action interface looks very confusing to me. I assume that's just me????
• Is the goal always a position with max force?
• Can we specify velocity?
• Can we specify just a force, regardless of position? Guess that is 0 or negative position with max force... might be nice to make a little more explicit, but okay.
• I assume there is little point (given the shape of the fingers), to specifying a max opening force?? We are always looking at closing forces only?
• Does this use and of the touch sensors? I'm assuming max force is simply max motor force?
• What units are position in? meters open?

Wim

• Which frame/axis are we pointing? Should it be possible to choose the frame you want to point?
• Can the head controller provide state feedback?
• What type of trajectory is used to get to the desired head orientation and gripper position? Could we specify max vel, max acc, duration?

Matei

• for the head, we have the controller ("head_traj_controller") and the interface node ("head_controller") that you actually talk to. The naming is confusing: maybe the interface node should not have the word "controller" in its name.

• for both the gripper and the arm, the interface is through an action; for the head it's not. Do we want to leave it this way?

Meeting agenda

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

Head

• Do we want to provide the ability to send velocities or timings as well?
• Possibility: anyone who wants velocities/timings talks directly to the traj controller.
• The head currently just jerks to point the head:
  • Do we want maximum velocities?
  • Vision folks just want the head to snap to a position
• The head goes tic-tic-tic at the command rate
  • Change message to specify how much time to take to get there?
  • Change message to specify the max velocity?
• Not an action now, but you do want to know when your head has settled so you can take a picture.
• Also for consistency.
• If an action, when is success?
  • Succeed when you've settled
  • Never succeed, just cancel when you're preempted (feedback indicates error)
• Specifying a frame implies specifying an axis (possibly implicitly)
• Make the user do it?
• More conceptual juggling than the user should have to do
• Definitely add a pointing_frame to the command message
• Also specify an axis?
• The default is pointing the x axis (for head_pan)

Head message that includes everything:

Header (to describe the target)
target
frame to point
axis to point (vector)
Doing smooth tracking:
  how_long_to_take duration (0 = immediately)
  max_velocity (0 = none)


PointStamped target
Vector3Stamped pointing_axis (origin)
how_long_long_to_take
max_velocity

• Smoothing at 50hz/20hz?
• Should have a default frame/axis to point

• PoseStamped or Vector3Stamped to describe the pointing axis?

  • Need to deal with a quaternion with a pose
  • Vector3 is much more straightforward. Use it.
• Does the Vector3 timestamp have meaning???
  • Vector3 and a frame_id instead (pointing_axis, pointing_axis_frame)
• Fixed frame as a parameter? No for now.
• Setting head joints directly: talk to the traj controller yourself.
  • Interacts badly with ...
• At some point in the future we will construct a better way of chaining preempts all the way to the bottom.
• Head controller state feedback
• Service call: give it what you want to point at and it gives you the joint angles.
• Interface node should change to head_[pointing]_action
• This is definitely PR2 specific.
• Schedule a meeting for the gripper by itself.

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

---