[ros-users] cartesian trajectories

[Edwards, Shaun M.]

For what it's worth there have been many discussion on this list that talked about making generic messages.  A simple example, that I argued for, was to have a simple analog value message that could represent any kind of simple sensor value.  The main argument, which I accepted, is that each message should also have semantic meaning.

Shaun Edwards
Senior Research Engineer
Manufacturing System Department


http://robotics.swri.org
http://rosindustrial.swri.org/
http://ros.swri.org
Join the ROS-Industrial Developers List
Southwest Research Institute
210-522-3277


-----Original Message-----
From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Georg Bartels
Sent: Wednesday, June 05, 2013 10:32 AM
To: ros-users at code.ros.org
Subject: Re: [ros-users] cartesian trajectories

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.
_______________________________________________
ros-users mailing list
ros-users at code.ros.org
https://code.ros.org/mailman/listinfo/ros-users