However recently I was porting some estimation software to the Walkman robot ( https://www.walk-man.eu/ ) and I noticed that in building their SDF they choose a different option: they modeled their F/T sensors as sensors measuring the force transmitted over a non-fixed joint. The Walkman model is not public, but then I noticed that the same choice was done in the SDF of the Valkyrie robot, see for example:
Modelling the F/T sensor as attached to a non-fixed joint can make sense if the mass of the flange connecting the F/T sensor with its revolute joint is small enough and its weight and dynamical effect can be safely disregarded. However the presence of a non-fixed joints constraints the joint frame origin to be on the joint's revolution axis, and prevents to correctly simulate a sensor whose origin does not lie on the revolution axis. As far as I understood is the case in Walkman/Valkyrie, and the authors of those models tried to encode the position offset between the joint frame and the sensor frame using the sensor pose, apparently ignoring that the position part would be ignored.
I don't know if there is an easy way to fix this issue in these models. Two possible ways can be:
create a new value for the frame tag: a sensor_posandrot (better name preferable) that means that the sensor orientation is used to express the wrench, and the sensor origin is used as the point with respect to which the torque is expressed,
or considering that any model with a non-zero sensor position offset for a force_torque sensor is broken, we can just modify the definition of <frame>sensor</frame> to "the sensor orientation is used to express the wrench, and the sensor origin is used as the point with respect to which the torque is expressed".
Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).
TL; DR: There is bug in Valkyrie F/T sensor model that could cause up to 20 Nm of error between the simulated F/T measure and the real one.
Back in https://bitbucket.org/osrf/gazebo/issues/940/force-torque-sensor-forcetorquesensorcc , the semantics for force_torque sensor pose tag was defined.
In particular it was decided (probably for back-compatibility) that the point with respect to which the measured torque is expressed was always the origin of the "joint" frame, regardless of the sensor pose and of the frame tag (see https://bitbucket.org/osrf/gazebo/issues/940/force-torque-sensor-forcetorquesensorcc#comment-9473056).
Personally I was ok with this, because I always modeled six axis force torque sensors as "fixed" joints (as described in https://bitbucket.org/osrf/gazebo/issues/940/force-torque-sensor-forcetorquesensorcc#comment-9485945), for which the origin of the joint frame can be freely assigned without any other constraint.
However recently I was porting some estimation software to the Walkman robot ( https://www.walk-man.eu/ ) and I noticed that in building their SDF they choose a different option: they modeled their F/T sensors as sensors measuring the force transmitted over a non-fixed joint. The Walkman model is not public, but then I noticed that the same choice was done in the SDF of the Valkyrie robot, see for example:
See https://gitlab.com/nasa-jsc-robotics/val_description/blob/master/model/robots/common/xacro/sensors/ati_force_torque.xacro#L16 .
As in the case of the Walkman, even here the
force_torque
sensor is instantiated with a non-zero origin_xyz inSee https://gitlab.com/nasa-jsc-robotics/val_description/blob/master/model/robots/common/xacro/leg/leg.xacro#L173 .
Modelling the F/T sensor as attached to a non-fixed joint can make sense if the mass of the flange connecting the F/T sensor with its revolute joint is small enough and its weight and dynamical effect can be safely disregarded. However the presence of a non-fixed joints constraints the joint frame origin to be on the joint's revolution axis, and prevents to correctly simulate a sensor whose origin does not lie on the revolution axis. As far as I understood is the case in Walkman/Valkyrie, and the authors of those models tried to encode the position offset between the joint frame and the sensor frame using the sensor pose, apparently ignoring that the position part would be ignored.
I don't know if there is an easy way to fix this issue in these models. Two possible ways can be:
create a new value for the
frame
tag: asensor_posandrot
(better name preferable) that means that the sensor orientation is used to express the wrench, and the sensor origin is used as the point with respect to which the torque is expressed,or considering that any model with a non-zero sensor position offset for a
force_torque
sensor is broken, we can just modify the definition of<frame>sensor</frame>
to "the sensor orientation is used to express the wrench, and the sensor origin is used as the point with respect to which the torque is expressed".