irb2400: suspicious acceleration limits in MoveIt package

[gavanderhoorn]

The current MoveIt configuration package (irb2400_moveit_config) has all acceleration limits set to 1.0 in joint_limits.yaml. These are probably not the real limits, and should be updated if possible.

[Levi-Armstrong]

@shaun-edwards: Do you know where I can find the joint acceleration limits for ABB robots; is it possible to get them from RobotStudio?

[shaun-edwards]

The joint acceleration limits are not publicly available on most robots. A good guess is 10 x max velocity (i.e. a joint can reach max speed in 0.1s). I believe the accelerations can be removed. The moveit package will need to be regenerated if the limits are removed/changed.

[gavanderhoorn]

@shaun-edwards wrote:

I believe the accelerations can be removed

Do we know what the defaults are that MoveIt would use in that case?

[BrettHemes]

Do we know what the defaults are that MoveIt would use in that case?

I currently have the same question... From what I am seeing currently, it seems MoveIt's default accel limits are conservative as the robot's motion is very slow to accelerate (when compared to the native hardware controller's behavior)

[gavanderhoorn]

Yep. I recognise that.

Problem is with most robots that acceleration profiles are also load dependent (as are the velocity profiles), so setting hard limits in the MoveIt configuration doesn't really always work.

[shaun-edwards]

The ABB robot driver will not allow you to exceed acceleration/velocity limits. You could set them arbitrarily high and the robot will perform the trajectory the best it can. That being said, dense trajectories will always be executed slowly, as the robot motion controller struggles with these. See here for more info.

Do you have a particular need that you are trying to address? There might be a better option if I understood your use case.

[BrettHemes]

From a quick investigation, the default behavior seems to be as follows:

For the parameter server For each joint: /robot_description_planning/joint_limits/[joint_name]/

• has_acceleration_limits = false
• max_acceleration = 0

Inside of IterativeParabolicTimeParameterization::applyAccelerationConstraints()

00368     double a_max = 1.0;
00369     const robot_model::VariableBounds &b = rmodel.getVariableBounds(vars[j]);
00370     if (b.acceleration_bounded_)
00371       a_max = std::min(fabs(b.max_acceleration_*acceleration_scaling_factor), fabs(b.min_acceleration_*acceleration_scaling_factor));

... which if I understand correctly, will result in MoveIt defaulting to 1 [rad/s/s] unless iptp is not called in all cases; not sure.

@gavanderhoorn do you have a best practice for adjusting MoveIt acceleration limits? Maybe set them to their highest limits in the moveit config and then use MoveIt's acceleration_scaling_factor to control based on (current) payload @shaun-edwards I got here via Googling "moveit default acceleration limits". The application in question is using the kuka_rsi_hw_interface which implicitly enforces limits by faulting if you ask too much of it. My current problem, however, is that my accelerations are way too slow... which I think I can fix by setting limits in the moveit config...

btw, sorry if this conversation should be somewhere else

[gavanderhoorn]

btw, sorry if this conversation should be somewhere else

I'd say it's a good place, as https://github.com/ros-industrial/abb/issues/44#issuecomment-75224752 asks for what "the defaults are". Seems we got an answer :).

@gavanderhoorn do you have a best practice for adjusting MoveIt acceleration limits? Maybe set them to their highest limits in the moveit config and then use MoveIt's acceleration_scaling_factor to control based on (current) payload

I'd always put in the maxima. The controller will either fault (RSI, MXT, EGM), or just perform at its maximum (current Rapid based driver). Scaling based on payload is difficult I think, unless you know how the robot controller does it itself (or figure it out by iteratively increasing and seeing where it starts to fail, but even then).