# clarification of PositionJointInterface mechanism

Hi,

I've tried using the kuka_experimental rsi hw interface and it works great. However, I wish to control the robot in terms of cartesian position instead of joint position. I thought of two ways to dot it:

1. creating a custom control interface with the pid package

2. using ros_control (should be a position controller)

(3.) undesired option is using IK, anyway I still have the problem described below.

Regarding the 2nd option, I really dug into the PositionJointInterface code, and I couldn't understand how is the control being done. The /position_trajectory_controller/command and /position_trajectory_controller/follow_joint_trajectory/goal topics display the final desired position of the joints, how ever, the rsi commands are being passed through some control loop (I guess pid) which I couldn't find and couldn't control. How does this control work? and is it possible to tune it? If it's not possible with the PositionJointInterface, I guess I should use the pid package, shouldn't I?

EDIT: Is this what's happening?

The controller is templated to work with multiple trajectory representations. By default, a spline interpolator is provided, but it's possible to support other representations. The spline interpolator uses the following interpolation strategies depending on the waypoint specification:

• Linear: Only position is specified. Guarantees continuity at the position level. Discouraged because it yields trajectories with discontinuous velocities at the waypoints.

• Cubic: Position and velocity are specified. Guarantees continuity at the velocity level.

• Quintic: Position, velocity and acceleration are specified: Guarantees continuity at the acceleration level.

I used rqt_joint_trajectory_controller and it sends only a jump in position with no velocities and acceleration (so I guess they're counted as 0), so the trajectory controller creates a quintic path?

So basically, can I write a new controller for a cartesian trajectory like specified here, and transfer a path to the FollowJointTrajectory Action and it should perform the trajectory I send it i guess.

Well I think I answered my self, can someone just confirm that it should work?

Also, I'm not sure if using a pid won't work better.. or maybe I should use them both.. using a pid to control the trajectory (based on sensor data) which will be sent through the FollowJointTrajectory Action.. I should think about it.

edit retag close merge delete

What exactly are you trying to achieve? Cartesian velocity control or Cartesian absolute control? Velocity control can be achieve using the jog_arm package. Why do you say IK is not preferred, surely it's essential to avoid singularities?

( 2018-08-27 03:40:13 -0600 )edit

I'm trying to achieve Cartesian position control (KUKA knows how to handle it). I don't want IK because I have other calculations, and I need to supply a position every 4ms - I want to keep the calculation as simple as possible. The KUKA controller stops if a singularity is reached, that's ok 4 me.

( 2018-08-27 03:51:10 -0600 )edit

Anyway, the IK won't solve the issue I'm dealing with, which is how to alter the trajectory created by the controller - be cartesian or in joint space. I think that if I want to use ros_control I should create the trajectory by my self with the position vs time (velocity) so it moves as I wish.

( 2018-08-27 03:55:22 -0600 )edit