search

moveit / moveit_resources

URDFs, meshes, and config packages for MoveIt testing
61 stars 114 forks source link

Update acceleration limits for robot configs #194

Open pac48 opened 8 months ago

pac48 commented 8 months ago

It looks like the acceleration limits for the robots in this repository do not match the values from here. I'm not positive these are the correct limits to use, but the values in this repository come from this commit. The justification of the values was

As MoveIt! does not support jerk limits, the acceleration limits provided here are the highest values that guarantee that no jerk limits will be violated. More precisely, applying Euler differentiation in the worst case (from min accel to max accel in 1 ms) the acceleration limits are the ones that satisfy max_jerk = (max_acceleration - min_acceleration) / 0.001

I am also not positive that switching between the minimum and maximum accelerations in 1 ms is the best estimate of jerk. There is a parameter called resample_dt in TOTG that creates waypoints every 100 ms by default. It seems that the jerk estimate would be (max_acceleration - min_acceleration) / 0.1 in the worst case. Of course, JTC interpolation also has the potential to significantly impact this. Regardless, since this commit added a parameter to enable/disable jerk limits, I believe the max_acceleration values can be updated. There are at least two options that are worth considering: 1) update the acceleration values joint_limits.yaml or 2) add another configuration joint_limits_jerk.yaml or something like that with new values. Option 1) is concerning because it's not opt-in.

I think this is something worth discussing. I'll create a PR with this issue.

sea-bass commented 8 months ago

To me, keeping separate configurations is an okay fix, though no suffix vs. _jerk suffix doesn't seem like the clearest option we can provide.

Some options would be:

or something like that.

Also while I think the jerk limits parsing was added for Ruckig, I suspect that TOTG doesn't use them at all so this proxy first-order Euler jerk limit is what would be needed there. Although I guess the right answer would be, if you want jerk limits, use a trajectory timing scheme that supports them?