Acceleration joint_limits_interface handling for Effort / Position

[BenArtes]

trafficstars

Why is the acceleration limit ignored in Position / Effort joint_limits_interface?

As these are open-loop I understand that Effort would be impractical or impossible to implement, but Position should be straightforward by keeping track of the previously calculated velocity. The PositionJointSaturationHandle and PositionJointSoftLimitHandle are already stateful / keep track of the prev_cmd so it wouldn't be difficult to implement.

Obviously we'll be implementing acceleration and velocity limiting in our trajectory controllers, but I would still think that the controllers should limit where possible.

[BenArtes]

Actually, on re-reading and seeing the use of k_* velocity and position, shouldn't it be possible to implement acceleration for of the limit interfaces?

[BenArtes]

So I've realized that enforcing acceleration limits would cause overshoot without a trajectory generator. My core issue was with behavior of gazebo_ros_control so I've opened an issue over there to discuss changes and features, but it still feels weird that the joint_limits_interface doesn't actually apply all of the joint_limits.

https://github.com/ros-simulation/gazebo_ros_pkgs/issues/1001

[dheera]

@BenArtes Why would it overshoot? It should not overshoot if it "plans well", and it should be possible to incorporate a simple trajectory generator into the position controller. Ideally there should be a controller that enforces position, velocity, acceleration, and jerk constraints all at the same time.

[BenArtes]

If the motor is moving at full speed and requires two seconds to decelerate but a new position is provided that is less than two seconds away it will overshoot. Which isn't really a problem but it implies that a full trajectory controller will need to be added that can decelerate and change direction (which now makes it require state etc); not an issue by itself, but it starts to add functionality to the joints_limit_interface that isn't supposed to have.

My understanding is that the joint_limits_interface is supposed to be simple range-checking / clamping and that trajectory / PID control should implemented at the ros_controllers level so that the controller can (if need be) effectively make decisions about what to do if it can't achieve the desired position / target.

For my use case I hacked in a new PositionLimitInterface that implements a simple trapezoidal trajectory generator until I have time to revisit this.