search

CentroEPiaggio / kuka-lwr

Software related to the KUKA LWR 4+: for real and for simulation.
The Unlicense
101 stars 81 forks source link

Effort readings from Gazebo are zero #69

Closed kjyv closed 7 years ago

kjyv commented 8 years ago

When reading joint_state messages from simulation in gazebo, the effort values are always zero. This seems to be in turn because the call to GetForce(0) in lwr_hw_gazebo.hpp returns zero. The documentation even says it is not implemented. Looking at https://bitbucket.org/osrf/gazebo/issues/1321/proper-joint-torque-feedback it seems that indeed there are no proper torque measurements possible, some suggest using GetForceTorque(), the values of which would need to be projected to the joint axis. This might only be an upstream bug but maybe it is good for reference. Do the included torque based controllers work at all in simulation?

carlosjoserg commented 8 years ago

Hi @kjyv

Yes, the problem is upstream.

Using GetForceTorque() and projecting to the joint axis is kind of workaround.

This happens when using position_controllers since there is no actual PID, but the position is set directly. This is because we didn't want to tune a PID for simulation, and in the real case, KUKA already did a great job with the joint position control.

Do the included torque based controllers work at all in simulation?

They should, let us know if they don't.

kjyv commented 8 years ago

Ok, I guess you have to decide if you want a workaround to be implemented or not, but it seems that it is not going to be fixed in gazebo anytime soon (I think it's a bit ridiculous for such a big project). I basically wanted to prepare my experiment with the real robot in simulation and noticed that it didn't give these measurements. They are being set fine from the hardware/frl, so I'm ok for now. I'm not using torque control at the moment, I was only interested in the torque readings, so I can't comment on that (Does the torque controller not use the torque readings?) It seems to me though you focus more on the real robot even though for me the main benefit of this package seems to be the ability to transparently switch between simulator and hardware and getting similar results. For that though, a proper (tuned) PID controller is probably closer to reality, no? The kuka controller will have some delay in reaching a position, generate different velocities depending on the distance to the setpoints etc.

carlosjoserg commented 7 years ago

Nothing to add for now. If you are willing to add this functionality for the workaround, you are welcome.

I re-read the issue on bitbucket, and it seems that the workaround was not properly working either, and the PR was declined.

For that though, a proper (tuned) PID controller is probably closer to reality, no?

Yes, but you would need to have the exact dynamic values of the arm, match the PID gains from KUKA position control (nobody that I know has access), and expect it behaves exactly the same.

Conclusion, closing for now, but thanks for pointing out the issue with gazebo.