robotology / icub-models-generator

Resources and programs to generated models (URDF, SDF) of the iCub robot

icub-models-generator

Resources and programs to generate models (URDF, SDF) of the iCub robot. The models automatically generated by the software and the resources in this repository are available at https://github.com/robotology/icub-models .

Note: this repository is meant to streamline the process of producing iCub URDF/SDF models by iCub mantainers. It is not meant to be used directly by users of iCub. For offical info on the kinematic parameters of the iCub, please see the documentation in iCub's documentation.

Usage

To generate the models, first of all that you have pixi installed.

Then, clone the repo and generate and the models via the test_generated_models pixi task:

cd ~
git clone https://github.com/robotology/icub-models-generator
cd icub-models-generator
pixi run test_generated_models

If you want to generate the models in a local clone of icub-models, set the ICUB_MODELS_SOURCE_DIR environment variable to the location of the icub-models local folder, and run the copy_models_to_icub_models pixi task:

cd ~
git clone https://github.com/robotology/icub-models
export ICUB_MODELS_SOURCE_DIR=`pwd`/icub-models
cd icub-models-generator
pixi run copy_models_to_icub_models

For example, if you already have a icub-models copy as part of a robotology-superbuild installation located in /usr/local/src/robotology-superbuild, to generate the models there you can do the following:

export ICUB_MODELS_SOURCE_DIR=/usr/local/src/robotology-superbuild/src/icub-models
cd icub-models-generator
pixi run copy_models_to_icub_models

Pipelines

Currently, it is possible to generate iCub models by means of two different pipelines.

1. The generation is achieved by using Denavit Hartenberg parametsrs based on robot-model hardcoded data in the iKin/iDyn source code, and meshes postprocessed by ISIR at UPMC, Paris, available in dh directory.

2. The generation is achieved from CAD models converted to simmechanics file, as described in https://github.com/icub-tech-iit/cad-mechanics-public/wiki/Creo-mechanism-to-URDF, available in the simmechanics directory.

As the two pipeline process data from different sources, the link frames are not guaranteed to have the same orientation or location across different models. The only frames (that are represented in URDF as massless links) whose position is guaranteed to be consistent across different models are the one documented in https://icub-tech-iit.github.io/documentation/icub_kinematics/icub-model-naming-conventions/icub-model-naming-conventions/ .

Both generation pipelines are still in a work in progress state, and several issues need to be properly solved, e.g.:

• Hands and eyes are not generated #29

icub-models-generator's Issues

Use the generated model in Gazebo

In this issue I want to track and recap the efforts done (mainly by @nunoguedelha) and what's missing in the generation chain to let these model work in Gazebo.

• Creating a first version that simulates (#49). These changes for now have been applied manually to the icub-models repository (robotology/icub-models#2)
• Install the model.config for all the robots (robotology/icub-models#3)
• Enable all the inertial sensors (wrapped in <sensor> tag). Right now gazebo crashes without giving any error (#54)
• Handle the name of the robot (robotology/simmechanics-to-urdf#24)
• Include the snippet at the bottom (#55, #54, robotology/simmechanics-to-urdf#25)
• Handling the small inertias. Two ways for this: increasing the numbers that are extremely low, ideally in an automatic way, or exploiting the implicit damping like reported in #24. Solved by #71.
• Integrate FT sensors plugins for Gazebo (robotology/simmechanics-to-urdf#32, #72)
• Allow using generated models within the composed models in icub-gazebo-wholebody repo (initial PR robotology-legacy/icub-gazebo-wholebody#12 and fix robotology-legacy/icub-gazebo-wholebody#15)
• Spawn the auto-generated iCub raw models in the composite Gazebo models (iCub fixed, iCub on seesaw, ...) (robotology-legacy/icub-gazebo-wholebody#16)
• Fix the model generation chain in order to be able to insert directly in Gazebo the URDF models from the repo icub-models (such models have a default pose and joint configuration and appear hovering 1mm above the ground) => #79
• install configuration files only for iCubGazeboV2_5, as all other models are expected not to work (as per @traversaro recommendation) => robotology/icub-models#11

Other pending issues imported from robotology/icub-models#7:

• Both the wrist yaw joints go in hardware fault. Apparently the position control is unstable and it brings the joints toward the limits => #74.
• The meshes in the foot should be substituted with a simpler primitive shapes (box or four spheres) => #77

cc @nunoguedelha @traversaro @DanielePucci

---

<gazebo reference="l_foot">
    <collision>
        <surface>
            <bounce>
                <restitution_coefficient>0</restitution_coefficient>
                <threshold>100000</threshold>
            </bounce>
        </surface>
    </collision>
    <maxContacts>4</maxContacts>
    <kp>18000000</kp>
    <kd>100</kd>
    <maxVel>100</maxVel>
    <minDepth>0.0001</minDepth>
    <mu1>1</mu1>
    <mu2>1</mu2>
    <fdir1>0 0 0</fdir1>
</gazebo>
<gazebo reference="r_foot">
    <collision>
        <surface>
            <bounce>
                <restitution_coefficient>0</restitution_coefficient>
                <threshold>100000</threshold>
            </bounce>
        </surface>
    </collision>
    <maxContacts>4</maxContacts>
    <kp>18000000</kp>
    <kd>100</kd>
    <maxVel>100</maxVel>
    <minDepth>0.0001</minDepth>
    <mu1>1</mu1>
    <mu2>1</mu2>
    <fdir1>
<gazebo>

wrong URDF fine calibration configuration

When putting the urdf-iCub in the ``fine calibration'' configuration (http://wiki.icub.org/wiki/ArmFineCalibration) there is an apparent error in the (left and right) shoulder joint position. This is probably due to a wrong alignment of the torso with the arms.

Missing raw STL for Simmechanics generated models

@bmagyar correctly pointed out that currently the SimMechanics generated models refer to meshes of the type model://iCubGenova02/meshes/dae/sim_sea_2-5_root_link_prt.dae.

This file names are generated by this value : https://github.com/robotology-playground/icub-model-generator/blob/master/simmechanics/data/icub2_5/ICUB_2-5_BB_simmechanics_options.yaml#L4 of the filenameformatchangeext parameter of simmechanics-to-urdf. The actual meshes they are referring to (the original name can be obtained by removing the filenameformatchangeext option, or checking the content of the SimMechanics file) are the .STL generated by the SimMechanics Link Creo exporter. Those files are enormous, and we are not committing them directly in icub-model-generator/simmechanics/data/icub2_5/ to avoid to bloat the repo.
The ideal situation would be to have a semiautonomous pipeline to convert this meshes in something useful, but for the moment providing them in someway in this repo is the basic state to make the generate models actually useful.

IMU v1 & v2.5

Currently all the IMU are placed using v2 kinematics, v1 has a slightly different kinematics that could be necessary to consider.

In Gazebo both the wrist yaw joints go in hardware fault

As reported by @S-Dafarra:

Both the wrist yaw joints go in hardware fault. Apparently the position control is unstable and it brings the joints toward the limits. I tried to reduce the gains, but it did not work. But changing the PIDs does the job! Setting 0 for the derivative and the integral part seems to be enough.

Changes shall be applied to the configuration ini files in icub-model-generator/simmechanics/data/icub2_5/conf.

Find a clean way to generate a simmechanics-generated model with slightly different kinematics

For example, it will be useful to generate a Simmechanics-based model with a kinematics of the arm modified to have a v1 arm (see #50) or a v2 head with a v2.5 IMU (see #2). For this kind of modifications, I think it is relatively reasonably to assume that the inertial parameters do not change.

Problems in icub2_5 simmechanics model

We used the most recent version of generated model of the iCubGenova02 in robotology-legacy/yarp-wholebodyinterface@867ba03 and robotology-legacy/yarp-wholebodyinterface@fe3d454 .

We found the following problems:

• the direction of the axis r_wrist_prosupwas wrong. This means that we also need to check all other wrist joints, and update the table in http://wiki.icub.org/wiki/ICub_Model_naming_conventions#Joint_additional_information and the tests in https://github.com/robotology-playground/icub-model-generator/blob/master/tests/icub-model-test.cpp#L230 ( #41 ) .
• the frame of the xsens imu is imu instead of imu_frame. While we probably need to have a better name for this, for the time being we should fix the generation of the models, and then do a proper migration ( #40 ) .

Handle colors in sdf files

Fixing #56 should be enough to handle the urdf side, adding something similar to the model:

simmechanics:

<MaterialProp>
    <color>0.666667,0.666667,0.666667</color>
    <transparency>0</transparency>
</MaterialProp>

urdf:

<material name="r_forearm_color">
    <color rgba="0.666667 0.666667 0.666667 1.0"/>
</material>

However, this doesn't seem to be enough for Gazebo, which uses OGRE colors. In my opinion using the default colors is not general enough, and it would require setting a kind of map between what is exported from the CAD (or specified in the simmechanics file) to the OGRE color keywords. One of the possible option to overcome this would be adding into the generator toolchain the possibility to generate a custom color file and export it where gazebo can find it.

Eventually, these lines are required in the urdf for importing colors in gazebo:

<gazebo reference="r_forearm">
    <visual>
        <material>
            <script>
                <uri>file://media/myfile.material</uri>
                <name>r_forearm_color</name>
            </script>
        </material>
    </visual>
</gazebo>

The resulting sdf would be:

<material>
    <script>
        <uri>file://media/myfile.material</uri>
        <name>r_forearm_color</name>
    </script>
</material>

Note that the media folder is relative to GAZEBO_RESOURCE_PATH.

cc @traversaro @nunoguedelha

Resources:

• Materials: Using proper colors and textures
• Building a Visual Robot Model with URDF from Scratch

wrong joint limits in generated files

It seems that the joint limits for the two hip-roll joints are wrong. See for instance the left-hip-roll joint of generated/gazebo_models/iCubGenova03/iCubGenova03.sdf:

<joint name='l_hip_roll' type='revolute'>
      <child>l_hip_2</child>
      <parent>l_hip_1</parent>
      <axis>
        <xyz>-1 2.65359e-06 7.34641e-06</xyz>
        <limit>
          <lower>-2.07694</lower>
          <upper>0.296706</upper>
          <effort>84</effort>
          <velocity>100</velocity>
        </limit>
        <dynamics>
          <damping>0.1</damping>
        </dynamics>
        <use_parent_model_frame>1</use_parent_model_frame>
      </axis>
    </joint>

and compare the joint limits with the one of the model of the model /icub/icub.sdf in the icub_gazebo repository:

        <joint name='l_hip_roll' type='revolute'>
            <child>l_hip_2</child>
            <parent>l_hip_1</parent>
            <axis>
                <xyz>-1 5.30716e-06 1.26536e-05</xyz>
                <limit>
                    <lower>-0.34</lower>
                    <upper>1.6707963268</upper>
                    <effort>10000</effort>
                    <velocity>100</velocity>
                </limit>
                <dynamics>
                    <damping>0.1</damping>
                </dynamics>
            </axis>
        </joint>

The problem is the same for the right-hip roll and for the iCubGenova01 model.

Simplifying the sensor frame "pose" information in the URDF

@traversaro , as soon as the accelerometers sensor data will be integrated in the URDF, we will get 3 equal instances of each sensor frame pose:

1. in the <sensor> tag
2. in the <gazebo> tag
3. in the fake link frame attached to the reference frame through a fixed joint.

If I understood well, the fake link frame is useful for iDynTree, such that we don't need another pose information under the respective tag. We could have, for instance, for a given sensor:

  <link name="l_forearm_mtb_acc_1b9"/>
  <joint name="l_forearm_mtb_acc_1b9_fixed_joint" type="fixed">
    <origin xyz="0.0595957174403 0.0596569 -0.0205995080872" rpy="1.76682134218 0.261099829847 3.08752548202"/>
    <parent link="l_elbow_1"/>
    <child link="l_forearm_mtb_acc_1b9"/>
    <dynamics damping="0.1"/>
  </joint>
  ...
  <gazebo reference="l_forearm_mtb_acc_1b9">
    <sensor name="l_forearm_mtb_acc_1b9" type="imu">
      <always_on>1</always_on>
      <update_rate>100</update_rate>
      <pose>0.0 0.0 0.0 0.0 0.0 0.0</pose>
    </sensor>
  </gazebo>
  ...
  <sensor name="l_forearm_mtb_acc_1b9" type="accelerometer">
        <pose>0.0 0.0 0.0 0.0 0.0 0.0</pose>
    <parent link="l_forearm_mtb_acc_1b9"/>
  </sensor>

or even remove the <pose> tag in <sensor> and <gazebo>. It would make a lighter URDF with less repetition and less confusion. What do you think?

Generate models with eyes

Spin-off of #29 .

Investigate if Travis can be used to automatically generate and commit the models

cc @fiorisi

Generate gazebo models

We need to generate a Gazebo model for each major revision of the iCub, see robotology-legacy/icub-gazebo-legacy#16 .

*_upper_leg_back_contact frames

@gabrielenava defined and added to the simmechanics generated models the (r/l)_upper_leg_contact frames, that are convenient for experiments in which the robot is sitting on its legs. After a day, I suggest to renamed this frames to *_upper_leg_back_contact to avoid confusion.

These frames work fine, but they have been just committed to the robot models contained in yarp-wholebodyinterface , and I will list here the things that need to be addressed to have them properly integrated in the model generation pipeline.

• Document their location in http://wiki.icub.org/wiki/ICub_Model_naming_conventions#URDF_frames,
• Add them to Creo model committed in the hardware repository and regenerate the shrinkwraps for the upper_leg links and then regenerate the simmechanics xml,
• Commit the generated file in icub-model-generator and regenerated all the URDFs ,
• Copy the generated models in yarp-wholebodyinterface.

cc @DanielePucci

Add iCubGenova04

It is a classical iCub 2.5 with backpack, so it should be simple.

optimization of forearm skin position files - slighltly different results for left vs. right

The output of https://github.com/robotology-playground/icub-model-generator/blob/master/simmechanics/scripts/generate_taxels_3d_positions.py
for the left vs. right forearm is slightly different. The two forearms should be identical - the only difference being that the reference frame is different. However, under careful inspection, the pos in x-axis have slightly different values.

See:

• https://github.com/robotology/icub-main/blob/master/app/skinGui/conf/positions/left_forearm_V2.txt
• https://github.com/robotology/icub-main/blob/master/app/skinGui/conf/positions/right_forearm_V2.txt

So either the optimization is not deterministic or the input from the pipeline from CAD is not the same for the two forearms?

URDF models deployed automatically

Dear all,
recently, together with @traversaro, we started to have a look at the automatic generation of the URDF models hosted in the repository icub-models using our CI system Travis.
The goal is to have the URDF models deployed automatically every time a change is committed to the icub-model-generator repository.

For this purpose, it is possible to configure Travis such that at the end of the build process it commits the generated files.
Hereafter is described one possible approach to automate the process:

1. Create a GitHub BOT account.
2. Invite the BOT account to the icub-models and icub-model-generator repositories
3. Generate a personal access token for the BOT account
4. Add the personal access token as an Environment Variable in the Travis settings of the icub-model-generator repository
5. Add the following code to the before_script section of the Travis configuration file

# clone the output folder and add the environment variable
  - git clone https://github.com/fiorisi/icub-models
  - cd icub-models
  - export ICUB_MODELS_SOURCE_DIR=`pwd`
  - cd ../

6. modify the cmake command to include the ICUB_MODELS_SOURCE_DIR

  - cmake -D ICUB_MODELS_SOURCE_DIR=$ICUB_MODELS_SOURCE_DIR  ..

7. At the end of the script section add a line to call the target to copy the new files

  - sudo cmake --build . --target copy-models-to-icub-models

8. Add a after_success section with the following lines

after_success:
  # Start in the home directory
  - cd ../..
  # Commit the new models back to the icub-models repository
  - cd icub-models
  - git remote rm origin
  - git remote add origin https://BOT_USER_NAME:${BOT_TOCKEN}@github.com/robotology-playground/icub-models.git
  - git status
  - git add .
  - git commit --message "Travis build ${TRAVIS_BUILD_NUMBER}"
  - git push --set-upstream --quiet origin master

Where:

• BOT_USER_NAME is the account of the GitHub BOT.
• BOT_TOCKEN is the name of the Travis Environment Variable created before

A preliminary test has been done on a fork of the Robotology Playground repositories. As you can see in this commit the system is working.

As suggested by @traversaro, it would be nice to have a copy of the message associated to the commit that triggered the build. Furthermore, might be also useful to have the version of all the libraries used during the conversion process, and probably there should be a check that allows the commit only if the master branch was modified.
If you think that this automation can be useful, we can have a discussion to implement it properly.

I cc the main contributors of the repositories but feel free to add who you think might be interested in this topic.

@traversaro, @francesco-romano, @diegoferigo, @nunoguedelha, @pattacini, @DanielePucci

Generate DH frames for model generated with v2 workflow (i.e. from Creo models)

DH frames (as documented in http://wiki.icub.org/wiki/ICub_Model_naming_conventions) are necessary for proper integration with the skinDynLib library, that currently uses those frames for expressing the position/orientation of contact points, forces and torques.

Make the arms joints frames symmetric in the iCub 2.5 models

Recently (robotology/icub-models#4) we updated the model generated with the SimMechanics tool to have the leg joints frames symmetric. The same shall be done with the arms joints frames.

Fix materials exported in URDF file

Currently all the models exported using the creo --> simmechanics --> urdf workflow do not properly export materials.
For example if you load of today any URDF in iDynTree, you get the following warnings:

`[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material black not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material red not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material blue not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material yellow not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material pink not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material cyan not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material white not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material dblue not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material dgreen not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material gray not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material black not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material red not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material blue not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material yellow not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material pink not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material cyan not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material white not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material dblue not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material dgreen not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material gray not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material green not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material black not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, material red not found in model database.
[ERROR]  :: parseURDFMaterial : Impossible to parse URDF material, setting material to white.

Inertia set to zero causes simulation problems ?

Hi all,

I noticed that a few links in the iCub URDFs have inertia values set to zero which later on proved to be the source of simulation problems. Though it is fair to say that this is done for good reason as far as design goes, does it really make sense ? For example, DART (using the FCL collision detector) is crashing when the iCub collides with a simple object (e.g. the ground, in a very basic simulation where I just load the iCub put it on the ground). Setting the inertia to a non zero value (let's say 0.01) seems to solve the simulation issue. Do you think that it is a good way to do that / do you have any suggestions ?

Those are the links in question:

• l_ankle_2 (here)
• l_hip_3 (here)
• l_wrist_1 (here)
• r_wrist_1 (here)
• neck_1 (here)
• r_hip_3 (here)
• root_link (here)

Not all of the above are causing (or so it seems) problems. In my case l_wrist_1, r_wrist_1 and neck_1 seemed to be the links causing problems.

P.S. it may be (more) related to DART's handling, but nevertheless you may be aware of a better workaround

Thank you

@serena-ivaldi @jbmouret

urdf icubNancy need meshes

Hi,

We got some issues with icubNancy URDF, we need to get some meshes .dae for part of the iCub which are not end effector (l_hip_yaw, r_hip_yaw, torso_yaw, l_shoulder_yaw, r_shoulder_yaw, l_ankle_2, r_ankle_2, l_elbow_1, l_elbow_1).

I need it to compute some convex hull to do automatic collision.
For now i took l_hip_pitch.dae to compute convex hull of l_hip_yaw (same for right leg etc, but i don't know what to take for torso_yaw).

Thanks

SimMechanics has been renamed Simscape Multibody

We should update the docs.

Sole mismatch in iCubHeidelberg01 model

Move to robotology

I think this repo is ready to be migrated to robotology .
Anything against this? @drdanz

Integrate iCubHeidelberg01 in the generation pipeline

To avoid robotology-legacy/yarp-wholebodyinterface@147bef3 .

We are halted on #15 .
We should implement at least a workaround to get it merged.

MaterialProp not exported into the simmechanics file

I'm digging into the python code for adding colors in the generated urdfs. The models at the current stage are all white, and despite the urdf --> sdf conversion for material elements still doesn't work, I realized that in the first place the MaterialProp element of the simmechanics file is never specified. This would mean that 1) it is not exported from the CAD, or 2) It is not handled properly from Simscape Multibody Link.

The following message is displayed:

Material has neither a color nor texture.

Side note: these errors are suppressed during the generation process and imho they should't be.

Check the Heidelberg model as reference.

cc @traversaro @fiorisi

Creating URDF for iCubNancy01 modified forearm

Hi all,
we would like to create the URDF also for a modified iCub with modified arms. We have the design of the arms in Solidworks. We would like to attach them to an iCub model to make a full new robot.
Could you help us in opening the full robot in Solidworks? The original files do not seem compliant.

Thanks in advance

@bpapaspyros @jbmouret @Anthonyfma @dogoepp

Error linking TinyXML on Mac OS 10.9.4

When trying to build icub-model-generator through the codyco-superbuild I get this error:

Linking CXX executable icub_urdf_from_iDyn
ld: library not found for -lTinyXML::tinyxml
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[5]: *** [src/icub_urdf_from_iDyn] Error 1
make[4]: *** [src/CMakeFiles/icub_urdf_from_iDyn.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [misc/icub-model-generator/CMakeFiles/YCMStamp/icub-model-generator-build] Error 2
make[1]: *** [CMakeFiles/icub-model-generator.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Note that the repo TinyXML is correctly downloaded, built and installed (I found it in 'codyco-superbuild/build/install/lib'.

The generated simmechanics doesn't contain MaterialProp elements

Moved from robotology/simmechanics-to-urdf#27.

For some reason, the steps that generate the XML simmechanics file don't export anymore the MaterialProp elements. Without this, the generated urdf has no color.

@traversaro @fiorisi Who can help me on this? I have 0 knowledge about how Simscape Multiboby Link works.

Model with additional FT sensors in the ankles.

Ankle FT sensors are not part of the legacy iDyn models.

For adding this sensors to the generated models, we add additional information, in the form of:

• ss_T_old_ee the homogeneous transformation that transform position vectors expressed in the iDynChain endeffector frames to position vector expressed in the ft sensor frame.
• new_ee_T_old_ee the homogeneous transformation that transform position vectors expressed in the iDynChain endeffector frames to position vector expressed in new endeffector frame (r/l_foot_dh_frame).

The end effector frame origin, used by frames r/l_foot_dh_frame (that have the orientation used in the old iKinChain/iDynChain objects) and frame r/l_sole (that use the orientation X-front, Y-left, Z-up as defined in REP-120) is always defined as the projection of the interesection of the *_ankle_roll and *_ankle_pitch axis on the metal sole plane (disregarding any skin that could be added to the feet). Note: the iDynChain legs v2.5 do not follow this convention for the end effector origin, but places the end effector origin on the projection of the ft sensor origin. Given that the mismatch between the two is minimal (3.5 mm) we decided to use this convention for all URDF models

iCub v2.5 legs (iCubGenova01, iCubDarmstad01, upcoming iCubGenova02)

T_ss_old_ee = KDL::Frame(KDL::Rotation(0,0,1,
                                                                    0,1,0,
                                                                   -1,0,0),
                                             KDL::Vector(0,0,0.004)); 

T_new_ee_old_ee = KDL::Frame(KDL::Rotation(1,0,0,
                                                                             0,1,0,
                                                                             0,0,1),
                                                       KDL::Vector(0,0,0)); 

(should be an offset of 0.0035 somewhere, todo).

iCub v1 legs + ankle FT (iCubParis01, iCubGenova03)

Obtained by modifying RC_USAL_001_A_037_001_RANKLE with rc_iit_001_a_041.asm

T_ss_old_ee = KDL::Frame(KDL::Rotation(0,0,1,
                                                                    0,1,0,
                                                                   -1,0,0),
                                             KDL::Vector(-0.017,0,-0.001)); 

T_new_ee_old_ee = KDL::Frame(KDL::Rotation(1,0,0,
                                                                             0,1,0,
                                                                             0,0,1),
                                                       KDL::Vector(0,0,0.0183)); 

iCub v2 legs + ankle FT (iCubParis02, for now assuming v01 legs kinematics)

T_ss_old_ee = KDL::Frame(KDL::Rotation(0,0,1,
                                                                    0,1,0,
                                                                   -1,0,0),
                                             KDL::Vector(-0.008,0,-0.0143)); 

T_new_ee_old_ee = KDL::Frame(KDL::Rotation(1,0,0,
                                                                             0,1,0,
                                                                             0,0,1),
                                                       KDL::Vector(0,0,0.0183)); 

Simmechanics models have the wrong sign in the r_wrist_prosup axis

This axis should be added to https://github.com/robotology-playground/icub-model-generator/blob/master/simmechanics/data/icub2_5/ICUB_2-5_BB_simmechanics_options.yaml#L506 , and a test should be added in https://github.com/robotology-playground/icub-model-generator/blob/master/tests/icub-model-test.cpp#L219 .

Related manual modification : robotology-legacy/yarp-wholebodyinterface@fe3d454 .

Cleanup how URDF meshes are processed

imu_frame not generated in simmechanics models

Add generation of Gazebo ODE parameters for each joint

Add automated file copyng for v1

Currently only the sdf/urdf files are correctly created, we should also add in some way (CMake?) the copy of configuration files and meshes to the right directories.

Review torque (effort) limits in generated models

@randaz81 noticed that some issues in iCub Gazebo models (see robotology-legacy/icub-gazebo-legacy#35) where due to misplaced torque effort limits.

Generate iCubNancy01 model

@UChervet originally wrote:

Dear all,

We would like to simulate precisely our robot in gazebo and control it with WBI. The problem is that we > need a custom URDF since our robot is peculiar : we have a V2 head, V1 arms and torso and V2 legs. > If I'm not mistaken all the URDF for the other robots have V2 arms. Is there an URDF for a V1 robot ? > Is it possible to combine parts from different URDF files to create our custom one or is there something > else that we should know ? Could you help us making the correct URDF for iCubNancy01 ?

Thanks in advance.

@serena-ivaldi @bpapaspyros @jbmouret

Gazebo crashes without throwing any error if we add the accelerometers to the URDF

This issue occurred while testing updates not yet released to the model generator toolchain (#49, #52).

Conditions for reproducing the issue

The initial URDF model that could be loaded successfully in Gazebo was in the commit nunoguedelha/icub-models@6b74550 (branch feature/updateModels). This commit includes :

• the initial URDF generated from the CAD model iCub 2.5 (except the inertial sensors tags)
• updated link inertias for avoiding numerical instabilities
• updated ankle and hip joints limits
• blobs under gazebo tag for tuning the sole bounce on the ground

We then merged the changes from robotology/icub-models#2:

• initial URDF generated from the CAD model iCub 2.5, including the inertial sensors tags

Symptoms

The resulting URDF (nunoguedelha/icub-models@3aab750) is making Gazebo crash.

We are using Gazebo version 8. No error is apparently thrown by the simulator, but a crash report is saved when testing on Mac OSX environment.

Increase the number of tests on the generated models

Would be nice to test:

• The transform from root to end effector frames for different arm and leg joint configuration
• The joint axis direction for all the joint
• The total mass of the robots

Generate gazebo models with implicit damping enabled

See:

• http://www.osrfoundation.org/wordpress2/wp-content/uploads/2015/04/roscon2014_scpeters.pdf
• https://bitbucket.org/osrf/sdformat/issues/127/make-implicit_spring_damper-default-to

We did that on R1.

TO DO list of improvements and minor fixes

This issue lists low priority To Do tasks like documenting parameters or fixing minor issues with no functional impact:

• document collision and friction parameters of iCub feet and check redundant parameters.

Simmechanics models need to have a imu_frame frame for the xsens imu location

At the moment, they have a imu frame that is not compatible with the configuration files available in the codyco-modules repository .

iCub v2.5 without backpack generated URDF models are not valid

Stricter checks in iDynTree routines for loading URDF (see robotology/idyntree#212) highlighted that there are XML validity problems in some generated URDF (see https://travis-ci.org/robotology-playground/icub-model-generator/builds/153229462).

All the models failing are iCub v2.5 without backpack, so the problem is probably in https://github.com/robotology-playground/icub-model-generator/blob/master/simmechanics/data/icub2_5/adjust_com_for_model_without_backpack.py .

$ ctest --output-on-failure
Test project /home/travis/build/robotology-playground/icub-model-generator/build
    Start 1: iCubGenova03ConsistencyCheck
1/8 Test #1: iCubGenova03ConsistencyCheck ......   Passed    0.02 sec
    Start 2: iCubNancy01ConsistencyCheck
2/8 Test #2: iCubNancy01ConsistencyCheck .......   Passed    0.02 sec
    Start 3: iCubParis01ConsistencyCheck
3/8 Test #3: iCubParis01ConsistencyCheck .......   Passed    0.02 sec
    Start 4: iCubParis02ConsistencyCheck
4/8 Test #4: iCubParis02ConsistencyCheck .......   Passed    0.02 sec
    Start 5: iCubGenova01ConsistencyCheck
5/8 Test #5: iCubGenova01ConsistencyCheck ......***Failed    0.01 sec
[ERROR]  :: modelFromURDFString : Invalid XML
[ERROR] error in loading robot model
icub-model-test error: impossible to load model from 0
    Start 6: iCubGenova02ConsistencyCheck
6/8 Test #6: iCubGenova02ConsistencyCheck ......   Passed    0.02 sec
    Start 7: iCubGenova05ConsistencyCheck
7/8 Test #7: iCubGenova05ConsistencyCheck ......***Failed    0.01 sec
[ERROR]  :: modelFromURDFString : Invalid XML
[ERROR] error in loading robot model
icub-model-test error: impossible to load model from 0
    Start 8: iCubDarmstadt01ConsistencyCheck
8/8 Test #8: iCubDarmstadt01ConsistencyCheck ...***Failed    0.01 sec
[ERROR]  :: modelFromURDFString : Invalid XML
[ERROR] error in loading robot model
icub-model-test error: impossible to load model from 0

63% tests passed, 3 tests failed out of 8
Total Test time (real) =   0.12 sec

The following tests FAILED:

      5 - iCubGenova01ConsistencyCheck (Failed)
      7 - iCubGenova05ConsistencyCheck (Failed)
      8 - iCubDarmstadt01ConsistencyCheck (Failed)

Errors while running CTest

Issues in the iCubGenova05.urdf after introducing pronation/supination+wrist DOFs

The forearm pronation/supination and wrist DOFs have been introduced in the YAML parameter file for iCubGenova05 model. We are observing the following issues in the generated URDF file :

1. l_elbow joint appears as SIM_SEA_2-5_L_ELBOW--SIM_SEA_2-5_L_ELBOW_PROSUP
2. The MTB 1b7, 1b8, 1b9 sensors are attached to l_elbow_1 which is between the elbow and the forearm. While we rotate the l_wrist_prosup joint, l_elbow_1 won't rotate with the forearm cover, where the sensors are attached. In the URDF they should be attached to l_forearm. Same issue for the right forearm sensors.

Correctly process meshes in URDF models

We need to correctly process meshes of generated URDF models.

One of the problems to solve is that the URDF format [1] does not describe the semantics of the filename attribute, that is used to specify external meshes in Collada or STL format.
In practice, most URDF released as part of ROS packages specify the meshes location using the package:// URI, that are resolved to absolute filenames using ROS' resource_retriever.

Clearly this is not a viable strategy for libraries that do not depend on ROS, and want to load arbitrary URDF files. Unfortunatly mesh handling without using ROS is not uniform across different libraries.
Some (such as Google's Bullet ) just support meshes specified w.r.t to the model subdirectory using the format filename="meshes/mesh.dae", but I guess a model of that kind would not be supported by ROS tools.

Another problem is if we want to share the same meshes among the different models of if we want to duplicate them by copying them in each robot directory.

[1] : http://wiki.ros.org/urdf/XML/link

Travis build broken

https://travis-ci.org/robotology-playground/icub-model-generator/builds/287783127

cc @fiorisi

iCubNancy01 urdf

@InriaBrice commented on Fri Jun 30 2017

Hi !

We need some features about iCubNancy01 urdf to convert urdf to sdf file with gz sdf -p command :

Links can't have masse = 0,
Links can't have inertia matrix diagonal null -> ixx, iyy, izz != 0,
It happens for link like wrist or hip_yaw, so it's not an end effector (we can't just remove this link otherwise hand can't be here ),

We need a version without dh frame because we just don't use them,

About Center of masses of links, soemtimes it seems like they are not at the right position (especially in the arms they are a bit forward ).

Also if it is possible to have all link frame with X axis forward and Z axis upward.

Also i was asking myself, why meshes are not Centered at origin in .dae files ? ( Also it's possible to set frame meshes to get X forward and Z upward ) .

I think link wrist could be more in the middle of the forearm, i mean at the middle of end of the forearm, they are actually ahead and in the forearm.

Also it would be nice if iCub was turned forward ( looking at +X axis ), without turn robot in gazebo or whatever (just with urdf spawn )

For now i customized all to get something like expected, but some inertia matrix are making robot a bit instable.

---

@traversaro commented on Tue Jul 04 2017

Hi @InriaBrice , moving the issue over to icub-model-generator where we already have all the other discussions on the generated models.

URDF models have non-consistent joint limits

This is somehow related to #5 .
The limits displayed in this file are different from those defined in https://github.com/robotology/robots-configuration/tree/devel .
For example the l_hip_roll has different limits from those defined in this file.

We should even discuss whether to use the "soft" or the "hardware" limits. (https://github.com/robotology/robots-configuration/blob/devel/iCubGenova04/hardware/motorControl/left_leg-eb6-j0_3-mc.xml vs https://github.com/robotology/robots-configuration/blob/devel/iCubGenova04/hardware/mechanicals/left_leg-eb6-j0_3-mec.xml)

Generate models with hands