[ENHANCEMENTS] multi-robot-test -> master

[carlosjoserg]

Hello everyone,

I've been using the multi-robot-test branch to continue developing the package. The motivation to do this is that there is a not-so-good dependency when composing the arm in a multiple robot configurations in simulation. In that case, and hence, to compile the package, our forked version of ros-indigo-ros-control is required, explicitly, this tree due to a small change in the transmission_interface package. The reason is described in ros-simulation/gazebo_ros_pkgs#297.

Thus, there are several things in this PR, but I will document later in the README about how to use the package. Some changes are still pending to include external work by @marcoesposito1988 and to show examples on how to use the package, so stay tuned.

For the moment, few issues are addressed:

@gpldecha The issue you were having in #17 does not happen with this PR.

@ahoarau In this PR, the arm simulation hw interface adds the gravity term as the real controller box does, though the dynamic model in the xacro is not accurate. And, I need to delete the hydro-devel branch, the doc attribute in the launch files hopefully won't be a problem in what I intend to do with the package.

@anaceri With this PR, you can control position and stiffness using joint impedance control strategy. Hence, you can plan&execute both simultaneously in both real and simulation.

/

Finally, and sorry for the delay, @marcoesposito1988 after this PR, I'm making you collaborator to continue porting the package close to be ROS-I compliant.

Thanks!

[marcoesposito1988]

Hey Carlos,

this looks amazing, everything is tidier and more logically structured. And the improvements to the simulation also sound very good. There are only a couple of small "regressions" (for example the missing moveit_planning_execution.launch) for which I will make pull requests on top of this one, if that's ok for you.

Unfortunately I cannot start lwr_launch/lwr.launch because of a segfault:

gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = urdf::JointLimits; typename boost::detail::sp_member_access<T>::type = urdf::JointLimits*]: Assertion `px != 0' failed.

I don't understand the reason, since the URDF is properly loaded. Do you get any error like that? Are you using hydro? I am on Indigo here.

[carlosjoserg]

Hi @marcoesposito1988

Indigo as well. Which version of Gazebo are you using? It should be 4, see instructions to install here. Let me know.

I couldn't make you a collaborator without making you part of the organization, and I wouldn't want that. Is it ok for you to keep the Fork&PR mode? I will be doing the same but with branches. If you do it with branches as well like gravity-compensation-feature, moveit-to-real-connection, marco-devel, etc, I would merge always your PRs and then discuss the branch-to-master merge later, what do you think?

I'm ok with PR-ing again the regressions, only that wait a bit and take a look at the structure I have in mind in the README (suggestions welcome). The regression you mention will go within the single_lwr_moveit package. In fact, I can set up the template, but if you want, that single_lwr_example package could be your usecase directly if you don't have external dependencies.

[marcoesposito1988]

@carlosjoserg: The Fork&PR workflow is perfectly ok for me, that is not a problem.

About the structure, I think it would be better to make it more uniform to the existing packages in the ros-industrial repo here. That structure makes it already possible to use the arm in a more complex robot.

[gavanderhoorn]

Just pitching in: I can support you guys with (re)structuring your packages to ros-i spec. If you're stuck with something, or anything is unclear just let me know.

[carlosjoserg]

That is great, @gavanderhoorn, I think it won't be exactly as it is in ROS-I, but something we can do. Once we have a quasi-definite 0.1.0 version, your help will be appreciated.

Good @marcoesposito1988! Ok, the thing is, in contrast to what's in ROS-I, to me, the moveit configuration depends on how you mount the arm in your lab scenario and other parts, table, etc., and not in the arm itself, so that part should be the user doing it.

And also, the definition of the models and its use is all mixed up, like in here.

The motivation behind the structure I propose in the readme is to have a clear example on how an user can configure-only a custom package relying on the kuka lwr packages. I will push in minutes two of the single_lwr_example to show you ( @marcoesposito1988 don't panic, since I'm deleting also the lwr_moveit and lwr_launch but they are becoming single_lwr_moveit and single_lwr_launch packages! )

[carlosjoserg]

@marcoesposito1988 I think I'm done with the changes I wanted to make. Let me know what you think, I believe they are for good.

I think in the way I ate the gravity compensation part but haven't checked, and I believe you have already something with the position control strategy since I understand you are using that strategy.

However, as I told you by email, it it'd be great if we can implement a full krl script that allows the change of strategies on-the-fly instead of having to change the script.

The strategy can be triggered by manually changing the interface in the urdf/transmission using proper controllers, or by using a desired controller that would trigger the interface change folloing controller -> hardware_interface -> krl, using the recently added notifier function.