Added torque-only client_command_mode.

[xmatousm]

Our proposal to torque-only command mode (related to #303). Tested on rolling and humble.

[mhubii]

sorry this went past my attention! Will review this next week.

[xmatousm]

Never mind. Anyway, there was a bug about determining when the commands starts coming from the client. Hope now its fixed. Currently it is tested in humble, I will test this in rolling tomorrow.

[mhubii]

okay just had a brief look, looks pretty reasonable. Will try run this.

Thx for the effort

[mhubii]

Just FYI, trying to get #271 in first.

[mhubii]

Sorry for the delay here. Everything is now setup and I will look into getting this merged ASAP and don't want to block you here.

Just for my understanding and context, are you looking into using something like CRISP: https://github.com/utiasDSL/crisp_controllers?

[xmatousm]

Maybe. I'm not familiar with the CRISP library, as in the project I'm working on (https://www.agimus-project.eu/) the solution for model predictive control is developped, which uses the effort-only interface of a robot.

[mhubii]

Okay got you. Just a quick question, did you run a load data calibration?

[xmatousm]

Course I did. But in some situations the accuracy of the calibration is not enough - sometimes the stack of ros nodes and controllers starts too long that the robot unwanted motion during a "fall" is considerable (and the issue can be expected when robot with some payload in its gripper is e.g. emergency stopped)

[mhubii]

Course I did.

Got you, sorry just checking in case!

[mhubii]

Sorry for not merging atm.

My understanding is the robot fell in compliant control modes due to slow controller spawning.

I was wondering whether there is a mechanism for the SystemInterface in ros2_control to understand whether it is currently being controlled or not.

The other shortcoming is that this stack misses abstraction to be extendible.

[xmatousm]

Yes, the slow controller spawning/switching is the reason.

The other thing, which our change is solving, is that any effort-only like controller sends only torques, but the FRI needs positions as well (though all stifness is set to zero at sunrise side).

[mhubii]

would it help you have this on the humble branch? I am happy to merge things as they are there.

[xmatousm]

This is not necessary. We have several project in out lab working with one or two iwa-7 arms, in one project, we are still on humble, but in other we moving to jazzy, etc, so creating PR on rolling is fine for me. (Its only unclear to me how to properly back-port then). So if you think that merging makes sense, I will look at the last changes in the (upstream) code-base and will create updated PR. I can do this probably after next week first.