API review
Proposer: Stu
Present at review:
- List reviewers
Question / concerns / comments
Stu
- 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 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?
Josh
- This may be out of scope, but it would be nice to have an action for "close until contact", which I assume is what a lot of people care about.
Meeting agenda
To be filled out by proposer based on comments gathered during API review period
- Feedback needs to include the current position
- It should tell me when it's stuck. Should be a guess of some sort. Has it moved in a few timesteps?
- Specify in the request? Specify as a parameter?
- We should have a trajectory for the gripper. - Gunter
- But max force is more important, but this means that we definitely won't track the trajectory.
- Beta grippers may improve the min force.
- There's also different types of friction compensation. Consider these separately.
- Stu will follow up on friction with Gunter (possibly post M3)
- The desired behavior is often "grab with 10N"
- "Move until you touch something and the contact force reaches a certain level"
- Having to set a position for what "closed" means is not necessarily intuitive.
- Could be two actions: close/open and move to position
- Three options: move to position, move at force, move to position with force
- The force level "specifies" the trajectory ("constrains")
- Document: what max_force means don't limit force?
- max_force of 0 could actually have meaning: "move while the touch pad reads 0"
- Side note: if you have a model of what your friction is, you can estimate what your contact force actually is.
- Document: what units are the position in (meters, gap size)
- What does the action do when the gripper gets "stuck"?
- Should be a different action (Josh) because the position action should abort on not reaching the position, but the "just close" action should succeed when stopped.
- Like other setpoint actions, this action will no longer succeed/abort. Information on stuckness will be provided in the feedback.
- Feedback needs: stuck, reached end
- min_force: It's difficult for the controller to report when it's stuck or not if the max_force specified is below the minimum friction.
- Option: max_force should always be above the minimum friction. Should reject
- Really want to know "is the gripper touching something?"
- Best guess of if it's touching something?
- Option: best guess of the threshold, and it thresholds the min force itself
- Option: make the user figure it out.
- Option: have a calibration for determining static friction.
- Option: Test: is out velocity near 0?
- Stalled flag: not moving, not at setpoint, applying max effort
- Stu: head trajectory can abort, so shouldn't the head controller abort too???
Conclusion
- The gripper will be a setpoint-style action: It will never succeed or abort.
- max_force = 0 means you don't move. Negative numbers mean don't limit force
- Provide a min_force, below which the action rejects the goal
feedback:
bool stalled # Are we stuck? (likely contact) bool reached_position # Did we reach the desired position? float64 position float64 effort
Package status change mark change manifest)
Action items that need to be taken.
Major issues that need to be resolved