Introducing Gazebo support for RX160/RX160L

[MuriloMartins]

@gavanderhoorn Could you please verify this PR to add support for simulation of Staubli RX160/160L robot sin Gazebo 2.x.

It follows the design standards discussed in ros-industrial/abb_experimental#18.

Some remarks regarding this PR. Firstly, I had to open the .stl files of some links in meshlab and save them again as .stl so that I could apply colour to those links in Gazebo (the original files were not working).

Also, I changed the colours to represent the real robots we have (they are actually yellow, not orange, but that is purely cosmetic).

Lastly, inertia matrices, as well as link masses, at the moment do not represent the actual real robot.

Although maximum speed and torque are documented in the robot manual, inertia matrices and/or COGs are not. I tried to follow this tutorial to extract the data from the CAD models, but I got matrices filled with nans for most joints.

I tested MoveIt with the simulated robot and it works just fine.

[gavanderhoorn]

Quick comment: there are numerous places that (re)introduce tabs instead of spaces, mostly in launch files and xacro macros. #14 changed those all to spaces. Could you make sure to use an indentation of 2 spaces for each level?

re: colours: the colour is based on information I found that Staubli used RAL 1028 for the RX160. If your robots have a different colour, please just add it to the relevant files. Removing the current xacro property it is not an option, as we do not know where it is being used.

[MuriloMartins]

Thanks for pointing that out! I didn't realise vim was changing the indentation...

I fixed and rebased the PR.

I reverted the colour for the RX160, but left the new yellow to be used with the RX160L (I think that also helps distinguishing amongst them -- does that make sense?).

[gavanderhoorn]

@MuriloMartins wrote:

Thanks for pointing that out! I didn't realise vim was changing the indentation...

I fixed and rebased the PR.

ok, thanks for that.

I reverted the colour for the RX160, but left the new yellow to be used with the RX160L (I think that also helps distinguishing amongst them -- does that make sense?).

Yes, this is ok.

I'm actually considering to just name the colours after their RAL name (ie: Melon yellow for 1028, and Zinc yellow for 1018). They already have a name, and it would make things more maintainable as well, instead of having to come up with names ourselves all the time. We could still have colour_staubli_yellow, but it would just be an alias of whatever it turns out that Staubli is actually using.

[gavanderhoorn]

As to this PR: I hate to ask this of you, but could you split it into two? One against this repository, containing just the changes to resources and rx160_support, and one against ros-industrial/staubli_experimental, introducing the experimental Gazebo pkg.

Nothing in the Staubli repositories has been released, but the _experimental repositories allow us to do some, well, experimenting without worrying about backwards compatibility and support. I try to take that serious, hence my request.

Let me know if that is possible for you (I'm willing to do it myself).

[gavanderhoorn]

I'll wait with reviewing the changes until after you've updated the PR(s).

[MuriloMartins]

I split the PR and updated the colour names to use standard RAL naming (the macros are still using the names previously used to avoid changing URDF files - perhaps we should propagate the changes?).

The staubli_rx160_gazebo package is now the ros-industrial/staubli_experimental#1.

[gavanderhoorn]

Some comments, mostly about how to name things (and then mostly the colour properties).

Firstly, I had to open the .stl files of some links in meshlab and save them again as .stl so that I could apply colour to those links in Gazebo (the original files were not working).

Hm, I don't quite understand why that would be necessary. I'll try and see if I can get Gazebo to reproduce the issue you are describing. Looking at the 'rendered diff' Github shows, it looks like a few faces have been changed in link_1.stl. The meshes have been edited with meshlab before, so I don't really get why things would be different this time.

[gavanderhoorn]

As to the RAL colours: these are obviously not Staubli specific, but without a prefix playing poor man's namespace, I think we run the risk of nameclashes (with unusable xacro macros as a result). So for now I suggest we just use colour_staubli_ral_ as a prefix for all of those.

[MuriloMartins]

@gavanderhoorn the difference in the .stl files might have been due to a version of meshlab, or the settings whilst saving the mesh as .stl. I literally opened the files and exported to .stl, having not done anything else, it is surprising a few faces have changed.

I could not apply colour to the previous meshes, and I accidentally realised that when analysing how the meshes used for collision in Gazebo influenced the ROS effort controllers I used (before switching to position controllers).

We could get the .stl files from the official CAD model again (though I assume that's where they came from at first place).

[MuriloMartins]

@gavanderhoorn could we please revisit the desired changes regarding colours, I lost track of what we've discussed previously (sorry about that!).

[gavanderhoorn]

@gavanderhoorn could we please revisit the desired changes regarding colours, I lost track of what we've discussed previously (sorry about that!).

Yes, no problem. I'm preparing a PR (agains your PR) right now.

[gavanderhoorn]

@gavanderhoorn could we please revisit the desired changes regarding colours, I lost track of what we've discussed previously (sorry about that!).

@MuriloMartins: I've just submitted ocadotechnology/staubli#1. Does that clear things up?

Sorry for being to persistent with this, but I feel it'll pay off later.

[MuriloMartins]

@gavanderhoorn thanks for the changes, I've just merged your PR. I agree, the earlier we get things sorted the better.

I'll propagate the changes to the colour macros into my packages.

[gavanderhoorn]

@MuriloMartins: we can go ahead and merge this. Two minor things:

1. please add this comment (wording doesn't need to be identical) about the max joint torque for joint_6 as an NB in the package manifest, similar to the note about the values in the inertial tags. I'd like to make such 'design decisions' (if those exist for urdfs) as explicit as possible. Perhaps also a quick note in the xacro macro itself, as a line-comment above the joint_6 limits declaration?
2. squash all commits in this PR into a single "rx160: prepare for Gazebo support." (or something)

I'll merge the PR then.

[MuriloMartins]

@gavanderhoorn Great, I'm on it. Could you please confirm that the torque limits from version D28075404C are the same as in version D28086504A of the instruction manual (in case you have access to it), just so we avoid mentioning 2 different versions of the manual as sources of information.

[gavanderhoorn]

Could you please confirm that the torque limits from version D28075404C are the same as in version D28086504A of the instruction manual

Yes, D28086504A has the same values.

[MuriloMartins]

Thanks! I've just rebased the PR. Let me know if it looks OK. :-)

[gavanderhoorn]

Yes, this is ok.

+1.

[gavanderhoorn]

Thanks for contributing @MuriloMartins, much appreciated.

[MuriloMartins]

No worries. :-)

[gavanderhoorn]

@MuriloMartins wrote:

Firstly, I had to open the .stl files of some links in meshlab and save them again as .stl so that I could apply colour to those links in Gazebo (the original files were not working).

I think I figured this one out: meshlab by default (at least on my machine) has Materialise Color Encoding checked in the Choose Saving Options dialogue. This would seem to be a Materialise Magics compatible type of saving STLs, which embeds (non-standard) colour info in the STL header (see STL (file format) - Binary STL - Color in binary STL on Wikipedia).

I haven't checked, but it could be that the STL loader Gazebo uses recognises this, and Gazebo then doesn't allow any other colours to be configured for the mesh (just as RViz ignores material tags on Collada meshes). Another option is that Gazebo's STL loader is just confused, does something strange with the end result being the same: issues with configuring colours for meshes.