exposing joint impedance controller through ROS control

[Georg Bartels]

Hi all,

I have a manipulator with a custom controller which comes with an usual interface: at 1kHz I can command an effort AND stiffness value to every joint. So, my command consists of 2 doubles for every joint. That seems to be beyond the scope of the joint-command-interfaces provided in ros-controls. Do I see this correctly? If yes, how would you expose this interface to the hardware manager?

Obviously, I introduce the constraint of wanting to reuse as many of the existing controllers as possible. Meaning: I definitely want to have the joint-state-publisher. Using all the effort controllers (with a default stiffness value maybe provided as a parameter) would be outstanding!

Initial brainstorming led me to two alternatives:
1) Creating a new type of JointHandle which supports 2 doubles. However, I doubt that any of the plugins would still work in this case.
2) Exposing the effort command as an EffortCommandInterface, and the stiffness command as a PositionCommandInterface. For this scenario: Is it possible to write a controller plugin which fills both command interfaces with values received in a ROS message?

Looking forward to your suggestions!

Cheers,
Georg.

[Adolfo Rodríguez Tsouroukdissian]

On Thu, Mar 12, 2015 at 5:53 PM, Georg Bartels <georg....@cs.uni-bremen.de> wrote:

Hi all,

I have a manipulator with a custom controller which comes with an usual interface: at 1kHz I can command an effort AND stiffness value to every joint. So, my command consists of 2 doubles for every joint. That seems to be beyond the scope of the joint-command-interfaces provided in ros-controls. Do I see this correctly? If yes, how would you expose this interface to the hardware manager?

Obviously, I introduce the constraint of wanting to reuse as many of the existing controllers as possible. Meaning: I definitely want to have the joint-state-publisher. Using all the effort controllers (with a default stiffness value maybe provided as a parameter) would be outstanding!

Hi Georg,

If you don't care about setting effort and stiffness separately, through different ROS interfaces, you can simply create a new JointStiffnessInterface class, and write a controller that takes a topic or action command for driving stiffness. If you go this way, it wouldn't be possible to write a controller that commands the two interfaces simultaneously (effort + stiffness).

To be clear about your question, do you want to reuse existing read-only controllers only, like the joint_state_controller, or do you also want to leverage existing controllers that actually write commands?.

Adolfo.

Initial brainstorming led me to two alternatives:
1) Creating a new type of JointHandle which supports 2 doubles. However, I doubt that any of the plugins would still work in this case.
2) Exposing the effort command as an EffortCommandInterface, and the stiffness command as a PositionCommandInterface. For this scenario: Is it possible to write a controller plugin which fills both command interfaces with values received in a ROS message?

Looking forward to your suggestions!

Cheers,
Georg.

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

[Georg Bartels]

Hi Adolfo,

thank you for your quick response! I want to expose the effort and
stiffness interfaces such that I can

1) re-use the joint-state-controller

2) use the existing effort-controllers to drive only the effort and
use a default value for stiffness

3) have the possibility to write a controller which drives both effort
and stiffness offering a single ROS msg/action interface to the outside

I would need some sort of switching between 2) and 3). For initial
experimentation restarting the entire controller manager node is fine.

Does that make my question clearer?

Cheers,
Georg.

P.S.: I just realized that requirement 1) is somewhat orthogonal to 2)
and 3). So, let's focus the discussion on use case 2) and 3)!

[Georg Bartels]

Hi Adolfo,

would this work?

1.) Create new class JointStiffnessInterface with basically only
setStiffness and getStiffness, no inheritance.
2.) Create new class JointImpedanceCommandInterface which publicly
inherits from JointCommandInterface and JointStiffnessInterface.
3.) Create new classes
Effort/Velocity/PositionImpedanceCommandInterface as aliases from
JointImpedanceCommandInterface.

Then I can still load the existing controllers on this and write a
custom control specifically for my EffortImpedancCommandInterface.

Cheers,
Georg.

[Carlos J. Rosales Gallegos]

Hi Georg,

We have the same situation with our Kuka LWR 4+, where actually there are 3 doubles: effort, position and stiffness for each joint using the joint impedance control strategy.

We are using the position_controllers/JointPositionController type already available in ros-controllers for both position and stiffness commands, for which I register position interfaces in the HWI. This allows to control everything independently using a single HWI.

But for a comprehensive impedance command, we also have this: https://github.com/CentroEPiaggio/kuka-lwr/blob/master/lwr_controllers/src/joint_impedance_controller.cpp (WIP), for which we use only a registered effort interface in the HWI.

Best

Carlos

>>> ros-sig-robot-control+unsub...@googlegroups.com. For more
>>> options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>

[Adolfo Rodríguez Tsouroukdissian]

On Thu, Mar 12, 2015 at 7:50 PM, Georg Bartels <georg....@cs.uni-bremen.de> wrote:

Hi Adolfo,

would this work?

I'll reply inline to your two previous posts (most recent first due to top posting):

1.) Create new class JointStiffnessInterface with basically only
setStiffness and getStiffness, no inheritance.
2.) Create new class JointImpedanceCommandInterface which publicly
inherits from JointCommandInterface and JointStiffnessInterface.
3.) Create new classes
Effort/Velocity/PositionImpedanceCommandInterface as aliases from
JointImpedanceCommandInterface.

All are valid. It depends on how you want to use them. I would suggest exposing the existing hardware interfaces without stiffness, and then whatever combinations works best for you. If you expose separate resource claiming interfaces for the same resource name (e.g., EffortJointInterface and JointStiffnessInterface for "foo_joint"), you'll need to override the default resource conflict policy, which is exclusive resource ownership. This is done in RobotHW::checkForConflict(...).

Supporting multiple interfaces per controller has been discussed many times in the issue trackers, but nobody has wanted it bad enough to champion the effort. It also needs to be rolled out on a new ROS distro because APIs will break.

(more below on your older post)

Then I can still load the existing controllers on this and write a
custom control specifically for my EffortImpedancCommandInterface.

Cheers,
Georg.

On 03/12/2015 07:22 PM, Georg Bartels wrote:
> Hi Adolfo,
>
> thank you for your quick response! I want to expose the effort and
> stiffness interfaces such that I can
>
> 1) re-use the joint-state-controller

There should be no problem with exposing a joint state inteface. As you say below, this is orthogonal to having a stiffness interface or not.

 

>
> 2) use the existing effort-controllers to drive only the effort
> and use a default value for stiffness

When no stiffness controllers are running, it would make sense that your hardware abstracion assigns a sensible default stiffness. This would allow simpler deployments to work out-of-the-box.

Adolfo.

[Georg Bartels]

Hi Adolfo,

after some roaming in the existing interfaces I decided to copy the
design of the JointCommandInterface and expose my hardware like this
interface:

https://github.com/airballking/ros_control/blob/impedance-joint-interface/hardware_interface/include/hardware_interface/impedance_joint_interface.h

In my RobotHw I would now have:

class MyRobot: public RobotHW
{
public:
...
private:
PositionJointInterface jnt_pos_interface_;
PositionImpedanceJointInterface jnt_pos_imp_interface_;
...
};

Like that, I can load the existing controllers in ros_controllers
which use the PositionJointInterface (plus some solution to set
impedance defaults in MyRobot). I can also implement my own
controllers against
PositionImpedanceJointInterface which will set both positions and
impedance values.

I plan to initialize both of these interfaces with the same resource
name. Why do you say "you'll need to override the default resource
conflict policy"?

Final question: Would you be interested in merging the
ImpedanceJointInterface I sketched? If not, I will move it into the
repository in which I will implement my controllers.

Cheers,
Georg.

@Carlos: Thank you for sending me the links to your repositories. It
was interesting to see your choices. :)

[Carlos J. Rosales Gallegos]

That's a good idea as well Georg, maybe you can think of  extending the joint state message (http://docs.ros.org/indigo/api/sensor_msgs/html/msg/JointState.html) with stiffness and damping fields as well.

I'll be following your fork!

Carlos

>>>>> ros-sig-robot-control+unsub...@googlegroups.com. For

>>>>> more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>> -- You received this message because you are subscribed to the
>> Google Groups "ROS/Orocos Robot Control Special Interest Group"
>> group. To unsubscribe from this group and stop receiving emails
>> from it, send an email to

>> ros-sig-robot-control+unsub...@googlegroups.com. For more
>> options, visit https://groups.google.com/d/optout.
>>
>
>
>

[Georg Bartels]

Hi Carlos,

I think impedance is a concept related to controllers, or more
specifically it is a control strategy. In contrast, the joint-state
message only communicates the observed state of a joint.

Hence, I'd rather report stiffness and damping in a controller-state
message and leave joint-state messages untouched. Does this sound
reasonable to you?

Cheers,
Georg.

>>>>>>> ros-sig-robot-co...@googlegroups.com <javascript:>.

>> For
>>>>>>> more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> -- You received this message because you are subscribed to the
>>>> Google Groups "ROS/Orocos Robot Control Special Interest Group"
>>>> group. To unsubscribe from this group and stop receiving emails
>>>> from it, send an email to

>>>> ros-sig-robot-co...@googlegroups.com <javascript:>. For

[Carlos J. Rosales Gallegos]

Hi Georg,

You can achieve impedance via control strategy, as in the kuka arm, and probably your testbed as well.

I was thinking more of Variable Stiffness/Impedance Actuators where that id achieved mechanically. In this case, I think it can be considered as a joint state as well (measured indirectly in most cases though). So, they can be considered already from the beginning for your approach, which I see a better option than what I had in mind (in few months I'll start working on the interfaces for these: http://www.qbrobotics.com).

Carlos

[Adolfo Rodríguez Tsouroukdissian]

On Mon, Mar 16, 2015 at 9:46 AM, Georg Bartels <georg....@cs.uni-bremen.de> wrote:

Hi Adolfo,

after some roaming in the existing interfaces I decided to copy the
design of the JointCommandInterface and expose my hardware like this
interface:

https://github.com/airballking/ros_control/blob/impedance-joint-interface/hardware_interface/include/hardware_interface/impedance_joint_interface.h

In my RobotHw I would now have:

class MyRobot: public RobotHW
{
  public:
    ...
  private:
   PositionJointInterface jnt_pos_interface_;
   PositionImpedanceJointInterface jnt_pos_imp_interface_;
   ...
};

Like that, I can load the existing controllers in ros_controllers
which use the PositionJointInterface (plus some solution to set
impedance defaults in MyRobot). I can also implement my own
controllers against
PositionImpedanceJointInterface which will set both positions and
impedance values.

I plan to initialize both of these interfaces with the same resource
name. Why do you say "you'll need to override the default resource
conflict policy"?

By default there's an exclusive resource ownership policy. Resources are identified by their names. So if the same resource name has a position and an impedance interface, you won't be able to simultaneously command both interfaces. This is the default, however, and you can implement (hardware_interface::RobotHW::checkForConflict(...) ) whatever policy you see fit, such as allowing an impedance interface to co-exist with any other interface.

Note: I'm assuming the impedance interface is separate from that commanding positions. If your impedance interface also inherits from JointHandle, then you only need to claim the resource from one interface.

Final question: Would you be interested in merging the
ImpedanceJointInterface I sketched? If not, I will move it into the
repository in which I will implement my controllers.

An impedance interface would be a welcome addition. I'm not sure if inheriting from JointHandle is the best strategy. One might want to control impedances without controlling positions or efforts. At any rate, I currently don't have impedance-controlled hardware, so the most valuable feedback might come from potential users of your interface, like Carlos.

Adolfo.

--