Introducing ROS support for Staubli TX90 family

[MuriloMartins]

I added support for the TX90 family as well (it is essentially a clone of the RX160, mostly renaming files and robot names within files).

As with the RX160, meshes come from the official STEP file from Staubli, joint, velocity and effort limits from the official Staubli manual, and moments of inertia were extracted from the official CAD using SolidWorks.

[gavanderhoorn]

Thanks for separating the PRs.

Quick question: do the TX90 and the TX90L share any meshes? As in: would it be possible to store the common ones just once, and then add only the different ones (probably link_4?) to the meshes/tx90l folder?

[MuriloMartins]

Links link_2 and link_4 are different between TX90 family variants.

So yes, there are common meshes which can be shared.

I'll make the changes and make sure everything works, then I'll update this PR.

[MuriloMartins]

I made the changes and tested, everything seems fine. I also regenerated the URDF files.

[gavanderhoorn]

Thanks.

re: masses, coms and inertias: I don't know how good your Spanish is, but we might be able to use the information from Modelado Dinámico y Simulación del robot industrial Stäubli TX90.

[gavanderhoorn]

@MuriloMartins: I can either rebase & squash this myself on top of indigo-devel and merge, or you could update the PR. Preference?

In case you update the PR: could I ask you to split it in two? One for the _support package, and one for the _gazebo package. Should just be a matter of juggling the commits a bit.

[MuriloMartins]

I can split PR #2 in two, but does it really make sense? I mean, _gazebo depends on _support.

I can rebase & squash, no problem.

re: masses, coms and inertias: that document was really interesting, thanks for sending me the link! I think there are 2 reasons as to why we should use the data from SolidWorks. 1) This is the method described in one document from Staubli which I found in their resources page, and 2) for consistency across robot models (perhaps not that important). What do you think @gavanderhoorn ?

[gavanderhoorn]

I can split PR #2 in two, but does it really make sense? I mean, _gazebo depends on _support.

well, yes. So, _support in the first, and _gazebo in the second :).

I can rebase & squash, no problem.

ok, great.

re: masses, coms and inertias: that document was really interesting, thanks for sending me the link!

no problem. Interesting because of the LLI info probably?

I think there are 2 reasons as to why we should use the data from SolidWorks. 1) This is the method described in one document from Staubli which I found in their resources page, and 2) for consistency across robot models (perhaps not that important). What do you think @gavanderhoorn ?

hm, yes. Consistency might be a good reason not to use the data from the thesis. Let's keep what you have now.

[MuriloMartins]

Ok, I'll split the PR then.

I just thought that having two PRs on indigo-devel would mean that the first one (_support) would merge and work fine, but the second one (_gazebo) would fail because it would depend on another pending PR.

As long as people merge both PRs locally in order to test the packages, it should be fine. Although I have feeling it's only @gavanderhoorn testing anyway...

If you're happy with the split, I can easily do that.

[gavanderhoorn]

Having multiple PRs that have a dependency relation isn't really a problem. If we want to be nice, you could always mention that PR X depends on PR Y.

Reason I'd like to have two separate PRs is that they introduce two (related, but individual) changes: one is the regular robot support package for a new model, the other introduces additional functionality that just happens to be related to the robot support pkg introduced earlier.

[MuriloMartins]

I'll close this PR and open two separate ones, it will be tidier...