Support for LWR 4+

[carlosjoserg]

Hi @shaun-edwards @gavanderhoorn

I think that our lwr4+ package is in a decent state to start the review for merging into ROS-I. How would you like to proceed? I can think of some options within a lwr4plus_support subfolder:

1. Since everything is on git/github, the repo could be added as a submodule
2. Since everything is CMake'd, I can configure an external project that clone a specific tag/commit
3. (I wouldn't like, but it can be if needed) Fork kuka_experimental and copy&paste all files and PR.
4. I wouldn't mind transferring it, but that will not go under kuka_experimental and also I don't have permissions in ros-i to keep the development (there is still plenty of work to do).

Do you have any other idea?

In the meantime, I will use CentroEPiaggio/kuka-lwr#46 to finish some minor stuff.

/cc @marcoesposito1988

[gavanderhoorn]

@carlosjoserg: thanks for considering contributing to the ROS-Industrial support for KUKA robots.

As to the options you propose:

1. I'm not too much of a fan of submodules: it's a nice idea in principle, but repository management is complicated by it, and support for it is less than ideal in ROS tools at the moment.
2. I'm not sure what you have in mind: who (or what) is doing the ExternalProject_Add(..) call in your setup (or in other words: which project/package is including who)?
3. this would be more in-line with how we've merged in contributions in the past. I can see why you'd not like that though. It would make things really transparent: all packages providing KUKA support would be hosted in one (possibly two) repositories.
4. obviously, if we decide to transfer the repository to the ROS-Industrial organisation, you'd keep your maintenance rights, as it would be ideally the case that you'd continue supporting the package (and I think you'd want to do that as well :)).

I think the biggest issue for merging at the moment is naming: packages, launch files, xacros and file & directory layout (something I think @marcoesposito1988 also recognised in CentroEPiaggio/kuka-lwr#23). This is something that is not a blocker, but should probably be addressed, as we try to keep things consistent across our repositories. We've found that it helps with maintenance, makes automation possible and allows developers / users to re-use knowledge and experience they've built up with other ROS-Industrial packages.

Do you have any other idea?

Not right now. I think I'd prefer option 3. I'm not convinced 1 & 2 are really something we should do. Option 4 would be ok, but would mean introducing a repository that hosts support for a 'single' robot series / model: not impossible, but a deviation from current practice.

@shaun-edwards, @Levi-Armstrong: opinions?

[shaun-edwards]

I'm in agreement with @gavanderhoorn on 3 & 4. Either of these options would allow us to do an "official" release, using the OSRF build servers.

FYI, I've asked @frederickproctor to try out this driver on his hardware. He is already familiar with some of the software, having used it for simulating in Gazebo. This is really a sanity check to make certain other developers will be able to get the driver/software to work on their systems.

[carlosjoserg]

Hi, many thanks for your support.

Ok, between 3 & 4, I would definitely go for the 4... even if we don't finally get access ;)

I think the biggest issue for merging at the moment is naming...

Yes. Thing is, I really like the structure I'm suggesting, but we can talk about that after we complete CentroEPiaggio/kuka-lwr/pull/46, we will try to finish as most as and as soon as we can and prepare the transfer (see below if you are interested in why I use that layout).

FYI, I've asked @frederickproctor to try out this driver on his hardware...

Sure, the more we use it, the better it gets.

/cc @marcoesposito1988

---

About the layout, I see xacro and launch files similar to c++ development, i.e.:

• Libraries: what you call macro in the urdf folder, which I prefer to call it model, devel-wise
• API: the parameters you pass to instantiate your model, in this case only name, parent and origin, devel-wise
• Apps: the macro you use to generate the urdf, which I prefer to call it robot, user-wise (to me, the moveit configuration goes here as well)
• Temporary files: the generated urdf, which I don't even bother to commit

Something similar goes for the launch files.

---

Side information about the first two points:

1. I used to think the same, but I have found them very handy for demo projects to have everything I need in one single repo and control the versions of the experimental packages. In the end, basically you just add --recursive for almost all commands, that's why I thought of it.
2. It reads rare, sorry. The idea was that I'd prepare a CMakeLists.txt file to be within the lwr 4+ folder at kuka_experimental configured to clone an external repository, look at this example that uses the catkin environment. Certainly for official releasing could be kind of a mess I think.

[carlosjoserg]

Oh, btw, I just checked on the newest github member management and now one can add external collaborators to an organization. So, even if I would be glad to, I don't need to be part of ROS-I to keep on maintaining the lwr 4+ packages.