robotology / icub-models Goto Github PK

View Code? Open in Web Editor NEW

33.0 12.0 33.0 37.44 MB

Official URDF and SDF models of the iCub humanoid robot.

License: Creative Commons Attribution Share Alike 4.0 International

CMake 92.57% C++ 1.85% Python 5.58%

yarp ros gazebo icub gazebo-simulator gazebo-models urdf

icub-models's People

Stargazers

Watchers

icub-models's Issues

[iCubGazeboV3] The direction of several axis joints does not match the real robot

I'm currently in front of the robot with @isorrentino and I checked the joints motion of iCubGazeboV3 with iCub3.

The following joints axes are wrongly mounted in the urdf

torso_roll
l_ankle_pitch
r_hip_yaw
r_ankle_roll

I didn't check the head and arms
cc @DanielePucci @traversaro @S-Dafarra and @Nicogene

Add CHANGELOG

Update README to use models with Gazebo

Following #5, I think we could add few lines to the README.

Line 3,

Repository containing models automatically generated by https://github.com/robotology-playground/icub-model-generator .

Somewhere at the end:

Gazebo

In order to use these models in Gazebo, set up the simulation environment following the instructions provided in the icub-gazebo repository, and add the following line to your .bashrc:
export GAZEBO_MODEL_PATH=${GAZEBO_MODEL_PATH}:/your_installation_folder/share/iCub/robots:/your_installation_folder/share

@diegoferigo feel free to edit it as you prefer 😊

[iCubGazeboV3] right leg joints direction wrongly defined

The direction of the right joint seems to be wrongly defined

This is r_hip_roll

This is for the ankle pitch

Notice the ankle roll goes in HF for a specific value of ankle-pitch for this problem please check #60

@traversaro and @Nicogene
Similar issue: #57

iCubGazebo2_5_visuomanip: provide port names consistent with the real robot

See #44 (comment) .

In particular, according to #44 (comment) the real robot publishes RGB images as:

/icub/cam/right
/icub/cam/left

While the Gazebo simulated robot:

/icubSim/cam/left/rgbImage:o
/icubSim/cam/right

Document frames and link frames situation

Document that the location of the link frames is not consistent between the models, and that for simmechanics models only the link frames listed in https://github.com/robotology/icub-model-generator/blob/52ee80fdbfc588e09010dd418fd5904c6ac7383c/simmechanics/data/icub2_5/ICUB_2-5_BB_simmechanics_options.yaml.in#L552 have a strictly defined location
Move documentation from http://wiki.icub.org/wiki/ICub_Model_naming_conventions to this repo

Update models with realistic viscous and coulomb friction parameters

Since when the iCub URDF and Gazebo models have been created, they have been always arbitrary values for the viscous and coulomb joint friction parameters (see robotology/icub-models-generator#86).

While the values of viscous and coulomb friction that best approximate a real joint depend on a lot of factors (such as the precise transmission and motor models, and how much the transmisssions are lubrificated, etc etc) and change from robot to robot and also on the calibration data, I think we should be able to at settle on parameters that have the correct order of magnitude, and use them by default on our iCub models.

Add the possibility to use multipleanalogsensorsclient and multipleanalogsensorsremapper also in Gazebo

Recently, on the robot, we started using the multipleanalogsensorsremapper: https://github.com/robotology/robots-configuration/tree/master/iCubGenova04/wrappers/inertials

The corresponding plugin seems also available in GazeboYarpPlugins: https://github.com/robotology/gazebo-yarp-plugins/blob/master/plugins/imu/include/gazebo/IMU.hh

How should I modify the urdf and the configuration files in order to have a parallel setup also in Gazebo?

@prashanthr05 @nunoguedelha @traversaro

Misalignment between soles frames and feet collisions (iCubGazeboV2_5)

Putting the robot on the ground on a dynamical simulator, I would expect the soles frames to be in contact with the ground (coordinate z equal to zero). However, this is not happening due to a misalignment between the collision and the feet frames

e.g.

the robot is on the ground

- get the base position using [`baseState`](https://github.com/robotology/gazebo-yarp-plugins/tree/8c056e21c10bd231d1659612285386f12432626b/plugins/basestate), and computing the forward kinematics, the position of soles frame (`l_sole` and `r_sole`) that I obtain is the following:

so an offset of $\approx 1cm$ is observed

Make sure ARE is working in Gazebo simulation

Several users are experiencing issues that (I think) are related to not properly tuned joint-level PID position loops of the iCub model in Gazebo, see:

We should tune the position gains with respect to some clearly defined scenario, such as the ARE one described by @frank-foerster in robotology-legacy/icub-gazebo-legacy#37 . For reference we should document on which scenario we tuned the gains, such that in the future we can simplify the process of re-tuning the gains for different robots (such as R1).

Avoid to use modified models to deal with numerical instabilities in Gazebo and related tools

Back in the autumn of 2013, I was preparing the first ever model of iCub for Gazebo (the one that is currently stored in https://github.com/robotology/icub-gazebo .

Unfortunately, the model with correct inertia was not being correctly simulated, mainly due to the default timestep used by Gazebo/ODE (1 ms), non-error-controlled integrator used by Gazebo/ODE and the friction parameters I was using at the time. The problem could have been solved by decreasing the timestep of Gazebo. Instead, I decided to increase manually the inertia of some links of the iCub model to reduce the stiffness of the dynamical system. That decision created the duality between the iCub models that we use for estimation and control on the real robot (typically named iCubCityNameXX) and the models used in Gazebo simulation, i.e. icubGazeboSim and later iCubGazeboV2_5 . The strategy was eventually propagated to this repo as well, see robotology/icub-models-generator#52 (comment) and robotology/icub-models-generator#71 . I think that the design decision of having different models was wrong, and this is getting more clear every day.

In particular, I think that having different models is problematic for the following reasons:

It is not clear to users, that prefer to have one single source of true for their software architectures
If you are able to simulate the model with stiff inertias (for example by reducing the timestep in Classic Gazebo with ODE, or using a more advanced physics engine with Ignition Gazebo) you can't easily, you need instead to completely change model

An alternative solution that I think it would make sense to use instead of duplicated models, would be a custom Gazebo Classic plugin that, during loading of the model in Gazebo Classic, would increase the inertia and the damping of the links and joints specified in the configuration. In this way, if a user wants to customize the simulation to disable the increased inertia, for example because he decrease the timestamp, it can without problems. Note that such a solution could create an inconsistency as controllers would use the model with non-increased inertia. However, I do not think this is a big problem as if the users want accurate simulations, they should know how to appropriately reduce the Gazebo timestep to obtain accurate simulation without the increased inertia workaround.

iCubGazeboV2_5 unstable if it is controlled using velocity mode

When I try to switch from position control to velocity control iCub jumps and the switched joint goes in hardware fault.
Here a simple example.

I have tried to tune the PID controller of the l_shoulder_pitch` joint:

Gain	Old	New
Kp	8.726	0.85
Kd	0.035	0
Ki	0.002	0.15

This is the result

iCubGazebo2_5_visuomanip discrepancies

Hi @xEnVrE

First off, thanks a lot for the new model added in #42 ✨

Regarding this, I've noticed the following points:

At startup, I can see these errors popping up:

[Err] [Model.cc:99] Error Code 2 Msg: sensor with name[head_imu_acc_1x1] already exists.
[Err] [Model.cc:99] Error Code 5 Msg: Attempting to load a Sensor, but the provided sensor type is missing or invalid.
[Err] [SensorManager.cc:290] Unable to create sensor of type[accelerometer]

I would harmonize the name of the cameras' ports. As of now, the model will open (aside from the rpc service ports):
- /icubSim/cam/left/depthImage:o
- /icubSim/cam/left/rgbImage:o
- /icubSim/cam/right
  Therefore, either we use /icubSim/cam/right/rgbImage:o or /icubSim/cam/left, I'd say.

cc @traversaro

Regression in generated models iCub2 models due to iCub3 modifications

After merging robotology/icub-models-generator#143, in the committed models something strange happened, see cd4b2a6 .
What is happening is that some new changes in the .ini files introduced by robotology/icub-models-generator#138 has been removed.
I think that what is happening is that the icub3 model has a copy of a lot of .ini files from the iCub2 model in https://github.com/robotology/icub-model-generator/tree/master/simmechanics/data/icub3/conf, and it installs them in https://github.com/robotology/icub-model-generator/blob/master/simmechanics/CMakeLists.txt#L334 in the same location of the same files of iCub2, overwriting in this way the files of iCub2 and all the recent modifications. I think the directory in https://github.com/robotology/icub-model-generator/tree/master/simmechanics/data/icub3/conf should contain only files actually used by iCub 3, and they should be installed in a directory different from the one of iCub2 .

Inserting in Gazebo the new model iCubGazeboV2_5 directly from icub-models crashes the simulator

This issue only occurs if we insert in Gazebo the new model iCubGazeboV2_5 directly from the icub-models repo. This is probably due to an issue with the nesting of gazebo models and the resulting path to inertial sensors.
The current implementation of the plugins handling the inertial MTB sensors (libgazebo_yarp_inertial.so and libgazebo_yarp_distributedinertials.so) were designed considering a model nested like in the case of icub_fixed_no_hands, and might have a faulty behavior when the robot model is not nested.

Add support for iCub facial expressions simulation in Gazebo

Probably this can be done with the gazebo_yarp_videotexture plugin, as done for the R1 robot ( robotology/cer-sim#17 and robotology/cer-sim#18).

Other related issues:

Ports prefix conflict while spawning multiple composite models

As mentioned in this issue while spawning multiple icub robots into gazebo gazeboYarpPluginsRobotName icubSim inside gazebo_icub_robotname.ini is commented out.

All the FT sensor ports and inertial ports open correctly while spawning two base icub models inside gazebo

registration name /iCub/left_arm/analog:o ip 10.255.54.112 port 10008 type tcp
registration name /iCub/left_arm/analog:o/rpc:i ip 10.255.54.112 port 10007 type tcp
registration name /iCub/left_foot/analog:o ip 10.255.54.112 port 10191 type tcp
registration name /iCub/left_foot/analog:o/rpc:i ip 10.255.54.112 port 10190 type tcp
registration name /iCub/left_leg/analog:o ip 10.255.54.112 port 10189 type tcp
registration name /iCub/left_leg/analog:o/rpc:i ip 10.255.54.112 port 10188 type tcp
registration name /iCub/right_arm/analog:o ip 10.255.54.112 port 10010 type tcp
registration name /iCub/right_arm/analog:o/rpc:i ip 10.255.54.112 port 10009 type tcp
registration name /iCub/right_foot/analog:o ip 10.255.54.112 port 10195 type tcp
registration name /iCub/right_foot/analog:o/rpc:i ip 10.255.54.112 port 10194 type tcp
registration name /iCub/right_leg/analog:o ip 10.255.54.112 port 10193 type tcp
registration name /iCub/right_leg/analog:o/rpc:i ip 10.255.54.112 port 10192 type tcp
registration name /iCub_0/left_arm/analog:o ip 10.255.54.112 port 10230 type tcp
registration name /iCub_0/left_arm/analog:o/rpc:i ip 10.255.54.112 port 10229 type tcp
registration name /iCub_0/left_foot/analog:o ip 10.255.54.112 port 10224 type tcp
registration name /iCub_0/left_foot/analog:o/rpc:i ip 10.255.54.112 port 10223 type tcp
registration name /iCub_0/left_leg/analog:o ip 10.255.54.112 port 10222 type tcp
registration name /iCub_0/left_leg/analog:o/rpc:i ip 10.255.54.112 port 10221 type tcp
registration name /iCub_0/right_arm/analog:o ip 10.255.54.112 port 10232 type tcp
registration name /iCub_0/right_arm/analog:o/rpc:i ip 10.255.54.112 port 10231 type tcp
registration name /iCub_0/right_foot/analog:o ip 10.255.54.112 port 10228 type tcp
registration name /iCub_0/right_foot/analog:o/rpc:i ip 10.255.54.112 port 10227 type tcp
registration name /iCub_0/right_leg/analog:o ip 10.255.54.112 port 10226 type tcp
registration name /iCub_0/right_leg/analog:o/rpc:i ip 10.255.54.112 port 10225 type tcp

But when iCub (fixed) model, which uses composite icub_with_hands model is spawnned in gazebo the ports opened are not correct

The FT ports of the arms are opened with /iCub prefix
The FT ports of the hands are opened with /iCub_fixed prefix
The FT ports of the legs are opened without any prefx

registration name /iCub/left_arm/analog:o ip 10.255.54.112 port 10008 type tcp
registration name /iCub/left_arm/analog:o/rpc:i ip 10.255.54.112 port 10007 type tcp
registration name /iCub/right_arm/analog:o ip 10.255.54.112 port 10010 type tcp
registration name /iCub/right_arm/analog:o/rpc:i ip 10.255.54.112 port 10009 type tcp
registration name /iCub_fixed/left_hand/analog:o ip 10.255.54.112 port 10101 type tcp
registration name /iCub_fixed/left_hand/analog:o/rpc:i ip 10.255.54.112 port 10100 type tcp
registration name /iCub_fixed/right_hand/analog:o ip 10.255.54.112 port 10103 type tcp
registration name /iCub_fixed/right_hand/analog:o/rpc:i ip 10.255.54.112 port 10102 type tcp
registration name /l_leg/left_foot/analog:o ip 10.255.54.112 port 10014 type tcp
registration name /l_leg/left_foot/analog:o/rpc:i ip 10.255.54.112 port 10013 type tcp
registration name /l_leg/left_leg/analog:o ip 10.255.54.112 port 10012 type tcp
registration name /l_leg/left_leg/analog:o/rpc:i ip 10.255.54.112 port 10011 type tcp
registration name /r_leg/right_foot/analog:o ip 10.255.54.112 port 10018 type tcp
registration name /r_leg/right_foot/analog:o/rpc:i ip 10.255.54.112 port 10017 type tcp
registration name /r_leg/right_leg/analog:o ip 10.255.54.112 port 10016 type tcp
registration name /r_leg/right_leg/analog:o/rpc:i ip 10.255.54.112 port 10015 type tcp

When the second icub_with_hands model is spawnned into gazebo all the FT ports and inertial ports are started with the same names leading to address conflict

NOTE: The same behavior is observed with inertial sensor port

Later tried iCub (fixed) model, using base icub model. In this case also FT and inertial ports are not opened correctly

registration name /iCub/inertial ip 10.255.54.112 port 10004 type tcp
registration name /iCub/left_arm/analog:o ip 10.255.54.112 port 10008 type tcp
registration name /iCub/left_arm/analog:o/rpc:i ip 10.255.54.112 port 10007 type tcp
registration name /iCub/left_foot/analog:o ip 10.255.54.112 port 10191 type tcp
registration name /iCub/left_foot/analog:o/rpc:i ip 10.255.54.112 port 10190 type tcp
registration name /iCub/left_leg/analog:o ip 10.255.54.112 port 10189 type tcp
registration name /iCub/left_leg/analog:o/rpc:i ip 10.255.54.112 port 10188 type tcp
registration name /iCub/right_arm/analog:o ip 10.255.54.112 port 10010 type tcp
registration name /iCub/right_arm/analog:o/rpc:i ip 10.255.54.112 port 10009 type tcp
registration name /iCub/right_foot/analog:o ip 10.255.54.112 port 10195 type tcp
registration name /iCub/right_foot/analog:o/rpc:i ip 10.255.54.112 port 10194 type tcp
registration name /iCub/right_leg/analog:o ip 10.255.54.112 port 10193 type tcp
registration name /iCub/right_leg/analog:o/rpc:i ip 10.255.54.112 port 10192 type tcp
registration name /iCub_fixed/head/command:i ip 10.255.54.112 port 10080 type tcp
registration name /iCub_fixed/head/rpc:i ip 10.255.54.112 port 10079 type tcp
registration name /iCub_fixed/head/state:o ip 10.255.54.112 port 10081 type tcp
registration name /iCub_fixed/head/stateExt:o ip 10.255.54.112 port 10082 type tcp
registration name /iCub_fixed/left_arm/command:i ip 10.255.54.112 port 10093 type tcp
registration name /iCub_fixed/left_arm/rpc:i ip 10.255.54.112 port 10092 type tcp
registration name /iCub_fixed/left_arm/state:o ip 10.255.54.112 port 10094 type tcp
registration name /iCub_fixed/left_arm/stateExt:o ip 10.255.54.112 port 10095 type tcp
registration name /iCub_fixed/left_leg/command:i ip 10.255.54.112 port 10020 type tcp
registration name /iCub_fixed/left_leg/rpc:i ip 10.255.54.112 port 10019 type tcp
registration name /iCub_fixed/left_leg/state:o ip 10.255.54.112 port 10021 type tcp
registration name /iCub_fixed/left_leg/stateExt:o ip 10.255.54.112 port 10022 type tcp
registration name /iCub_fixed/right_arm/command:i ip 10.255.54.112 port 10097 type tcp
registration name /iCub_fixed/right_arm/rpc:i ip 10.255.54.112 port 10096 type tcp
registration name /iCub_fixed/right_arm/state:o ip 10.255.54.112 port 10098 type tcp
registration name /iCub_fixed/right_arm/stateExt:o ip 10.255.54.112 port 10099 type tcp
registration name /iCub_fixed/right_leg/command:i ip 10.255.54.112 port 10024 type tcp
registration name /iCub_fixed/right_leg/rpc:i ip 10.255.54.112 port 10023 type tcp
registration name /iCub_fixed/right_leg/state:o ip 10.255.54.112 port 10025 type tcp
registration name /iCub_fixed/right_leg/stateExt:o ip 10.255.54.112 port 10026 type tcp
registration name /iCub_fixed/torso/command:i ip 10.255.54.112 port 10076 type tcp
registration name /iCub_fixed/torso/rpc:i ip 10.255.54.112 port 10075 type tcp
registration name /iCub_fixed/torso/state:o ip 10.255.54.112 port 10077 type tcp
registration name /iCub_fixed/torso/stateExt:o ip 10.255.54.112 port 10078 type tcp
registration name /iCub_fixed_0/head/command:i ip 10.255.54.112 port 10165 type tcp
registration name /iCub_fixed_0/head/rpc:i ip 10.255.54.112 port 10164 type tcp
registration name /iCub_fixed_0/head/state:o ip 10.255.54.112 port 10166 type tcp
registration name /iCub_fixed_0/head/stateExt:o ip 10.255.54.112 port 10167 type tcp
registration name /iCub_fixed_0/left_arm/command:i ip 10.255.54.112 port 10177 type tcp
registration name /iCub_fixed_0/left_arm/rpc:i ip 10.255.54.112 port 10176 type tcp
registration name /iCub_fixed_0/left_arm/state:o ip 10.255.54.112 port 10178 type tcp
registration name /iCub_fixed_0/left_arm/stateExt:o ip 10.255.54.112 port 10179 type tcp
registration name /iCub_fixed_0/left_leg/command:i ip 10.255.54.112 port 10105 type tcp
registration name /iCub_fixed_0/left_leg/rpc:i ip 10.255.54.112 port 10104 type tcp
registration name /iCub_fixed_0/left_leg/state:o ip 10.255.54.112 port 10106 type tcp
registration name /iCub_fixed_0/left_leg/stateExt:o ip 10.255.54.112 port 10107 type tcp
registration name /iCub_fixed_0/right_arm/command:i ip 10.255.54.112 port 10181 type tcp
registration name /iCub_fixed_0/right_arm/rpc:i ip 10.255.54.112 port 10180 type tcp
registration name /iCub_fixed_0/right_arm/state:o ip 10.255.54.112 port 10182 type tcp
registration name /iCub_fixed_0/right_arm/stateExt:o ip 10.255.54.112 port 10183 type tcp
registration name /iCub_fixed_0/right_leg/command:i ip 10.255.54.112 port 10109 type tcp
registration name /iCub_fixed_0/right_leg/rpc:i ip 10.255.54.112 port 10108 type tcp
registration name /iCub_fixed_0/right_leg/state:o ip 10.255.54.112 port 10110 type tcp
registration name /iCub_fixed_0/right_leg/stateExt:o ip 10.255.54.112 port 10111 type tcp
registration name /iCub_fixed_0/torso/command:i ip 10.255.54.112 port 10161 type tcp
registration name /iCub_fixed_0/torso/rpc:i ip 10.255.54.112 port 10160 type tcp
registration name /iCub_fixed_0/torso/state:o ip 10.255.54.112 port 10162 type tcp
registration name /iCub_fixed_0/torso/stateExt:o ip 10.255.54.112 port 10163 type tcp

@traversaro

Use preserveFixedJoint instead disableFixedJointLumping to convert URDF fixed joints to real SDF fixed joints

See https://bitbucket.org/osrf/sdformat/pull-requests/352/add-preservefixedjoint-option-to-the-urdf/diff for the discussion about the option.

Related comment: robotology/gym-ignition#130 (comment) .

Symmetry in iCubGenova04

Hi @fiorisi and @gabrielenava!

When running simulations I noticed that the robot was not moving symmetrically. After looking into why this was the case I found that the model is not mirrored left to right. I am not sure if this was done on purpose to better reflect the real hardware and if this affects other iCub models also.

More specifically, I found that the same bodies for left and right arms and legs have different masses and different joint offsets. Here are two examples from the urdf:

<joint name="l_knee" type="revolute">
<origin xyz="-0.0135855 -0.145625 0" rpy="0 0 0"/>

<joint name="r_knee" type="revolute">
<origin xyz="-0.0096675 -0.145625 0" rpy="0 0 0"/>

<link name="l_upper_leg">
<mass value="1.8084"/>

<link name="r_upper_leg">
<mass value="1.8035"/>

My question is: is this expected or wanted?
If so, would it be much work to provide a symmetric model for simulations?
If not, do you plan of fixing this? In that case I can give you a full list of inconsistencies that I found.

Thanks for the feedback!

Move in robotology?

I think that the repo has been used for relativly a long time, and so it is time to move it to robotology.
Opinions on that? @nunoguedelha @diegoferigo @gabrielenava @S-Dafarra ?

Instruction on using the models in Gazebo should be updated to consider also the case in which the models are used from the build directory

In https://github.com/robotology/icub-models#use-the-models-with-gazebo, we should also consider the case of models used from the build, as that case is documented as supported in the superbuild itself.

[iCubGazeboV3] Ankles roll goes in HF for a given value of ankle pitch

If the ankle pitch of the left foot is greater than 13deg the ankle roll goes in HF

The same behavior happens also for the right foot.

Notice that the joint axis of the two ankles seems to be not coherent (associate issue #61)

@Nicogene and @traversaro

Weight and drawing of hand

What is the weight of hand iCub?
I tried to find dimensions of hand like finger phalanx length in assembly drawing and found out that to open assembly files need PTC Creo commercial version. I have only student version.

Could you send a link for drawing of hand compatible with student version to meashure finger sizes and their position?

Problems while loading models in Gazebo 11

Hi,

I've recently started off playing with Gazebo 11 in a Docker Image and I've noticed that there are models provided in this repo that will crumble down to the ground as soon as loaded within the environment.

Here are a couple of examples:



Model working OK

Model NOT working

As @traversaro found out, it might be due to gazebosim/gazebo-classic#2728.

cc @xEnVrE

Use the models in Gazebo

Can you provide some instructions on how to use these models in Gazebo?
For example, I added the /icub-models-install/share/iCub/robots folder to the GAZEBO_MODEL_PATH variable, but Gazebo is not able to find the meshes. What is the best way to load the meshes without copying their folder into /icub-models-install/share/iCub/robots?
Can I run all the controllers as with icub-gazebo with no problems?

@fiorisi @traversaro @nunoguedelha @gabrielenava

Provide models corresponding to specific versions of iCub

Currently the icub-models repo contains models of specific physical iCub used around the world (iCub), but for some uses cases it would be useful to have a model of a iCub with a given version (for example, the latest version would be iCubV2_5) ignoring the specific changes of the different physical iCubs,

We already have something similar to this with the iCubGazeboV2_5 model that is indeed a canonical 2.5 robot, but at the moment that robot contains some inertia that have been artificially increased with respect to their nominal value to permit simulation with the default physics engine (ODE) and settings of Classic Gazebo. At this moment (early 2020) a model that matches a iCubV2_5 is the iCubGenova04.

Add the waist-imu in iCubGazeboV2_7

Every time we have to use the waist IMU in the simulation we need to switch to a custom branch developed by @prashanthr05. Please check here.

It would be nice if the IMU is embedded by default in the simulation model.

Add support for using icub-models out of the box with PyBullet

To use iCubGenova04 urdf model in pybullet simulator, I deleted all the lines containing the keyword Gazebo in the urdf file and relocated the meshes folder directory. I'm not sure if the model is still reliable but at least by doing so I can load the model. In view of the simulation, there are some problems:

iCub hands have collision with the body.
I received many warnings and most of them are complaining about no inertial data and skin such as

b3Printf: No inertial data for link, using mass=1, localinertiadiagonal = 1,1,1, identity local inertial frame
b3Printf: b3Warning[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,115]:

b3Printf: r_lower_leg_skin_10
b3Printf: b3Warning[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,115]:

there are in total 138 joints(is this the correct number?)

Run the iCub's Gaze controller on Gazebo

So there is no possibility to run gaze controller on Gazebo?

Originally posted by @robertorovella91 in robotology-legacy/icub-gazebo-legacy#62 (comment)

Automatically generate the **_visuomanip models from existing models

Similar to what is done for all others model stored in this repo, the original source of information (hands model, eyes models) should be stored in some other location, and then the complete models (such as iCubGazeboV2_5_visuomanip) should be generate automatically, to ensure that modifications in new version of iCub can be propagated automatically.

In this issue in particular we track the modifications done in the iCubGazeboV2_5_visuomanip model, to make sure that they will be eventually all ported to an automatic procedure.

Know modifications:

A model with hands and eyes has been added in #42 . Hands and eyes models are not derived from CAD models, but this should not stop us from having an automatic procedure: the "manually" prepared hands and eyes model should prepare a standalone models, that then are combined with the rest of the model coming from the CAD in an automatic way
The head_imu_acc_1x1 sensor tag has been removed from a <gazebo> tag in #45, but the accelerometer tags were never supposed to be there in the first place.

Add IMU frame of ft-stain2 in the models.

Since now we have the IMU in the ft sensor we should add it.

cc @fiorisi @traversaro @nunoguedelha @prashanthr05

install configuration files only for the supported models (iCubGazeboV2_5)

@nunoguedelha commented on Fri Nov 10 2017

We should install configuration files only for the models expected to work on Gazebo simulation, which are currently:

iCubGazeboV2_5
iCubGazeboV2_5_plus

Clarification on the FT frames in the FT CAD model

Looking at the CAD model of the FT sensors, more specifically, ic_007_a_001.asm, for the FT sensor with M3 skrews, I noted that the SCSYS_FT45 frame, which should be the sensor frame of the FT sensor, is reversed w.r.t. the sketch that represents the positive x and y axis of the sensor's frame. See the pictures below:

@fiorisi am I missing something here? Which frame should I follow when mounting the FT?

[model-generation] Numerical instability due to low articulated body inertia in the iCub shoulder

The mechanical department of iCub Facility recently extracted a URDF/SDF of the iCub v2.5 (with backpack and battery) from the CAD model of the robot, using the process described in https://www.icub.org/wiki/Creo_Mechanism_to_URDF .

That model was committed in robotology-legacy/icub-gazebo-legacy@0e631bd .
Tests performed with Gazebo 6 (i.e. ODE Physics Engine with Semi Explicit Euler integration with a fixed timestsamp of 1ms) and with a fixed base robot show that when the *_shoulder_pitch and *_shoulder_yaw are close to be coincident (for example in the -90 90 0 configuration of the shoulder) then the simulation explodes.

The reason why is apparently that given the relatively small dimensions of the _shoulder_1 and _shoulder_2 links the associated apparent inertias seen by the *_shoulder_pitch is low (~ 10^-4 Kg m^2 ) and that, coupled with a stiff position control by the low level PID, results in a system that is numerically difficult to integrate.
Consistently with this theory, reducing the fixed timestamp to 0.1 ms solves the problem on ODE.

Anyway it is desirable to be able to provide a model that works flawless on the stock version of Gazebo. A possible way is to increase artificially the inertia matrices of _shoulder_1 and _shoulder_2 given that most (all?) users will not concerned by such a negligible mismatch between reality and simulation (other differences, such as the fact that the transmission chain is not modeled, are orders of magnitude more relevant) .

Theory note: multiplying an inertia matrix at the com by K without changing neither the mass nor the COM position is equivalent to stretch the mass distribution of the rigid body around the COM by a factor of sqrt(k).

With a quick check it seems that a multiplication of the inertia matrices of _shoulder_1 and _shoulder_2 by 10 (i.e. a stretch of ~ 3.1623 ) is solving the issue.

Problems with iCub 3 inertias

The model of iCub 3 explodes if using the masses and inertias of the right and left arm, exported from simmechanics.
This happens only if they are controlled with the controlboard.

This happens both with ode and dart physical engine.

Setting ixx, iyy, izz to 0.01 solves this issue, or rather worked around the problem.

ICub default posture

Hi guys,

I was looking for the joint values for a default posture. I meant the posture that the robots has in when it's standing statically.

Grazie mille,
Carlos

[iCubGazeboV3][iCubGenova09] head_imu_acc_1x1 (SCSYS_HEAD_MTX_IMU SimMechanics display name) missing

We usually use the head IMU as the primary IMU to run the wholeBodyDynamics device in https://github.com/robotology/whole-body-estimators.
Currently, we are trying to configure wholeBodyDynamics on iCubGazeboV3 and iCubGenova09 models. This requires the availability of the head IMU.

iCub3 SimMechanics XML file doesn't contain a SCSYS_HEAD_MTX_IMU. Should we generate it from the CAD?

See https://github.com/robotology/icub-model-generator/blob/master/simmechanics/data/icub3/ICUB3_ALL_SIM_MODEL.xml

On checking further the sim-mechanics file, there seems to be 3 coordinate systems CS1, CS2, and CS3 in the head link as seen in https://github.com/robotology/icub-model-generator/blob/49a4e0a4d11a09895c207baba1b29c5395ecc662/simmechanics/data/icub3/ICUB3_ALL_SIM_MODEL.xml#L2816

CS2 seems to be the frame SCSYS_HEAD. Is one of CS1 and CS3 related to the IMU?

How should we proceed if we would like to have the head IMU in the URDF model?

cc @traversaro @S-Dafarra @GiulioRomualdi

Fix correct location of RFE IMU for iCub 2.6 models

To correctly run WBD for robots that have a 2.6 version of the head, we need to correctly export the iCub models with the correct location of the imu_frame frame. To avoid the need to re-generate a simmechanics model, we can do something similar to robotology/icub-models-generator#139 in which a new iCubGazeboV2_7 model is added with just modification at the configuration/CMake level.

Give official names to the iCub hand joints

Currently, the iCub hand joints does not have common (official) names in order to be addressed, similar to what we have for the actuated axis names in http://wiki.icub.org/wiki/ICub_joints .
This naming possibly can be common for both the current version of the iCub hands and the new version.

CC @traversaro @fiorisi @pattacini

Add the iCub 3 model

In order to start performing experiments with the iCub 3 robot, it is fundamental to have its urdf and the possibility of using it in Gazebo.

With this issue, I would like to track the generation and the issues arising when trying to use this model for the first time.

cc @pattacini, @traversaro, @fiorisi

Clarifications on joint limits of eyes and finger adduction/abduction

These are the limits for the right hand finger adduction/abduction

https://github.com/robotology/icub-gazebo/blob/14a078e49968c2130d64b8d5635d6f302035d67b/icub/conf/gazebo_icub_right_hand_finger.ini#L68-L71

On the real robot, these correspond to a single DoF spanning approximately 60.0 degrees. Please also consider that the joint associated to the middle finger is not actuated.

Hence I am expecting something like

[LIMITS] 
 jntPosMax 20.0 0.0 20.0 20.0 
 jntPosMin 0.0 0.0 0.0 0.0 
 jntVelMax 100.0 100.0 100.0 100.0

because, when the hand is totally open, the best that we can do is to assign one third of the range to each joint. The link associated to the middle finger, instead, does not move.

As far as I understand, the controlboard plugin within gazebo-yarp-plugins uses the limits to decide the limits of the trajectory generator. The trajectory is associated to the controlled DoFs (i.e. the ones that we can control via, e.g., the yarpmotorgui) and is remapped to the physical joints simulated within Gazebo using coupling handlers (see here).

Right now, the effect of the coupling on the limits is not handled and this PR is trying to address this issue. Without this PR, the limits indicated above will result in a minimum possible value for the joint r_hand_finger of 0.0 and a maximum possible value of 20.0. Of course, this is wrong.

The same apply for the left hand.

I also have doubts for the eyes. These are the joint names

https://github.com/robotology/icub-gazebo/blob/14a078e49968c2130d64b8d5635d6f302035d67b/icub/conf/gazebo_icub_head.ini#L27

with associated limits

https://github.com/robotology/icub-gazebo/blob/14a078e49968c2130d64b8d5635d6f302035d67b/icub/conf/gazebo_icub_head.ini#L72-L75

The physical joints (excluding the neck) are eyes-tilt, left-eye and right-eye while the commanded DoF are the eyes-tilt, eyes-version and eyes-vergence. Hence, I am expecting that the limits associated to the physical joints are reported while (-30.0 30.0) is indeed the typical range for the eyes-version and (0.0 50.0) is the typical range for the eyes-vergence.

Is any specific reason for this choice of the limits?

Check the torso pitch joint limits on iCubGazeboV3

I was tuning the PID position control in the simulated version of iCub3 and I noticed that something wired on the torso joint limits.

Accordingly to the motorgui the torso pitch has to be a value between -18 deg and +45 deg. However, the range of motion seems to be not coherent with the real robot.

I drop here a gif. Is there a way to check if the limits are wrong?

The values seem to be in accordance with https://github.com/robotology/robots-configuration/blob/40b8e8893fd11e42fff53a1454854319bd922ad7/iCubGenova09/hardware/motorControl/torso-eb5-j0_2-mc.xml#L15-L16. However, the range of motion is strange.

cc @traversaro and @S-Dafarra

Wrong rotation order in /icubGazeboSim/inertial port

On the real icub, data received from the imu sensor is transmitted on the /inertial port in the order: roll pitch yaw. Anyway the values is produced by the sensor using the aeronautic convention pitch roll yaw.

On the simulator, the imu sensor sends values in the same order, roll pitch yaw, but the data is produced using the robotic convention roll pitch yaw.

The result is that the values are the same when the rotation is only on one of the axes, but when the rotation is on 2 or 3 axes the values are different and the correct rotation matrix must be obtained by switching the order of the roll and pitch terms in the matrix product.

The same issue probably applies to the velocity and acceleration vectors.

I'm not sure if this is a bug that should be fixed in the real robot (i.e. use robotics convention in the robot) or in the model.

Add sanity checks for iCub3 models

To avoid strange regressions, we have some sanity checks for the iCub 2.* models in https://github.com/robotology/icub-model-generator/blob/master/tests/CMakeLists.txt#L25 . It probably could make sense to have similar checks for iCub 3 models, to avoid regressions such as the one described in #41 (comment) .

iCub default stiffness seems to be set to 0.0

It should be set to a reasonable value, similar to the ones found on the real robots.

Installed package.xml contains an old version

The package.xml used for ROS compatibility is always installed with the old 1.6.0 version, see https://github.com/robotology/icub-models/blob/master/iCub/package.xml . We should probably make sure that this file is installed with a version that is coherent with the one that we use in tags.

Problems when using these models in Gazebo

While using the icub-models in Gazebo I encountered the following problems:

The inertias of some links are too small and need to be modified by hand as suggested in this comment => solved by robotology/icub-models-generator#71.
When the robot is inserted in Gazebo, it is "submerged" in the ground and needs to be moved by hand pausing Gazebo beforehand => this is because the models in the repo icub-models don't have the offset positioning the model in the world. This offset is defined within the models defined in icub-gazebo-wholebody.
Once I press play on Gazebo with the robot correctly placed, Gazebo crashes. See this comment => only occurs if we insert in Gazebo the new model iCubGazeboV2_5 directly from the icub-models repo, and not through icub-gazebo-wholebody. This issue is not blocking and shall be tracked by #10. All models in icub-gazebo-wholebody will be updated in order to point to the new model iCubGazeboV2_5.
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 => will be tracked in the Epic icub-model-generator/#52.

Cc.
@nunoguedelha @traversaro @diegoferigo @francesco-romano @fiorisi @DanielePucci

iCubNancy01 urdf

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.

[Q/A] Query regarding Gazebo foot collision elements

Few SDF collision elements here, for the foot seems to be outside the parent tag 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>

Also, http://sdformat.org/spec?elem=collision&ver=1.6 specifies max_contacts tag. Moreover, the parameters kp, kd, mu1, etc fall as children of friction->physics_engine (where in this example, physics_engine is a place-holder. eg, physics_engine ode) tags all under surface element.

There seems to be a mismatch between the SDF format and the gazebo reference tags written in the robot URDF file. Is this because we use the SDF tags within a URDF format?

Error while loading iCubGazeboV3_fixed

When I tried to load iCubGazeboV3_fixed an error is thrown by gazebo 11.
Consequentially the robot is not fixed in the world

Here the error:

[Err] [SdfFrameSemantics.cc:91] Error Code 23 Msg: FrameAttachedToGraph error, Non-LINK vertex with name [fixed_base] is disconnected; it should have 1 outgoing edge in MODEL attached_to graph.
[Err] [SdfFrameSemantics.cc:91] Error Code 23 Msg: Graph has __model__ scope but sink vertex named [fixed_base] does not have FrameType LINK OR MODEL when starting from vertex with name [fixed_base].
[Err] [SdfFrameSemantics.cc:91] Error Code 26 Msg: PoseRelativeToGraph error, Vertex with name [fixed_base] is disconnected; it should have 1 incoming edge in MODEL relative_to graph.
[Err] [SdfFrameSemantics.cc:91] Error Code 26 Msg: PoseRelativeToGraph frame with name [fixed_base] is disconnected; its source vertex has name [fixed_base], but its source name should be __model__.
[Err] [Model.cc:99] Error Code 23 Msg: FrameAttachedToGraph error, Non-LINK vertex with name [fixed_base] is disconnected; it should have 1 outgoing edge in MODEL attached_to graph.
[Err] [Model.cc:99] Error Code 23 Msg: Graph has __model__ scope but sink vertex named [fixed_base] does not have FrameType LINK OR MODEL when starting from vertex with name [fixed_base].
[Err] [Model.cc:99] Error Code 26 Msg: PoseRelativeToGraph error, Vertex with name [fixed_base] is disconnected; it should have 1 incoming edge in MODEL relative_to graph.
[Err] [Model.cc:99] Error Code 26 Msg: PoseRelativeToGraph frame with name [fixed_base] is disconnected; its source vertex has name [fixed_base], but its source name should be __model__.
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/left_leg/analog:o/rpc:i active at tcp://192.168.1.3:10004/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/left_leg/analog:o active at tcp://192.168.1.3:10005/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/left_foot_front/analog:o/rpc:i active at tcp://192.168.1.3:10006/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/left_foot_front/analog:o active at tcp://192.168.1.3:10007/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/left_foot_rear/analog:o/rpc:i active at tcp://192.168.1.3:10008/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/left_foot_rear/analog:o active at tcp://192.168.1.3:10009/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/right_leg/analog:o/rpc:i active at tcp://192.168.1.3:10010/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/right_leg/analog:o active at tcp://192.168.1.3:10011/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/right_foot_front/analog:o/rpc:i active at tcp://192.168.1.3:10012/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/right_foot_front/analog:o active at tcp://192.168.1.3:10013/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/right_foot_rear/analog:o/rpc:i active at tcp://192.168.1.3:10014/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/right_foot_rear/analog:o active at tcp://192.168.1.3:10015/
[INFO]No ROS group found in config file ... skipping ROS initialization. 
yarp: Port /icubSim/left_arm/analog:o/rpc:i active at tcp://192.168.1.3:10016/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/left_arm/analog:o active at tcp://192.168.1.3:10017/
[Err] [Joint.cc:297] EXCEPTION: Couldn't Find Child Link[iCub::base_link]

[Err] [Model.cc:247] LoadJoint Failed
[INFO]No ROS group found in config file ... skipping ROS initialization. 
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
yarp: Port /icubSim/right_arm/analog:o/rpc:i active at tcp://192.168.1.3:10018/
[INFO]AnalogServer : no ROS initialization required 
[INFO]created wrapper <analogServer>. See C++ class AnalogWrapper for documentation.
[INFO]created device <gazebo_forcetorque>. See C++ class GazeboYarpForceTorqueDriver for documentation.
yarp: Port /icubSim/right_arm/analog:o active at tcp://192.168.1.3:10019/
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[Wrn] [msgs.cc:1841] Conversion of sensor type[force_torque] not supported.
[INFO]/icubSim/torso : no ROS initialization required 
[INFO]/icubSim/torso  initting YARP initialization 
yarp: Port /icubSim/torso/rpc:i active at tcp://192.168.1.3:10020/
yarp: Port /icubSim/torso/command:i active at tcp://192.168.1.3:10021/
yarp: Port /icubSim/torso/state:o active at tcp://192.168.1.3:10022/
yarp: Port /icubSim/torso/stateExt:o active at tcp://192.168.1.3:10023/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::torso_yaw torso_yaw 
[DEBUG]found:  iCub::torso_pitch torso_pitch 
[DEBUG]found:  iCub::torso_roll torso_roll 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]Initializing Trajectory Generator with current values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.
[INFO]/icubSim/left_leg : no ROS initialization required 
[INFO]/icubSim/left_leg  initting YARP initialization 
yarp: Port /icubSim/left_leg/rpc:i active at tcp://192.168.1.3:10024/
yarp: Port /icubSim/left_leg/command:i active at tcp://192.168.1.3:10025/
yarp: Port /icubSim/left_leg/state:o active at tcp://192.168.1.3:10026/
yarp: Port /icubSim/left_leg/stateExt:o active at tcp://192.168.1.3:10027/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::l_hip_pitch l_hip_pitch 
[DEBUG]found:  iCub::l_hip_roll l_hip_roll 
[DEBUG]found:  iCub::l_hip_yaw l_hip_yaw 
[DEBUG]found:  iCub::l_knee l_knee 
[DEBUG]found:  iCub::l_ankle_pitch l_ankle_pitch 
[DEBUG]found:  iCub::l_ankle_roll l_ankle_roll 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]Initializing Trajectory Generator with current values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.
[INFO]/icubSim/right_leg : no ROS initialization required 
[INFO]/icubSim/right_leg  initting YARP initialization 
yarp: Port /icubSim/right_leg/rpc:i active at tcp://192.168.1.3:10028/
yarp: Port /icubSim/right_leg/command:i active at tcp://192.168.1.3:10029/
yarp: Port /icubSim/right_leg/state:o active at tcp://192.168.1.3:10030/
yarp: Port /icubSim/right_leg/stateExt:o active at tcp://192.168.1.3:10031/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::r_hip_pitch r_hip_pitch 
[DEBUG]found:  iCub::r_hip_roll r_hip_roll 
[DEBUG]found:  iCub::r_hip_yaw r_hip_yaw 
[DEBUG]found:  iCub::r_knee r_knee 
[DEBUG]found:  iCub::r_ankle_pitch r_ankle_pitch 
[DEBUG]found:  iCub::r_ankle_roll r_ankle_roll 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]Initializing Trajectory Generator with current values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.
[INFO]/icubSim/head : no ROS initialization required 
[INFO]/icubSim/head  initting YARP initialization 
yarp: Port /icubSim/head/rpc:i active at tcp://192.168.1.3:10032/
yarp: Port /icubSim/head/command:i active at tcp://192.168.1.3:10033/
yarp: Port /icubSim/head/state:o active at tcp://192.168.1.3:10034/
yarp: Port /icubSim/head/stateExt:o active at tcp://192.168.1.3:10035/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::neck_pitch neck_pitch 
[DEBUG]found:  iCub::neck_roll neck_roll 
[DEBUG]found:  iCub::neck_yaw neck_yaw 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]Initializing Trajectory Generator with current values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.
[INFO]/icubSim/left_arm : no ROS initialization required 
[INFO]/icubSim/left_arm  initting YARP initialization 
yarp: Port /icubSim/left_arm/rpc:i active at tcp://192.168.1.3:10036/
yarp: Port /icubSim/left_arm/command:i active at tcp://192.168.1.3:10037/
yarp: Port /icubSim/left_arm/state:o active at tcp://192.168.1.3:10038/
yarp: Port /icubSim/left_arm/stateExt:o active at tcp://192.168.1.3:10039/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::l_shoulder_pitch l_shoulder_pitch 
[DEBUG]found:  iCub::l_shoulder_roll l_shoulder_roll 
[DEBUG]found:  iCub::l_shoulder_yaw l_shoulder_yaw 
[DEBUG]found:  iCub::l_elbow l_elbow 
[DEBUG]found:  iCub::l_wrist_prosup l_wrist_prosup 
[DEBUG]found:  iCub::l_wrist_pitch l_wrist_pitch 
[DEBUG]found:  iCub::l_wrist_yaw l_wrist_yaw 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]INITIAL CONFIGURATION IS:  -0.520000	 0.520000	 0.000000	 0.785000	 0.000000	 0.000000	 0.000000 
[DEBUG]Initializing Trajectory Generator with default values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.
[INFO]/icubSim/right_arm : no ROS initialization required 
[INFO]/icubSim/right_arm  initting YARP initialization 
yarp: Port /icubSim/right_arm/rpc:i active at tcp://192.168.1.3:10040/
yarp: Port /icubSim/right_arm/command:i active at tcp://192.168.1.3:10041/
yarp: Port /icubSim/right_arm/state:o active at tcp://192.168.1.3:10042/
yarp: Port /icubSim/right_arm/stateExt:o active at tcp://192.168.1.3:10043/
[INFO]created wrapper <controlboardwrapper2>. See C++ class ControlBoardWrapper for documentation.
[DEBUG]found:  iCub::r_shoulder_pitch r_shoulder_pitch 
[DEBUG]found:  iCub::r_shoulder_roll r_shoulder_roll 
[DEBUG]found:  iCub::r_shoulder_yaw r_shoulder_yaw 
[DEBUG]found:  iCub::r_elbow r_elbow 
[DEBUG]found:  iCub::r_wrist_prosup r_wrist_prosup 
[DEBUG]found:  iCub::r_wrist_pitch r_wrist_pitch 
[DEBUG]found:  iCub::r_wrist_yaw r_wrist_yaw 
[DEBUG]done 
[WARNING]No positionToleranceLinear value found in ini file, default one will be used! 
[WARNING]No positionToleranceRevolute value found in ini file, default one will be used! 
[WARNING]No max torques value found in ini file, default one will be used! 
[DEBUG]max_torques: [   2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000	 2000.000000  ] 
[INFO]min_stiffness param found! 
[INFO]max_stiffness param found! 
[INFO]min_damping param found! 
[INFO]max_damping param found! 
[DEBUG]min_stiffness: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_stiffness: [   1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000	 1000.000000  ] 
[DEBUG]min_damping: [   0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000	 0.000000  ] 
[DEBUG]max_damping: [   100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000	 100.000000  ] 
[WARNING]VELOCITY_CONTROL: 'velocityControlImplementationType' param missing.  Using the default value of 'direct_velocity_pid', but the parameter will be compulsory gazebo-yarp-plugins 4.
[DEBUG]INITIAL CONFIGURATION IS:  -0.520000	 0.520000	 0.000000	 0.785000	 0.000000	 0.000000	 0.000000 
[DEBUG]Initializing Trajectory Generator with default values 
[INFO]created device <gazebo_controlboard>. See C++ class GazeboYarpControlBoardDriver for documentation.

Here the autogenerated sdf file of iCubGazeboV3_fixed

<?xml version='1.0'?>
<sdf version='1.7'>
  <model name="iCub_fixed">
    <include>
      <uri>model://iCubGazeboV3</uri>
      <pose>0.0 0 1.0 0 0 3.14</pose>
    </include>

    <joint name="fixed_base" type="fixed">
      <parent>world</parent>
      <child>iCub::base_link</child>
    </joint>
  </model>
</sdf>

@traversaro

robotology / icub-models Goto Github PK

icub-models's People

Stargazers

Watchers

Forkers

icub-models's Issues

Gazebo

Recommend Projects

Recommend Topics

Recommend Org