remove up_axis tag from DAE meshes

[T045T]

RViz doesn't respect it anyway ( ros-visualization/rviz#1045 ), but current versions of three.js' ColladaLoader (used in the RobotWebTools, see RobotWebTools/ros3djs#202 ) do!

(Since RViz doesn't respect the tag, this does not break the model)

[rctoris]

I went through the chain of tickets that lead to this PR and think I have an understanding. But I guess my initial confusion is, is this a problem with ThreeJS, or is ThreeJS correct and our model is wrong but we just don't notice because RViz doesn't care?

[T045T]

It's the latter - ThreeJS correctly applies the up_axis tag to models now (the older version ros3djs used before did not).

RViz doesn't check for up_axis and probably won't change because that would break some models.

As such, we'll probably modify ThreeJS' ColladaLoader downstream (or petition them to add an option to ignore up_axis) to keep ros3djs in sync with RViz' behavior.

However, I figured running a one line shell command on the repo to clean things up wouldn't hurt, even if it does not immediately change anything :)

If anything, this patch might prevent some confusion when loading the models in a non-RViz, non-ros3djs tool that does respect up_axis

[mikeferguson]

What about Gazebo? The loader there is different than the loader in RVIZ, has this been tested in Gazebo?

[T045T]

that's a very good question - I'll check just to make sure, but if Gazebo handled things differently from RViz, the model would have been broken in one of the two, but not the other, before this change.

[moriarty]

¯\(ツ)/¯ I don't have much opinion on this... @rctoris I don't think it breaks anything, and can probably be merged.

Actually digging into the linked issues I found these:

1. not loading robot model from srdf personalrobotics/or_urdf#33
2. How to access the head camera? jontromanab/fetchpy#2

Which are both Fetch specific and relate back to this Issue.
@jontromanab would this PR fix the above issues?

Also, for non Fetch related PRs similar to this one, some have been merged:

• ✅ remove up_axis tag from DAE meshes turtlebot/turtlebot#262
• ✅ remove up_axis tag from DAE meshes yujinrobot/kobuki#380
• open remove up_axis tag from DAE meshes RethinkRobotics/baxter_common#92

[jontromanab]

Hello @moriarty. My issue was a little bit different in the sense that Assimp, the openrave mesh handler, and Rviz handles meshes little differently. Making the y-axis up generally solves the issues in openrave. That's what my code in process_urdf does. It may work in Rviz and three.js, but I am highly doubtful, it may work for other systems such as openrave.

[T045T]

Yes, Y_UP is the default, I believe - so removing the up_axis tag altogether or changing it to Y_UP should not make a difference :)

[moriarty]

Opps, I used the GitHub interface to change this PR to go into melodic-devel and I don't think it worked, there are now many conflicts, I'll try to undo that.

[moriarty]

#105 changed this to

-<up_axis>Z_UP</up_axis>
+<up_axis>Y_UP</up_axis>

Yes, Y_UP is the default, I believe - so removing the up_axis tag altogether or changing it to Y_UP should not make a difference :)

So I'll close this, it's fixed in melodic-devel