No acceleration limits given in joint_limits.yaml

[AndyZe]

This leads MoveIt to select the default joint acceleration limit for all joints, 1.0 rad/s^2 --> motion is slow.

This is probably bad behavior on the MoveIt side and the default MoveIt behavior is likely to change soon. To prevent that change from affecting UR users, it would be nice to provide acceleration limits here.

[fmauch]

This seems reasonable, thanks for the suggestion and the heads-up!

[gavanderhoorn]

@AndyZe: if MoveIt's behaviour is going to change wrt how it uses default acceleration limits (and/or their absence), that would seem to merit a more wider announcement as it's a potentially breaking (behavioural) change.

I'm certain there are users who currently rely on "MoveIt is slow with the settings I use right now".

I'm also certain there will be users who will not be able to configure their MoveIt setup with meaningful / correct acceleration limits, as there are virtually no robot mfgs who are willing to provide that information.

[RobertWilbrandt]

To add to the "meaningful / correct" limit problem: We currently also don't have publicly available acceleration limits, but only torque limits. We could try to figure out a set of limits that works for most setups in most configurations, but i don't know if that is a good way forward as this will probably be quite limiting in different setups.

[urrsk]

It always boils down to joint torques. Therefore, the max acceleration depends on the robot configuration (joint positions and gravity direction) and payload mounted on the tool flange of the robot. But for a default value, I will suggest we could start with konservative 5 rad/s². We should just remember to document how people can change it and that they are allowed to do so.

Maybe also a QA that if they get protective stop when the robot starts moving or stopping then it might be that the acceleration is set too high or that the payload and Center of Mass of the payload is wrong.

Then there is the safety concerns as @gavanderhoorn rightly highlight. So in the QA we should also highlight how it is possible to ensure a low the velocity, momentum, etc... of the arm, if needed. Here, I mainly thinks of the safety system of a UR robot in combination with the scaled joint trajectory controller which is the default trajectory controller behaviour in the ROS2 driver as well

[olufskovnielsen]

@gavanderhoorn Do you have any information about how MoveIt is expecting to change behavior wrt. accelerations?.

We see more and more users wanting to do bin-picking applications with hard cycle-time constraints based on UR robots and MoveIt, so we want to give them the best options possible.

[gavanderhoorn]

@olufskovnielsen: you would really have to take that up with the MoveIt (probably PickNik) team, of which @AndyZe is a member.

The current behaviour is to fall back to 1 rad/s^2 in the absence of any defined acceleration limits.

I guess that's going to change. I've not seen any discussion about this on the public MoveIt issue trackers, so I cannot give you any more information.

[olufskovnielsen]

Thanks, we will be coordinating with the PickNik team

[gavanderhoorn]

I would encourage a discussion about this on the public MoveIt issue tracker(s), as I expect many more users will be affected by this.

[AndyZe]

I made an issue here. What we (MoveIt maintainers) discussed briefly was to print a warning then exit if no acceleration limit is defined.

[AndyZe]

@olufskovnielsen and @urrsk

Re changing payloads:

There is an option in MoveIt to update acceleration limits dynamically. I mean, the acceleration limits can be updated for every trajectory. It's an advanced option that not many people use, though. Probably more will use it in the future, I expect.

https://github.com/ros-planning/moveit2/blob/2c70d01cb679029ccbee28e7f58f8d4745c7097b/moveit_core/trajectory_processing/include/moveit/trajectory_processing/time_optimal_trajectory_generation.h#L173

The average MoveIt user is not aware of this option.

[gavanderhoorn]

The average MoveIt user is not aware of this option.

probably because it would require retiming? The standard request adapter would not use this.

[AndyZe]

Yeah, exactly. They have to be using moveit_cpp to have access to this. MoveGroupInterface and the typical RViz setup don't give access to it.

[olufskovnielsen]

That is an interesting feature - it makes a lot of sense to separate the user's desired accelerations and speeds from the urdf, describing the robot and kinematic chain. then users can more easily get the speeds they want for different trajectories.

[gavanderhoorn]

@olufskovnielsen: that was already always possible.

That's the main reason the joint limits are configured using a .yaml file.

[fmauch]

As mentioned above, the robot itself does not have any specific acceleration limits, but torque limits. The acceleration that can be achieved depends very much on the actual joint configuration the robot is currently in. Since a fixed (conservative) acceleration limit is required by MoveIt! it should in our opinion be specified inside the MoveIt! configuration directly. Hence, we implemented https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/pull/645. Therefore, I'm going to close this issue here.