As the frame element was hardcoded to be child, then the pose element in SDF or origin in URDF, that describe the location of the sensor w.r.t. to the child link frame, was not specified and so default to the identity value. This made sense because this transform is only considered (and only for the orientation part) if the frame tag is equal to sensor .
Due to the specific needs of generation of the new iCub3 model, it could make sense to expose these parameters. In particular, this would permit to have all the frame of a given limb to be all parallel in the 0 configuration, without the need to have a single link (the child link of the FT sensor) to have a different orientation to match the one of the sensor.
The
forceTorqueSensors
option in the YAML file permits to export the FT sensor information in two ways:sensor
tag with similar semantics to the sensor tag in SDF (see https://github.com/robotology/simmechanics-to-urdf/blob/master/simmechanics_to_urdf/firstgen.py#L1843).In both those cases, however some parameters that describe the sensor are hardcoded:
frame
element has been hardcoded to have thechild
value, while it could also accept thesensor
orparent
values (see http://gazebosim.org/tutorials?tut=force_torque_sensor&cat=sensors#%3Cframe%3E)frame
element was hardcoded to be child, then thepose
element in SDF ororigin
in URDF, that describe the location of the sensor w.r.t. to the child link frame, was not specified and so default to the identity value. This made sense because this transform is only considered (and only for the orientation part) if the frame tag is equal tosensor
.Due to the specific needs of generation of the new iCub3 model, it could make sense to expose these parameters. In particular, this would permit to have all the frame of a given limb to be all parallel in the 0 configuration, without the need to have a single link (the child link of the FT sensor) to have a different orientation to match the one of the sensor.
@Nicogene @prashanthr05