imu_frame not generated in simmechanics models

[traversaro]

No description provided.

[nunoguedelha]

@traversaro I actually just noticed now this issue in the URDF models I'm generating.

[nunoguedelha]

@traversaro, I found the origin of the problem in yaml parameter files and a potential bug in the script simmechanics_to_urdf.

In iCubGenova02_simmechanics_options.yaml and similar files:

the attribute defining the section for link sensors was IMUs instead of sensors, as per documentation section YAML Parameter File. The sensor type (mandatory) and the rate were missing.

In simmechanics_to_urdf script:

As documented here, the sensors parameters should also be defined for iDynTree under the <sensor> tag, and actually the script builds the chunk off data to add to the URDF but the actual line for adding is missing in the script.

Pushing the fixes for letting you review.

[nunoguedelha]

@traversaro , the methodology described here doesn't mention the IMU, and it seems that iDynTree doesn't currently require the <sensor> tag for this particular sensor. But in any case this will be necessary for the accelerometers, and it would be simpler to handle all link sensors the same way, right?

[traversaro]

Regarding the sensors stuff in iDynTree .
Currently we are just modeling three type of sensors (http://wiki.icub.org/codyco/dox/html/idyntree/html/namespaceiDynTree.html#ad291b88efdf5262d744d33f642daf8b9) i.e. gyroscopes, accelerometers and six axis force torque sensors. I was not leaning to include the imu in this list, as from a modeling point of view it is a composite sensors composed of an accelerometer and a gyroscope, that also outputs the result of an onboard estimation (for more on this see robotology/idyntree#30).

However the only place in which the software currently working on the robot is using the imu information is in the estimation of external forces/joint torques , for propagate the kinematics (proper acceleration, velocities) of the links. This is done using the updateKinematicsFromFloatingBase method, that only needs to have a frame (not a sensor) in the model named imu_frame (or any other name specified in the conf files).

[traversaro]

Fixed by #19 .

[nunoguedelha]

Considering your last comment, I suppose it's ok if I set the IMU sensorName to "imu" instead of the previous "imu_frame". Let me know if not.

[traversaro]

I think it is not a big problem, we just need to remember to change it also on the conf files. However if we change the name we can find a more meaningful name. I like imu_xsens_mtx, but we are changing it to the bosch bno055 in the newest robots, so it is not a great name... imu_head?

[nunoguedelha]

Yes, or even better, head_imu, to be consistent with the naming convention of the MTB accelerometers ("link"_"sensor_label").