[ros-users] cartesian trajectories
konradb3 at gmail.com
Wed Jun 5 17:18:39 UTC 2013
I thank that messages should be strongly-typed and dislike universal
key-value message concept.
The message structure should be self-explanatory without complex context of
The idea of trajectories for multiple end-effectors looks interesting.
What do you think about something like that :
Header header # A stamp of 0 means "execute now"
PoseStamped tool # The frame which is being controlled
CartesianTrajectoryPoint points duration time_from_start Pose
pose Twist twist
TBD stiffness % cartesian stiffness
TBD damping % damping ratio
CartesianTolerance path_tolerance # Tolerance for aborting the path
float64 position float64 orientation # Permitted angular error
float64 velocity float64 angular_velocityCartesianTolerance
goal_tolerance # Tolerance for when reaching the goal is considered
JointTrajectory posture # For determining the redundancy
JointImpedance nullspace_impedance # TBD
2013/6/5 Adolfo Rodríguez Tsouroukdissian <adolfo.rodriguez at pal-robotics.com
> Please keep the robot control sig in the loop.
> On Wed, Jun 5, 2013 at 5:32 PM, Georg Bartels <
> georg.bartels at cs.uni-bremen.de> wrote:
>> Hi guys,
>> first of all: thumbs up for having this discussion on the list. It's cool
>> to have this visible for everyone. :)
> Indeed :)
>> 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
> I'm not implying that semantics should be sacrificed. The semantics
> missing from the trajectory message should be present in the configuration
> of the actual interpolator, so it knows what the data represents. The
> current JointTrajectoryAction controller for example rejects trajectories
> whose joint set does not match exactly its set of controlled joints. One
> could think of a different, more complex set of checks that would validate
> and add semantic meaning to the message data. This might be easier said
> than done though. Possible complications:
> - Non-static configuration, such as your example of changing reference
> frames between messages.
> - Matching differently-sized position, velocity and acceleration
> variables. Eg, a pose represented with 7 variables (or 12, or 16), and
> twists/accelerations represented by 6.
> ...I'm probably missing others
>> ros-users mailing list
>> ros-users at code.ros.org
> ros-users mailing list
> ros-users at code.ros.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ros-users