Some problems about urdf exercises' solutions

Course Support URDF for Robot Modeling
1

Hi,
I meet with some problems in solutions of exercise 2.2 of urdf.
1.
What is really for? Why doesn’t the solution contain of “body_link”, and it still functions right in Gazebo?
2.
Why is inertia of “head_link” not a sphere?
‘’’





‘’’
This is definitely a cylinder.
3.
Why is inertia of “camera_link” the same as inertia of “eye_link”? They don’t even have same shape.

Thanks for explainations which may come.

2

sorry, the code of problem2 is here:

    <inertial>
        <origin xyz="0 0 0" rpy="0 0 0"/>
        <mass value="0.02" />
        <inertia ixx="2.61666666667e-05" ixy="0.0" ixz="0.0" iyy="2.61666666667e-05" iyz="0.0" izz="3.6e-05"/>
    </inertial>
3

and another problem:
why the origin of collision of “head_link” is different from origin of its own visual?

    <collision>
        <origin xyz="0 0 0.015" rpy="0 0 0"/>
        <geometry>
            <!--
            <cylinder radius="0.06" length="0.035"/>
            -->
            <sphere radius="0.06"/>
        </geometry>
    </collision>
	<visual>
        <origin rpy="0.0 0 0" xyz="0 0 0"/>
        <geometry>
            <mesh filename="package://my_mira_description/models/mira/meshes/mira_head_v5.dae"/>
        </geometry>
    </visual>

It is true that when I set the origins of collision and visual the same as xyz=“0 0 0”, the robot swingles in a different mode. But how can we actually define this difference ‘0.15’ here?

4

Hello @MeineLiebeAxt,

body_link is just an arbitrary name, you can name links anything you like. That being said, there are
some common names that people use for links, for instance body_link or root_link and you will see that name very often in different robot models. Additionally there are two name conventions related to TF frames that can be used as a good practice to name links, just to keep consistency:

When working with URDF models we use simple/basic geometry forms as a way of describing a more complex reality. We use these models in knowing that they are not 100% correct or complete because a 100% correct model is difficult to use. The head in the example you mention could be approximated by a sphere, but that would not be 100% correct either, as you can see the head resembles more half of an ovoid. So you could argue about modelling is a cylinder or a sphere, but both will not be 100% equal to the real head.

The explanation from 2. also applies here. we are working with simplified versions of reality, so you can weight and measure your real robot, but the model will be just an approximation of reality.

Hope this helps,

Roberto

5

@MeineLiebeAxt,

sometimes you have to “tweak” your model in order for it to work. As you discovered by yourself putting the collision origin at “0 0 0” will cause instability in the model you have to adjust a little bit until you have a model that works. It is a little bit of an iterative process, some trial and error might be needed if your first version of your model has some issues for instance with the colissions.

Regards,

Roberto

6

Thank you @rzegers very much, that is more clear for me now.

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.