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:
creating a custom control interface with the pid package
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.
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?
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.
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.