Proposer: Stuart Glaser
Present at review:
- Wim, Matei, Kaijen, Eric
Review for the head and gripper interfaces:
Question / concerns / comments
- 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.
- 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?
- 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?
- 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?
To be filled out by proposer based on comments gathered during API review period
- 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
- 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.
Package status change mark change manifest)
Action items that need to be taken.
Major issues that need to be resolved