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 configuration.

The idea of trajectories for multiple end-effectors looks interesting.
What do you think about something like that :

[CartesianTrajectoryGoal]
Header header # A stamp of 0 means "execute now"
string[] effector_names
CartesianTrajectory[] trajectory
PoseStamped tool # The frame which is being controlled CartesianTrajectoryPoint[] points duration time_from_start Pose pose Twist twist
CartesianImpedance[] impedance
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_velocity CartesianTolerance[] goal_tolerance # Tolerance for when reaching the goal is considered successful
JointTrajectory posture # For determining the redundancy
JointImpedance nullspace_impedance # TBD



Pozdrawiam
Konrad Banachowicz


2013/6/5 Adolfo Rodríguez Tsouroukdissian <adolfo.rodriguez@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@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


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@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users




_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users