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.
(text/plain)