Closed prashanthr05 closed 3 years ago
I guess this is what is done on iCub2.5 https://github.com/robotology/icub-models/blob/05e4e60ed08937fd292e34dd81119a0e7d78c7f6/iCub/robots/iCubGazeboV2_5/model.urdf#L527-L532
Can you provide a link to your modifications?
Can you provide a link to your modifications?
I have it here for the time being.
Looks like the origin for the collision geometry was modified in https://github.com/robotology/icub-models/blob/05e4e60ed08937fd292e34dd81119a0e7d78c7f6/iCub/robots/iCubGazeboV2_5/model.urdf#L527-L532
I hope this was not done by trial-and-error?
Can you try to put the robot fixed in the air and visualize the collisions?
I hope this was not done by trial-and-error?
This is specified in https://github.com/robotology/icub-model-generator/blob/master/simmechanics/CMakeLists.txt#L97 that was added in https://github.com/robotology/icub-model-generator/pull/85 .
To simplify the debug, I strong suggest to temporary disabled the visual meshes, so you would see just simplified mesh that you add. For the dimension of the box and the placement, I suggest to use as a reference the location of the l_sole
frames, as I imagine was done for iCub 2.5 .
I hope this was not done by trial-and-error?
This is specified in https://github.com/robotology/icub-model-generator/blob/master/simmechanics/CMakeLists.txt#L97 that was added in robotology/icub-model-generator#85 .
I was wondering about the choice and source of the values in
which is different from,
but seems to be the same as,
which is different from,
Why they should be similar? The origin of the box is placed in the center of the box (see http://wiki.ros.org/urdf/XML/link) while the origin of the visual mesh is arbitrary.
To simplify the debug, I strong suggest to temporary disabled the visual meshes, so you would see just simplified mesh that you add. For the dimension of the box and the placement, I suggest to use as a reference the location of the
l_sole
frames, as I imagine was done for iCub 2.5 .
I read this only now. Understood.
With @FabioBergonti, we modified the visual and collision geometries for all the feet links using data from the CAD,
<link name="r_foot_front">
...
<visual>
<origin xyz="0.0 0.0 0.003" rpy="0 0 0"/>
<geometry>
<box size="0.117 0.100 0.006"/>
</geometry>
...
</visual>
<collision>
<origin xyz="0.0 0.0 0.003" rpy="0 0 0"/>
<geometry>
<box size="0.117 0.100 0.006"/>
</geometry>
</collision>
</link>
On loading the model, we see | View 1 | View 2 |
---|---|---|
Great @prashanthr05! From the gif
it seems a little tilted. Is it only my impression? You can also try to use the fixed
version to look at the feet from below
Great @prashanthr05! From the
gif
it seems a little tilted. Is it only my impression? You can also try to use thefixed
version to look at the feet from below
It is indeed tilted because of my poor camera skills ;D.
I tried loading the fixed
version in vain. It keeps falling to the ground.
The SDF format seems to be the same as fixed models in icub-gazebo
, while those in icub-gazebo
remain fixed, instead those in icub-models
don't. Is it just me who is facing this?
This seems to be related to the base_link / root_link change .
This seems to be related to the base_link / root_link change .
Wow, such a memory! I am going to check this. Thanks, @traversaro !
I tried loading the fixed version in vain. It keeps falling to the ground. The SDF format seems to be the same as fixed models in icub-gazebo, while those in icub-gazebo remain fixed, instead those in icub-models don't. Is it just me who is facing this?
This seems to be related to the base_link / root_link change .
I confirm. Changing the fixed joint child from base_link
to root_link
, makes it work.
<joint name="fixed_base" type="fixed">
<parent>world</parent>
<child>iCub::root_link</child>
</joint>
With the fixed model, | View 1 | View 2 | View 3 |
---|---|---|---|
I will open relevant PRs in the icub-model-generator
.
I tried loading the fixed version in vain. It keeps falling to the ground. The SDF format seems to be the same as fixed models in icub-gazebo, while those in icub-gazebo remain fixed, instead those in icub-models don't. Is it just me who is facing this?
This seems to be related to the base_link / root_link change .
I confirm. Changing the fixed joint child from
base_link
toroot_link
, makes it work.<joint name="fixed_base" type="fixed"> <parent>world</parent> <child>iCub::root_link</child> </joint>
This has already been done in https://github.com/robotology/icub-models/pull/59.
Indeed, also to me the old fixed iCubV3
falls down, but the iCubGazeboV3
does not.
To introduce the changes of assigned collision geometries from here to the URDF model through icub-model-generator
, I will list the steps I will follow, please correct me wherever applicable
generate_icub_simmechanics
macro.@ASSIGNED_COLLISION_GEOMETRIES@
in ICUB_3_all_options_gazebo.yaml.
Which will actually be handled by simmechanics-to-urdf
.To introduce the changes of assigned collision geometries from here to the URDF model through
icub-model-generator
, I will list the steps I will follow, please correct me wherever applicable
- Introduce an option for ICUB3 in the cmake options here.
- Similar to what is done for ICUBPLUS robots of choosing between two collision geometries, I add a conditional block for the ICUBTHREE collision geometries and pass that option to the
generate_icub_simmechanics
macro.- Further, similar to what is done for ICUB25 models in yaml options I add the relevant
@ASSIGNED_COLLISION_GEOMETRIES@
in ICUB_3_all_options_gazebo.yaml. Which will actually be handled bysimmechanics-to-urdf
.
@pattacini @Nicogene what do you think?
Tested locally with changes made in https://github.com/prashanthr05/icub-model-generator/commit/d151943dad14ea87a9e644184a86d2dcce1828fa and https://github.com/prashanthr05/icub-model-generator/commit/8d08a83445af8216f912d49bdebb404e8aa32b9a
The diff between the files with the introduced option and without (changes for all the foot_rear/front links),
< <origin xyz="0.0 0.0 0.003" rpy="0.0 0.0 0.0"/>
---
> <origin xyz="0.010700000000000012 -0.06475000000001183 0.9464469999999995" rpy="0 0 -1.57079632679"/>
250c250
< <box size="0.117 0.1 0.006"/>
---
> <mesh filename="package://iCub/meshes/simmechanics/sim_icub3_l_foot_rear_prt.stl" scale="0.001 0.001 0.001"/>
283c283
< <origin xyz="0.0 0.0 0.003" rpy="0.0 0.0 0.0"/>
---
> <origin xyz="-0.10854999999999998 -0.06475000000001183 0.9464469999999995" rpy="0 0 -1.57079632679"/>
285c285
< <box size="0.117 0.1 0.006"/>
---
> <mesh filename="package://iCub/meshes/simmechanics/sim_icub3_l_foot_front_prt.stl" scale="0.001 0.001 0.001"/>
1202c1202
< <origin xyz="0.0 0.0 0.003" rpy="0.0 0.0 0.0"/>
---
> <origin xyz="-0.10850000000000011 0.06484999999993908 0.9464470000000105" rpy="0 0 -1.57079632679"/>
1204c1204
< <box size="0.117 0.1 0.006"/>
---
> <mesh filename="package://iCub/meshes/simmechanics/sim_icub3_r_foot_front_prt.stl" scale="0.001 0.001 0.001"/>
1230c1230
< <origin xyz="0.0 0.0 0.003" rpy="0.0 0.0 0.0"/>
---
> <origin xyz="0.010749999999999881 0.0648499999999391 0.9464470000000105" rpy="0 0 -1.57079632679"/>
1232c1232
< <box size="0.117 0.1 0.006"/>
---
> <mesh filename="package://iCub/meshes/simmechanics/sim_icub3_r_foot_rear_prt.stl" scale="0.001 0.001 0.001"/>
P.S. I had to test by disabling GENERATE_DH_MODELS
and tests
. See https://github.com/robotology/icub-model-generator/issues/161 and https://github.com/robotology/icub-model-generator/pull/159
cc @traversaro
P.S. I had to test by disabling GENERATE_DH_MODELS and tests. See robotology/icub-model-generator#161 and robotology/icub-model-generator#159
Yes, that is expected.
Given the merge of https://github.com/robotology/icub-model-generator/pull/165, shall we close this issue?
Ok!
I am trying to change the feet meshes to replace it with simplified geometry.
They all have the same dimensions and are in mm (I believe!).
However, in the URDF there seems to be a
scale
option for the mesh that scales the mesh's axis-aligned-bounding-box, according to http://wiki.ros.org/urdf/XML/link. There's no further explanation.I believe the scale is simply a unit conversion from millimeters to meters.
So I made the changes only to the
collision
part of the feet asBut looks like, there's something I am missing here, which can be seen as soon as we load the model,
Anyone's got advice/prior experience on this? cc @nunoguedelha @traversaro @S-Dafarra @GiulioRomualdi