Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FT "real" pose #11

Closed
EnricoMingo opened this issue Nov 3, 2013 · 3 comments
Closed

FT "real" pose #11

EnricoMingo opened this issue Nov 3, 2013 · 3 comments
Assignees

Comments

@EnricoMingo
Copy link
Collaborator

As titled.

@ghost ghost assigned arocchi Nov 3, 2013
@traversaro
Copy link
Contributor

Ok, I'll reply here from robotology/gazebo-yarp-plugins#21.
@EnricoMingo : yes, in the simulator the ft are specified as the force/torque exchanged thought a joint, however the real sensor for mechanical reason is not (as far as I know) attached to a joint, so it outputs the force/torque transmitted from one part of the link of the link to another (if one part of the link is negligible, then it can be considered as the force/torque exerted thought the joint..

@arocchi
Copy link

arocchi commented Nov 6, 2013

I actually modified the pose of the FT sensor to reflect the real pose (which should have forces/torques reading frame 6.5 cm below the joint axis, and centered with respect to the "center" of the joint axis).
Regarding the way this affects the simulator, at the moment I added the real pose in the coman.gazebo.wtf, so that the pose gets read from the fakebotFTsensor gazebo plugin implemented in https://github.com/EnricoMingo/gazebo_yarp_plugins/ which takes care of transforming the reading from the joint frame of reference to the sensor frame of reference.

In the long run, we should carefully evaluate how to proceed:

  • should we also take into account the mass of the sensor? At the moment, the inertial properties of foot and sensor are treated as a single link in the simulator, meaning the sensor has a bias deriving from its own mass (around 280g, with the foot at around 404g)
  • should the correct pose and the inertial properties of the sensor be taken care of by the urdf or by the plugin? I already separated the mass of the sensor from that of the foot, and modified accordingly the coman_robot.urdf.xacro. I also added, in the coman.gazebo.wtf, the inertial properties of the sensing element. The values for the inertia tensor are approximated, but in any case these modifications are still marked as "WIP", that is the .urdf modifications won't appear in the .sdf, and the .wtf entries regarding the sensing mass are not read (nor planned to be read, ATM) by the fakebotFTsensor plugin. The reason the pose and inertia properties are at the moment marked as a WIP in the .urdf (apart from the fact that I didn't bother creating a branch for this, and that the issue only talks about FT position, not bias) is that, by separating the two links (sensor and foot) and putting the sensor in between (which needs to be attached to a joint, which cannot be of type "fixed" but "revolute", since the "fixed" joint does not really exist in the sdf, but is just an abstraction of the urdf) we obtain an underactuated system (that is, an additional joint which the yarp gazebo controlboard sees as an actuated joint, even though it has 0 velocity, effort and configuration limits), This complicates things a little bit, and the yarp gazebo controlboard should be modified accordingly (see Underactuated system support for the controlboard robotology/gazebo-yarp-plugins#29 ). The solution to this problem will be probably taken care of when the elastic transmission gets added into the model.

@arocchi arocchi closed this as completed Nov 6, 2013
@arocchi arocchi mentioned this issue Nov 6, 2013
@traversaro
Copy link
Contributor

Just for reference: link to the gazebo bug to introduced fixed joints: https://bitbucket.org/osrf/gazebo/issue/618/add-option-to-disable-auto-fixed-joint .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants