Example of higher-level torque control

[adamconkey]

I am working on setting up a higher-level torque controller in the sense that I will be using the iiwa_ros torque control mode to expose the /iiwa/TorqueController/command topic, and then my torque controller will be sending commands to that topic. I have some controllers that do this kind of thing, but I'm wondering if you have a higher-level controller you use that you could point me to for guidance. I'm specifically wondering if your higher-level controllers are also implemented in the ros_control framework, or does the usage of that stop with the iiwa_driver?

One concern I have is if I have the KUKA in torque control mode with zero stiffness/damping and I'm sending my own torque commands, if my controller cuts out for some reason while the robot is in motion, it seems there is nothing to prevent the robot from continuing to move. Is there a good mechanism for this situation, that if my high-level controller stops sending torque commands, the robot could enter a relatively safe stop state?

[JimmyDaSilva]

I'm specifically wondering if your higher-level controllers are also implemented in the ros_control framework, or does the usage of that stop with the iiwa_driver?

Sorry. Mostly working on position controllers for the moment.

Is there a good mechanism for this situation, that if my high-level controller stops sending torque commands, the robot could enter a relatively safe stop state?

While sending torque commands to the IIWA, you need to send position commands as well (even if the stiffness and damping parameters are null). See image below from the FRI documentation:

If the position commands differ to much from the current position, there is an exception sent.
Maybe you could catch this exception to start a new "safety" controller, doing basic positioning

[costashatz]

While sending torque commands to the IIWA, you need to send position commands as well (even if the stiffness and damping parameters are null). See image below from the FRI documentation:

This is already done in iiwa_ros driver. So no need to worry about that.

One concern I have is if I have the KUKA in torque control mode with zero stiffness/damping and I'm sending my own torque commands, if my controller cuts out for some reason while the robot is in motion, it seems there is nothing to prevent the robot from continuing to move. Is there a good mechanism for this situation, that if my high-level controller stops sending torque commands, the robot could enter a relatively safe stop state?

I will try to reply to this as soon as possible. Short comment: your question is a bit fuzzy (will explain in my next comment; I need to better understand what you mean to reply ;) ).

[adamconkey]

@costashatz the scenario I'm thinking of is suppose I'm using Torque mode on KUKA with zero stiffness damping, and then I use a higher level computed torque controller (e.g. PD controller) to send commands to the ROS topic offered by iiwa_ros. Suppose while I'm sending commands with my PD controller and the robot is moving, the node dies - maybe I accidentally kill the process with Ctrl-C or I have software safety checks that I actually want my PD controller to stop sending commands. Then the KUKA torque controller stops receiving my computed torque commands, but because it has zero stiffness/damping, I feel like at this point the robot will just keep moving.

One way to resolve this would be, when my PD controller exits, the stiffness gains on the KUKA get increased and a position setpoint for the current robot joint configuration is set so that it tries to just halt where it is. Basically, that the iiwa ROS driver could keep the robot in a higher stiffness mode with a position setpoint until it actually receives client torque commands, and then set the stiffness to zero as long as it's receiving commands. Maybe you have some insight on why this would be a bad idea, or if it's even possible to do.