[ros-users] cartesian trajectories

[Adolfo Rodríguez Tsouroukdissian]

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
> http://www.ros.org/wiki/robot_**mechanism_controllers/Reviews/**
> Cartesian%20Trajectory%**20Proposal%20API%20Review<http://www.ros.org/wiki/robot_mechanism_controllers/Reviews/Cartesian%20Trajectory%20Proposal%20API%20Review>
>
>
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

Adolfo.


> Cheers,
> Georg.
>
> ______________________________**_________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/**listinfo/ros-users<https://code.ros.org/mailman/listinfo/ros-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130605/5609f2d2/attachment-0004.html>