[ros-users] cartesian trajectories

[Georg Bartels]

Hi guys,

first of all: thumbs up for having this discussion on the list. It's 
cool to have this visible for everyone. :)

On 06/05/2013 04:09 PM, Mrinal Kalakrishnan wrote:
> Let me correct that. We actually don't use a specific
> "CartesianTrajectory" msg any more. Instead, we have a generic
> "Trajectory" msg, which has a list of dimension names and
> TrajectoryPoints - which makes it very similar to a JointTrajectory
> msg. We then agree upon a naming scheme, like "r_hand_cart_x",
> "r_hand_cart_force_x", and "r_hand_cart_gain_x" and so on. This allows
> us to synchronize the execution of cartesian positions, forces and
> gains (impedances), on multiple end-effectors if needed. We can also
> send joint trajectories (or null-space joint posture trajectories)
> through the same interface.

I'd like to contribute my ideas about having one generic array-like 
message for arbitrary types of trajectories. I think this to be a 
dangerous idea because the meaning of "r_hand_cart_gain_x" is not 
communicated.

I definitely see the appeal of having the same message outline for 
different kinds of trajectories, but I am afraid it is inviting trouble. 
What I mean is that it is really important to state the reference 
points, reference frames, points of reference and frames of reference 
for Op-Space positions, velocities and wrenches. With joint state 
trajectories one can get away without stating such semantics because a) 
it's a configuration and b) people usually agree on a common URDF for 
one robot which is not mentioned in the joint state message. But 
Cartesian trajectories are a different animal: Reference frames change a 
lot between applications and users of the same robot. Hence, I'd vote 
for keeping such semantics with the trajectory as partly outlined with 
the tool PoseStamped in 
http://www.ros.org/wiki/robot_mechanism_controllers/Reviews/Cartesian%20Trajectory%20Proposal%20API%20Review

Cheers,
Georg.