robotology / icub-models Goto Github PK
View Code? Open in Web Editor NEWOfficial URDF and SDF models of the iCub humanoid robot.
License: Creative Commons Attribution Share Alike 4.0 International
Official URDF and SDF models of the iCub humanoid robot.
License: Creative Commons Attribution Share Alike 4.0 International
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 ?
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.
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.
so an offset of
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?
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
It should be set to a reasonable value, similar to the ones found on the real robots.
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
I didn't check the head and arms
cc @DanielePucci @traversaro @S-Dafarra and @Nicogene
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?
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?
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.
While using the icub-models
in Gazebo I encountered the following problems:
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.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.Cc.
@nunoguedelha @traversaro @diegoferigo @francesco-romano @fiorisi @DanielePucci
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?
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?
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 .
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
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.
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.
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.
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) .
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.
@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:
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
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.
The direction of the right joint seems to be wrongly defined
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
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
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
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:
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]:
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:
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.So there is no possibility to run gaze controller on Gazebo?
Originally posted by @robertorovella91 in robotology-legacy/icub-gazebo-legacy#62 (comment)
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>
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!
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).
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?
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?
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.
Following #5, I think we could add few lines to the README.
Repository containing models automatically generated by https://github.com/robotology-playground/icub-model-generator .
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 ๐
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.
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.
Hi @xEnVrE
First off, thanks a lot for the new model added in #42 โจ
Regarding this, I've noticed the following points:
[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]
/icubSim/cam/left/depthImage:o
/icubSim/cam/left/rgbImage:o
/icubSim/cam/right
/icubSim/cam/right/rgbImage:o
or /icubSim/cam/left
, I'd say.cc @traversaro
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.
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.
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
These are the limits for the right hand finger adduction/abduction
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
with associated limits
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?
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
Since now we have the IMU in the ft sensor we should add it.
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) .
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:
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.
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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.