Error Tolerance vs Limits

[BrettHemes]

The current proposal contains error constraints as tolerances in the CartesianTolerance message but these are limited to symmetric bounds about the point in question. How might one express non-symmetric constraints such as a maximum velocities, accelerations, or perhaps jerks? Perhaps it is up to the consumer of the message to determine semantics in such cases (e.g., for the case of maximum jerk, just use the target (see #3) as the limit)? Just curious...

[gavanderhoorn]

Could you perhaps give an example?

The idea with these type of *Trajectory messages is that they encode desired state. Deviation from that state (ie: tracking error) is to be avoided.

Are you thinking of the ability to express allowable tolerances around that desired state?

How might one express non-symmetric constraints such as a maximum velocities, accelerations, or perhaps jerks?

Would those be different from the limits as modelled in the robot model (ie: .xacro/.urdf) and/or any overrides on the parameter server?

[BrettHemes]

My mind had jumped to thinking in terms of a ComputeCartesianTrajectory or some form of a time parameterization request which is not discussed here (sorry, been thinking in this realm a lot of late). In such, the trajectory would lack timing information and thus actual dynamic values would not be known... hence the need for limits (i.e., "try as best you can").

E.g., "goto all of these points while satisfying these constraints." Ideally the constraints should be set for each of the waypoints to enable controlled velocity moves and the like.

And yes, I believe these would be different than the robot model constraints as they describe the desired path dynamics (vs the robot's dynamic capability).

We can close this if it is out of scope.

[gavanderhoorn]

I believe -- but I'm only an interested user here, so perhaps the FZI guys will correct me -- the intention is for these messages to become the Cartesian counterpart to JointTrajectory and JointTrajectoryPoint.

Those are currently not used to encode the kind of semantics you describe.

E.g., "goto all of these points while satisfying these constraints." Ideally the constraints should be set for each of the waypoints to enable controlled velocity moves and the like.

This sounds almost like a service request: "please take this Cartesian path and these associated constraints and then generate a Cartesian trajectory for me which adheres to all of it".

Composition of path + constraints could be used in a service request definition in that case -- similar to what the compute_cartesian_path service does in MoveIt. Its service definition (moveit_msgs/GetCartesianPath) seems to contain a Constraints type which goes into this direction.

How much it's actually taken into account I don't know btw, and it also seems to be "only" symmetric constraints.

And yes, I believe these would be different than the robot model constraints as they describe the desired path dynamics (vs the robot's dynamic capability).

Yes, I agree. It wasn't clear to me from your OP.

We can close this if it is out of scope.

Well I don't know. It depends on what sort of information these messages are intended to carry. That was also why I opened #6.

[fmauch]

thanks @gavanderhoorn for summing things up so well.

As already stated in the current document and further clarified in #8 the intention is indeed to specify a Cartesian counterpart of JointTrajectory, JointTrajectoryPoint and FollowJointTrajectoryAction

[gavanderhoorn]

@fmauch wrote:

As already stated in the current document and further clarified in #8 the intention is indeed to specify a Cartesian counterpart of JointTrajectory, JointTrajectoryPoint and FollowJointTrajectoryAction

But that should not prevent us from adding fields which would increase the utility of the new messages, right?

As in #3: the fact that JointTrajectoryPoint doesn't have it doesn't mean that's the best design and we should mimic JointTrajectory 100%. It just happened to work back then for the use-cases considered.

[fmauch]

@fmauch wrote:

As already stated in the current document and further clarified in #8 the intention is indeed to specify a Cartesian counterpart of JointTrajectory, JointTrajectoryPoint and FollowJointTrajectoryAction

But that should not prevent us from adding fields which would increase the utility of the new messages, right?

As in #3: the fact that JointTrajectoryPoint doesn't have it doesn't mean that's the best design and we should mimic JointTrajectory 100%. It just happened to work back then for the use-cases considered.

Yes, but you also made the point of compositing a path out of a series of waypoints and constraints such as MoveIt's compute_cartesian_path service. I added a paragraph to the introduction about that specific point in f03ef5e.