<div dir="ltr"><div><div><div>I thank that messages should be strongly-typed and dislike universal key-value message concept.<br></div>The message structure should be self-explanatory without complex context of configuration.<br>

<br></div>The idea of trajectories for multiple end-effectors looks interesting.<br></div>What do you think about something like that :<br><br><pre>[CartesianTrajectoryGoal]<br>Header header  # A stamp of 0 means "execute now"<br>

string[] effector_names<br><span class="" id="line-2-1"></span>CartesianTrajectory[] trajectory<br>  PoseStamped tool  # The frame which is being controlled
<span class="" id="line-6-1"></span>  CartesianTrajectoryPoint[] points
<span class="" id="line-7-1"></span>    duration time_from_start
<span class="" id="line-8-1"></span>    Pose pose
<span class="" id="line-9-1"></span>    Twist twist<br>CartesianImpedance[] impedance<br>    TBD stiffness % cartesian stiffness <br>    TBD damping % damping ratio<br>CartesianTolerance[] path_tolerance  # Tolerance for aborting the path
<span class="" id="line-13-1"></span>  float64 position
<span class="" id="line-14-1"></span>  float64 orientation  # Permitted angular error
<span class="" id="line-15-1"></span>  float64 velocity
<span class="" id="line-16-1"></span>  float64 angular_velocity
<span class="" id="line-17-1"></span>CartesianTolerance[] goal_tolerance  # Tolerance for when reaching the goal is considered successful<br>JointTrajectory posture  # For determining the redundancy<br>JointImpedance nullspace_impedance # TBD<br>

</pre><br><br></div><div class="gmail_extra"><br clear="all"><div>Pozdrawiam<br>Konrad Banachowicz</div>
<br><br><div class="gmail_quote">2013/6/5 Adolfo Rodríguez Tsouroukdissian <span dir="ltr"><<a href="mailto:adolfo.rodriguez@pal-robotics.com" target="_blank">adolfo.rodriguez@pal-robotics.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>Please keep the robot control sig in the loop.<br></div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Wed, Jun 5, 2013 at 5:32 PM, Georg Bartels <span dir="ltr"><<a href="mailto:georg.bartels@cs.uni-bremen.de" target="_blank">georg.bartels@cs.uni-bremen.de</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
first of all: thumbs up for having this discussion on the list. It's cool to have this visible for everyone. :)</blockquote><div><br></div></div><div>Indeed :)<br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
<br>
On 06/05/2013 04:09 PM, Mrinal Kalakrishnan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me correct that. We actually don't use a specific<br>
"CartesianTrajectory" msg any more. Instead, we have a generic<br>
"Trajectory" msg, which has a list of dimension names and<br>
TrajectoryPoints - which makes it very similar to a JointTrajectory<br>
msg. We then agree upon a naming scheme, like "r_hand_cart_x",<br>
"r_hand_cart_force_x", and "r_hand_cart_gain_x" and so on. This allows<br>
us to synchronize the execution of cartesian positions, forces and<br>
gains (impedances), on multiple end-effectors if needed. We can also<br>
send joint trajectories (or null-space joint posture trajectories)<br>
through the same interface.<br>
</blockquote>
<br></div>
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.<br>



<br>
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 <a href="http://www.ros.org/wiki/robot_mechanism_controllers/Reviews/Cartesian%20Trajectory%20Proposal%20API%20Review" target="_blank">http://www.ros.org/wiki/robot_<u></u>mechanism_controllers/Reviews/<u></u>Cartesian%20Trajectory%<u></u>20Proposal%20API%20Review</a><br>



<br></blockquote><div><br></div></div><div>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:<br>


</div><div>- Non-static configuration, such as your example of changing reference frames between messages.<br></div><div>- 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.<br>


</div><div></div><div>...I'm probably missing others<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Adolfo.<br></div></font></span><div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Georg.<div><div><br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</div></div></blockquote></div></div><br></div></div><br clear="all"><br></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>