[ros-users] cartesian trajectories
Edwards, Shaun M.
sedwards at swri.org
Wed Jun 5 15:48:11 UTC 2013
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.
Senior Research Engineer
Manufacturing System Department
Join the ROS-Industrial Developers List
Southwest Research Institute
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
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
ros-users mailing list
ros-users at code.ros.org
More information about the ros-users