Closed Nicogene closed 9 months ago
Today I tried to export the urdf without the exportFrameInURDF
, we obviously miss the head_imu_0
frame but we have the imu_frame
link and the sensors seems oriented correctly.
<gazebo reference="head">
<sensor name="head_imu_0" type="imu">
<always_on>1</always_on>
<update_rate>100</update_rate>
<pose>0.009500000190735 0.133444 0.009299999999999996 -1.5707963267948963 1.5707963267948963 0.0</pose>
<plugin name="iCub_yarp_gazebo_plugin_IMU" filename="libgazebo_yarp_imu.so">
<yarpConfigurationFile>model://iCub/conf/gazebo_icub_inertial.ini</yarpConfigurationFile>
</plugin>
</sensor>
</gazebo>
<sensor name="head_imu_0" type="accelerometer">
<parent link="head"/>
<origin rpy="-1.5707963267948963 1.5707963267948963 0.0" xyz="0.009500000190735 0.133444 0.009299999999999996"/>
</sensor>
<gazebo reference="head">
<sensor name="head_imu_0" type="imu">
<always_on>1</always_on>
<update_rate>100</update_rate>
<pose>0.023453700190734995 0.20544400000000002 -0.023077900000000023 1.5707963267948997 -3.4914813388431334e-15 0.0</pose>
<plugin name="iCub_yarp_gazebo_plugin_IMU" filename="libgazebo_yarp_imu.so">
<yarpConfigurationFile>model://iCub/conf/gazebo_icub_inertial.ini</yarpConfigurationFile>
</plugin>
</sensor>
</gazebo>
<sensor name="head_imu_0" type="accelerometer">
<parent link="head"/>
<origin rpy="1.5707963267948997 -3.4914813388431334e-15 0.0" xyz="0.023453700190734995 0.20544400000000002 -0.023077900000000023"/>
</sensor>
So probably it is the exportFrameInURDF
is somehow problematic.
This PR fixes this problem:
Unfortunately the exportFrameInURDF
shadows the exportedFrames
option, this is due that we are using as key of the map the CREO name that is in common between the two options, then now the sensor is correctly oriented, but imu_frame
is missing.
On the other hand, imu_frame
has to be kept in the yaml in order to express the additional transformation
So, the frame name for the imu in the urdf is still head_imu_0
after this fix but now contains the addition transform, right?
cc @Nicogene
So, the frame name for the imu in the urdf is still
head_imu_0
after this fix but now contains the addition transform, right?cc @Nicogene
Exaclty
<link name="head_imu_0"/>
<joint name="head_imu_0_fixed_joint" type="fixed">
<origin xyz="0.009500000190735 0.133444 0.009299999999999996" rpy="-1.5707963267948961 1.570796326794896 0"/>
<parent link="head"/>
<child link="head_imu_0"/>
<dynamics damping="0.1"/>
</joint>
<link name="head_imu_0"/>
<joint name="head_imu_0_fixed_joint" type="fixed">
<origin xyz="0.023453700190734995 0.20544400000000002 -0.023077900000000023" rpy="1.5707963267948997 0 0"/>
<parent link="head"/>
<child link="head_imu_0"/>
<dynamics damping="0.1"/>
</joint>
Great, thank you!
Closing since now V2_5 and V2_6/7 have the frames oriented differently
Today @martinaxgloria and I noticed that the
imu_frame
disappeared when I made the PR inicub-models-generator
that exports the sensors frames:head_imu_0
took its place, but the problem is that this frame does not incorporate theadditionalTransformation
from the old imu frame (iCub v2.5) to the frame of the rfe.You can see that in iCub 2.5 and 2.7 they have the same orientation.
https://github.com/robotology/icub-models/blob/453d9ed52f01a8a92cf41a9cae14ddb669446d5c/iCub/robots/iCubGazeboV2_5/model.urdf#L986-L992
https://github.com/robotology/icub-models/blob/453d9ed52f01a8a92cf41a9cae14ddb669446d5c/iCub/robots/iCubGazeboV2_5/model.urdf#L2684
https://github.com/robotology/icub-models/blob/453d9ed52f01a8a92cf41a9cae14ddb669446d5c/iCub/robots/iCubGazeboV2_7/model.urdf#L986-L992
https://github.com/robotology/icub-models/blob/453d9ed52f01a8a92cf41a9cae14ddb669446d5c/iCub/robots/iCubGazeboV2_7/model.urdf#L2700
If we read from the real imu and compare what we read in simulation we should notice this discrepancy
cc @traversaro @pattacini