CartesianMotion "Velocity" Controller

[torydebra]

Hi, I would like to ask if there is a plan to provide a CartesianMotionController which accepts a Twist instead of a pose, or if there are any cons in doing so.

I see that I can use the Motion control utility to "convert" from twist to pose but I think it is better to have a unique controller if I am going to use exclusively the twist, what do you think?

[stefanscherzinger]

Hi @torydebra

Good point. This idea has crossed my mind several times.

I would like to ask if there is a plan to provide a CartesianMotionController which accepts a Twist instead of a pose, or if there are any cons in doing so.

I don't have that on my agenda, so no. But I'm actually in favor of giving it a thought. If that's what users need, then why not.. There are some implications, though, that require a deeper thought.

Could I ask you what features you would like for this controller and what behavior you would expect from it?

[torydebra]

Hi Stefan,

I was just looking for something easy to implement to teleoperate robot with a Cartesian Velocity as input. I saw that motion control utility but I was wondering why not integrating it directly, avoiding passing through the pose.

If I understood correctly from the slides, it may be possible to computing directly the wrench eventually by just scaling the twist ?

[stefanscherzinger]

If I understood correctly from the slides, it may be possible to computing directly the wrench eventually by just scaling the twist ?

Yes, that's true. I also do that here https://github.com/fzi-forschungszentrum-informatik/cartesian_controllers/blob/6c45682a3fb0a46682daa5847fb601a6a1c8edfe/cartesian_controller_utilities/scripts/converter.py#L25

in the utility package. The space mouse publishes `twist messages by default that I re-scale. I was asking for your expectations, because this approach will not let the robot move with the specified twist, but with some scaled motion that is further parameterized by the controller gains. This might not be what users expect from an end-effector twist interface, which is why I don't provide that currently.

Note that the normal approach to handle twists would be using velocity-based IK with some Jacobian-based approach. That's straight-forward for me to integrate, I just need some feedback of whether that's required.

[torydebra]

Ah right I see your point.

So probably it is better to follow the normal approach, simple and straightforward.

I can not find anything in the ros control ecosystem to command a twist, so this can be useful for all people in general to fastly approach the problem.

[gavanderhoorn]

Depends on whether you're looking for ROS 1 or ROS 2 and what sort of resources your hw interface makes available, but ipa320/cob_control hosts quite a few relevant packages I believe.

For Twist control specifically, from the wiki page:

The main purpose of the cob_twist_controller is to convert target twists into joint velocities. Therefore it makes use of several implemented inverse kinematics approaches at the first order differential level. The inverse differential kinematics solver considers kinematic chain extensions, singularity robustness, redundancy resolution and priority-based methods. To avoid hardware destruction there is a limiter interface active as well. Via parameter server users can dynamically configure the solving strategy.

Not saying it wouldn't be interesting to add something here (ie: to fzi-forschungszentrum-informatik/cartesian_controllers) of course.

[torydebra]

Depends on whether you're looking for ROS 1 or ROS 2 and what sort of resources your hw interface makes available, but ipa320/cob_control hosts quite a few relevant packages I believe.

For Twist control specifically, from the wiki page:

The main purpose of the cob_twist_controller is to convert target twists into joint velocities. Therefore it makes use of several implemented inverse kinematics approaches at the first order differential level. The inverse differential kinematics solver considers kinematic chain extensions, singularity robustness, redundancy resolution and priority-based methods. To avoid hardware destruction there is a limiter interface active as well. Via parameter server users can dynamically configure the solving strategy.

Not saying it wouldn't be interesting to add something here (ie: to fzi-forschungszentrum-informatik/cartesian_controllers) of course.

Thanks, this may be what i was looking for, I will check it out