search

scpeters-test / sdformat

Simulation Description Format (SDF) parser and description files.
http://sdformat.org
Other
1 stars 0 forks source link

Position part of force_torque sensor pose is ignored and this may be confusing or impractical #130

Open scpeters-test opened 7 years ago

scpeters-test commented 7 years ago

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:

    <gazebo reference="${joint_to_attach_sensor_to}">
      <sensor name="${sensorName}" type="force_torque">
        <pose>${origin_xyz} ${origin_rpy}</pose>
        <sensor_number id="${sensor_number}" />
        <node id="${sensor_node}" />
        <api name="${sensor_api}" />
        <always_on>true</always_on>
        <update_rate>500.0</update_rate>
        <force_torque>
          <frame>sensor</frame>
          <measure_direction>parent_to_child</measure_direction>
        </force_torque>
        </sensor>
    </gazebo>

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 in 

<xacro:ati_force_torque_sensor sensorName="${prefix}FootSixAxis"
                               parentLink="${AnkleRollLinkName}"
                               joint_to_attach_sensor_to="${AnkleRollJointName}"                          
                               origin_xyz="0.0215646 0.0 -0.051054"                        
                               origin_rpy="3.14 0.0 0.0"                
                               sensor_number="${ATI_serial_number}"                                
                               sensor_node="${ATI_node}"                           
                               sensor_api="${ForceTorqueSensorApi}" />

See 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:

scpeters-test commented 7 years ago

Original comment by Silvio Traversaro (Bitbucket: traversaro).

scpeters-test commented 7 years ago

Original comment by Silvio Traversaro (Bitbucket: traversaro).

scpeters-test commented 6 years ago

Original comment by Silvio Traversaro (Bitbucket: traversaro).