Y up_axis

[olivier-stasse]

Would it be possible to change this to Z up_axis on the meshes of REEM C ? When loading the geometry with urdfdom on 12.04 LTS the local geometry of the link is upside-down. Unless there is a profound reason, I am not sure to see the point.

Thanks in advance for your answer.

[adolfo-rt]

Could you please provide more context so we can better understand the issue?. How are you loading the geometries?, does a simple rviz visualization of the model work?, is it something affecting all geometries or just some?. Some screenshots would help.

Some context from our side. In the REEM-C model, all geometries are oriented such that they can be attached to the link frames without needing any additional transformations. Also, not all link orientations have the z coordinate pointing upwards in the zero position, as shown in the below image.

[olivier-stasse]

Hi Adolfo, Thanks for your quick answer. I am probably missing something obvious.

The urdf file specify here starts with the base and its mesh without any transformation. Thus one could expect that in the kinematic tree the base frame is x-front, y-left, z-up. This is what we get when looking at gazebo/link_states when the robot is in the standing position:

 x: 0.0045927966684
 y: 0.000221814771623
 z: 0.853428401546

orientation: x: 9.59220059542e-06 y: -0.000331640671629 z: -0.00032384563851 w: 0.999999892523

But it seems not to be the case in rviz (y-green pointing up).

When looking into the DAE, it indicates that the mesh was generated using meshlab. When loading the base.dae using meshlab, we have the following display.

Y is pointing up but the geometry of the body and the local frame are showing that Z is pointing along the vertical of the robot.

Therefore the kinematic tree, and the local geometry of the link are right, (Z is up). But then I do not understand the interest of having the field up_axis set to Y_UP in base.dae ...

Could you explain me what I am getting wrong ?

In addition changing up_axis to Z_UP in line 8 of base.dae seems to not affect the computations done when starting the gazebo tutorial.

[olivier-stasse]

For the context, I am trying to load the geometry in an OpenSceneGraph custom application to check the geometry. The main point is to try our motion generator with various humanoid robots. When loading the REEM-C model with the openscenegraph loader it applies the transform Y_UP. This is fine with respect to a display choice as in meshlab. But with respect to the robot model, it seems to not be coherent if one wants to display the kinematic tree.

But again I am probably missing something obvious.

Thanks in advance for your kind help.

[adolfo-rt]

If what you want is to change which axis is considered as the 'up' direction when displayed in isolation, I think we could accept a pull request for that. It should not break code, as the coordinate system will remain unchanged with respect to the geometry. In other words, the Y_UP or Z_UP does not play a role when using the meshes within the robot model, .

[olivier-stasse]

With respect to the collada specification, this would make sure that no transformation is introduced. The meaning of the transformation is rather large when one looks at the collada specification. So yes I think it would be better.

[adolfo-rt]

Does #7 fix the issues you were having for all geometries?. The base of the robot is such that if z points up, the geometry will be correctly aligned with the robot's zero pose. This is not the case for all geometries. For instance, this is how the head looks with z pointing upwards:

In REEM-C, the z axis aligns with the axis of rotation of the associated joint.

[olivier-stasse]

Yes but then the kinematic tree should gives you the proper transformation:

0Xi : E = 1 0 0 0 4.89664e-12 1 0 -1 4.89664e-12

r = 0.0580575 0.0008831 1.3744

Which here would map 1/ the Z axis in the head frame to the Y axis in the world frame 2/ the opposite of Y in the head frame to the Z-axis in the world frame,

So the head is at the appropriate place with respect to the kinematic model.

The problem is that up_axis is introducing a transform which is explicitly removed by rviz. The ticket in rviz addressing the problem seems to me misleading. IMHO, it seems better that the geometry of the robot is coherent with respect to the kinematic model.

I checked that the commit does not modify anything by launching the tutorial on gazebo...

On my application, the only thing which changes are the textures. And maybe this is the main trouble with changing the up_axis. It defines the side of the normals. Still I did not see any change on Gazebo.

[adolfo-rt]

I can confirm that your patch does not affect the reconstruction of the robot. For extra caution: @hilario, can you think of any way in which this change could affect existing code?. Otherwise I'll go ahead and pull the trigger.

[adolfo-rt]

Ping @hilario.

[olivier-stasse]

Could you make a final decision on this pull request ?

[adolfo-rt]

@lucamarchionni, @hilario, I no longer can accept PRs on these repos, please take appropriate action. I think it can be safely merged.