[lwr_hw] enhancement

[carlosjoserg]

:hammer: in progress...

The most important changes concern the [lwr_hw] package. The other ones are a consequence of those changes.

A good consequence is that this does not depend in the fork of ros control, since the lwr_hw_sim plugin knows the urdf naming convention and the number of joints, so it only suffices to have the name of the robot, and all joint names are known for that instance of the arm, and the transmissions are filtered out according to that value, see here.

As described in https://github.com/CentroEPiaggio/kuka-lwr/issues/19#issuecomment-115153852, the package uses the joint command interfaces as a (temporal) solution to switching control strategies. I think a more suitable way would be to develop either a ImpedanceJointInterface that expose the FRI command values and use a controller, or having Pos, Sitff and Damping as dynamic paramters of all controllers when switching to EffortJointInterface (hence JOINT_IMPEDANCE -> Strategy 30 in FRI) as the PID gains, or wait for something like a joint_mode_controller.

In the meantime, the drawback is that I couldn't find a way to have more than one controller to act in a commanding interfaces, so the old joint_position_controller and joint_stiffness_controller can't work simultaneously, since the first triggers the strategy 10 (in fact, the latter as well as it uses the PositionJointInterface, but it'll do nothing because those commands will not be written to the robot, real & sim)

ATTENTION: I haven't tried the new single script because I'm not in the lab, but I will tomorrow and come back, but in the meantime I thought you might be reviewing the changes.

Comments are very well welcome !

[carlosjoserg]

[Update]

1. Now the script manages the mode switch properly.
2. Initial work to support also the Stanford library (fork with cmake-enabled by https://github.com/iocroblab/fril)

[carlosjoserg]

Final comment on the enhancement, update in travis config to compile in Ubuntu 14.04 :beers:

[carlosjoserg]

What remains, just need to think of how to deal with 3 things:

• Control cycle: For controller switch, I couldn't do it under 20ms without errors. However, without switching, stuff can run at 2ms. Perhaps I can't escape from having two scripts!
• The updated gravity compensation controller (I know it is useful to you right now) uses the EffortJointInterface that triggers the FRI joint impedance strategy with default values, see here and sends 0.0 torque here, but the behavior is not so smooth due to the 20ms I believe.
• [Optional] The update allows to add very quickly other interfaces, for instance, I started working on the Stanford FRI, but there is an issue with sudoing, which is not good for ROS.

---

One more thing, I like minimal interfaces in general, specially to the urdf model, but I'm thinking that, due to robot composability issues, it might be useful to have a flag to load or not the kuka plugin when you instantiate the model (default: true, of course), i.e. something like:

<xacro:kuka_lwr parent="box" name="lwr" loadGazeboPlugin="true">
    <origin xyz="0 0 1" rpy="0 0 0"/>
</xacro:kuka_lwr>

Any ideas?

[carlosjoserg]

Alright!

I managed to use the Stanford library as well which is really nice done to do the controller switch as well. Some limits are to be increased as explained in the README

Hopefully I will test it during the week, after that, I'll do the merge...

[marcoesposito1988]

@carlosjoserg: wow, I had completely overlooked this, I just found out about it now! :see_no_evil:

It sounds awesome, I'll get a look at it in depth.

[marcoesposito1988]

I think the major issue that remains is impedance mode.

The cleanest solution that comes to my mind would unfortunately require a lot of work: if it were possible to create composite interfaces, then we could write an "ImpedanceJointInterface" which would lock the Position and Effort interfaces, and accept setPosition, setStiffness, setDamping and setEffort commands, redirecting setPosition to the PositionJointInterface's setCommand, setEffort to EffortJointInterface's setCommand, and taking care of damping and effort. This would have the advantage of fitting into the framework, and allow to clearly state why the position and effort interfaces are activated at once.

What do you think about it?

[carlosjoserg]

Yes, I know what you mean, I agree it would be nice to just say Impedance = Effort (joint) + Poisition (joint) + Position (stiffness) + Position (damping), however it might not be available in short times, and I'm not sure now how to tackle it.

[carlosjoserg]

That was the last commit including naming fixes and added the e-stop for the kuka fri node. I don't think I will be able to test the Stanford interface #sigh, so, most likely I'll merge tomorrow morning, because changes start to accumulate.