clarification of PositionJointInterface mechanism

edit

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.