believe that Ros_Controller_IsInMotion() is not strict enough. Specifically START_MAX_PULSE_DEVIATION should be decreased. (Or make a new constant for "END deviation".) (Maybe make this configurable in yaml?)
A brief test indicated that the fb pos trails the cmd pos by about .0009 radians. If my calculations are right, for some axes (such as GP12 T axis) that's only 24 pulse counts. So, once the increment-queue is empty, Ros_ControllerIsInMotion would immediately return false, even though the robot is still moving. [This could cause the robot to think it's finished while outside of the final tolerance position.]_
I'm also suspicious that the difference between fb and cmd could shrink as the robot is decelerating. This might make it easier for other axes to also exceed the threshold.
Originally from here: https://github.com/Yaskawa-Global/motoros2/issues/233#issuecomment-2059659087