Gravity compensation while publishing in TF (plus more tuning)

[marcoesposito1988]

This change allows to move the robot in gravity compensation mode while logging the position to TF. This mode can be useful for performing a hand-eye calibration or to use the robot as a tracking device (both scenarios are a reality in my working place, and this mode was extensively debugged in both cases).

• A ros_monitor.{src,dat} KRL script is added (differs from the previous one only in that it sets a different mode)
• A couple of lines in lwr_hw.cpp are modified in order to keep the FRI connection alive in gravity compensation mode, without doing anything
• An lwr_launch / state_publisher.launch file is added that starts the joint_state_controller, uploads the robot description to the parameter server and starts a robot_state_publisher node; should be started after lwr_hw.launch

Plus, the PID tuning was further improved by Salvatore Virga.

[carlosjoserg]

It looks promising, entering in gravity compensation is really useful. However, I have a question: isn't it possible to do it with a single script plus a switch mode service on the lwr_hw ? (I believe it can be also useful as an emergency reaction)

In any case, this PR is a first step, so I will try the patch over the weekend.

[marcoesposito1988]

Actually the purpose of the patch is not just to move the robot in gravity compensation (there is some native option in the menu for that), but to log the position of the robot in real time in TF. The _joint_statecontroller reads the status from the FRI controller, then the _robot_statepublisher node creates a TF frame for each joint.

BTW, I just found out that I messed up the git merge badly after the directory reorganization; sorry about that, I am still cleaning up after it.

[carlosjoserg]

Hi @marcoesposito1988, I tried the patch, and it works fine. What I don't like too much is having to change the script, but we can think of improving that in the future.

Another thing is, why do you need the file state_publisher.launch instead of using roslaunch lwr_launch lwr.launch use_rviz:=false controller:=joint_state_controller ?

And last thing, I don't see a change in the lwr_hw/src/friremote.cpp, only change of lines, could you please checkout the repo version and commit nothing on that?

With this in mind, I would ask you to propose another PR considering this comments.

[marcoesposito1988]

Hi Carlos,

• I think that having two different scripts is the most practical thing (otherwise the user would have to input something everytime the script is restarted, i.e. every time the user's hand gets tired of keeping the buttons pressed)
• I added another launch file because the common launch file launches the _joint_statecontroller plus something else, and even if the user enters controller:="" the default argument kicks in (OneTaskInverseKinematics)
• My bad, the change is in _lwrhw.cpp. I will revert the change.

2015-02-16 10:34 GMT+01:00 Carlos J. Rosales notifications@github.com:

Hi @marcoesposito1988 https://github.com/marcoesposito1988, I tried the patch, and it works fine. What I don't like too much is having to change the script, but we can think of improving that in the future.

Another thing is, why do you need the file state_publisher.launch instead of using roslaunch lwr_launch lwr.launch use_rviz:=false controller:=joint_state_controller ?

And last thing, I don't see a change in the lwr_hw/src/friremote.cpp, only change of lines, could you please checkout the repo version and commit nothing on that?

With this in mind, I would ask you to propose another PR considering this comments.

— Reply to this email directly or view it on GitHub https://github.com/CentroEPiaggio/kuka-lwr/pull/10#issuecomment-74480825 .

[carlosjoserg]

I'm still thinking of the gravity compensation. For instance, using joint impedance control strategy with 0 added torque and 0 stiffness will give you the desired behavior. But I think that the robot joint limits will jump if you arrive to the limit while doing it, since the robot is being controlled.

Still thinking, in the meantime, this PR looks much better, thanks for the contribution.