Holding position problems

[yaoxt3]

I would like to express my appreciation for your valuable contributions. However, I am currently encountering some issues with the holding position when launching the 'bringup.launch' file with torque control mode (stiffness = 0). Once the stiffness is selected, the robot seems to be unable to maintain its position, indicating a possible lack of gravity compensation.

holding.problem.mp4

The 'iiwa_driver' is functioning correctly, and the '/iiwa/joint_states' is publishing real-time robot states. Furthermore, there are no tools attached to the end effector, and I have already completed the calibration via the 'PositionAndGMSReferencing' application on 'smartPad'.

I would greatly appreciate any suggestions or advice you could offer to help resolve this issue. Thank you in advance for your assistance.

[yaoxt3]

I'm using FRIOverlay since there is no tool attached to the EE. The video shows that the robot begins to fall down after selecting the 0 stiffness option on 'smartPad'.

[costashatz]

@yaoxt3 honestly it's been too long since I last used an IIWA robot to remember what happens when stiffness is set to zero. I think that it should still have gravity compensation. On the other hand I do remember that some "poses" were more difficult for the gravity compensation than others. Can you make sure that there's no end effector in your KUKA smartpad? Not FRIOverlayGripper but selected/calibrated on your smartpad.

Other than this @matthias-mayr maybe has more intuition about what happens here.

[yaoxt3]

Thank you for your reply. I will contact Mayr for further assistance with this issue. I appreciate your help and insights. If I am able to find a solution to this issue, I will update it here and close the issue. Thank you again for your time and assistance.

[costashatz]

No worries. Matthias is already tagged in the issue. He will reply if he has any ideas.

Btw, if stiffness is not set to zero, does gravity compensation work as expected?

[yaoxt3]

I have attempted to set the stiffness to 20, but unfortunately, the robot is running randomly. While when I set the stiffness to zero, the robot did not run randomly, but there was no gravity compensation.

[CodingCatMountain]

Hi, developer! .The situation: when we set the stiffness to 20 or more and the mode is Torque then the robot runs randomly. Is it a bug or something that needs to specially deal with? The situation also happened in the KUKA iiwa7 of our lab. : )

[matthias-mayr]

There would always be a calibration error and my take is that what you are observing is that error.
You can run something like a Cartesian impedance controller that would be able to handle such differences.

You can also run the calibration procedure and use the "GripperOverlay" Java. However, the results of the calibration vary and the robot would still move when in torque mode. If you want to avoid that you need to add your own compensation on top of what KUKA does.

[yaoxt3]

Thank you. I'll have a try! If I fix this issue, I'll update my solutions.

[yaoxt3]

Hi @matthias-mayr, thank you for your advise.

I successfully installed Cartesian impedance control, which has allowed the robot to hold its position, since the stiffness of joints is non-zero. However, we now want to implement an impact-friendly demo using the torque controller, which requires the robot's stiffness to be reduced.

Following your previous suggestion, I added a specific weight of tools to the end-effector and used the load data on the smartpad to automatically obtain calibration data. However, I have observed that while the robot can maintain its position in certain positions, it struggles in others. It appears that the automatically acquired data may not be entirely accurate.

In a previous discussions, you mentioned mapping external torques to virtual mass. I would greatly appreciate it if you could provide more information on how to perform this mapping.

Thank you once again for your assistance.

[matthias-mayr]

Following your previous suggestion, I added a specific weight of tools to the end-effector and used the load data on the smartpad to automatically obtain calibration data. However, I have observed that while the robot can maintain its position in certain positions, it struggles in others. It appears that the automatically acquired data may not be entirely accurate.

That is the behavior that people typically experience.

In a previous #84, you mentioned mapping external torques to virtual mass. I would greatly appreciate it if you could provide more information on how to perform this mapping.

I did not implement this myself, but the basic procedure is to go to a set of poses. Let's say 50, obtain the external torques (that should not be there) and then solve e.g. a least-squares problem that estimates a mass mounted to the EE that best explains the external torques. He said that this was sufficient for him.
However after that, one would also need to implement the compensation. For example in this driver.

Multiple people have the same issue. I know at least 5 by now (like @anubhav-dogra in this issue), so if anyone would do it, that would be greatly appreciated.