effort feedback - "80% solution"#97
Open
josephcoombe wants to merge 6 commits into
Open
Conversation
added 6 commits
July 6, 2018 11:54
…revious SetForce value.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A few things I learned:
GetForceTorque() returns the net force-torque experienced by the Joint (e.g. for a X5-9 holding an arm at horizontal at steady-state, GetForceTorque() will return ~0.0 since the motor effort is being counteracted by the gravitational force). This is - as far as I can tell - not what we want for force-feedback control.
GetForce() simply returns the last torque applied to the Joint via SetForce. Using GetForce() is the 80% (cop-out) solution in my book - based off my tests. Now when playing with force-control using the real actuators, I noted that they are responsive to external forces. E.g. if a pendulum arm is partially lifted since the motor is set to apply a -1.4 N/m ("upwards") torque and I push down on the arm, it will temporarily reduce its torque output to compensate for the transient change in torque measured by the motor. Obviously GetForce() doesn't give us any of this, but GetForceTorque() might. See video below. Perhaps we could use the GetForce + (-GetForceTorque()) readings.
Videos:
GetForceTorque (dotted line) vs GetForce (solid line):
https://drive.google.com/file/d/15vdITw2A4socnTJ0Ghwu5QT8UpQxQMBn/view?usp=sharing
force-torque-plugin readings while moving a joint (notice these aren't too horribly noisy):
https://drive.google.com/file/d/1HFzK05pN0u0opxflZ4954Bq0c4Co-UQ9/view?usp=sharing
force-torque-plugin readings on extra transmission-to-output revolute joint with lower=0 upper=0 limits (Transient spikes would have to be clipped+filtered out. I think the noise at the jt limits can be reduced/eliminated by changing SQR from 1.3 (default) to 1.0):
https://drive.google.com/file/d/1FH6YU3eFOHYznW7Ddt93WtBPnRmxVyWJ/view?usp=sharing
Reference:
https://bitbucket.org/osrf/gazebo/issues/1975/changed-the-calculation-of-force-torque-on
https://bitbucket.org/osrf/gazebo/src/default/gazebo/sensors/ForceTorqueSensor.cc
https://bitbucket.org/osrf/gazebo/pull-requests/2110/changed-the-calculation-of-force-torque-on/diff
https://bitbucket.org/osrf/gazebo/src/default/gazebo/physics/ode/ODEJoint.cc
https://bitbucket.org/osrf/gazebo/pull-requests/735/create-spring-damper-in-joints-issue-845/diff#comment-671487 (Simulating SEA joints using an active joint and a passive joint - with upper & lower position limits set to 0)
robotology/gazebo-yarp-plugins#192