Trajectory rejected on first use or after powersafe
simonschmeisser opened this issue · comments
We get a failing trajectory start position check after the robot was idle for some time. In this case we also observe that the actual and desired pulse/joint position do not match. In one case I was seeing a joint difference as big as 2.2e-3 on the wrist joint (this is a small size, GP7 robot where we usually rather expect precision < 1e-4) between the display on the teach pendant and what is sent out via simple message to ROS.
For reading the current position the driver uses mpGetFbPulse() while later for the check of the first trajectory point mpGetPulse() is used. The allowed difference between the trajectory start position and the theoretical robot position is 30 pulses. According to Yaskawa Germany internally 500 pulses are accepted before an error is shown to the user.
motoman/motoman_driver/MotoPlus/MotionServer.c
Line 1225 in bd4bdbd
motoman/motoman_driver/MotoPlus/CtrlGroup.c
Line 242 in bd4bdbd
vs
motoman/motoman_driver/MotoPlus/CtrlGroup.c
Line 305 in bd4bdbd
My theory is that brakes are only released after this check and therefore the offset will never be corrected. Somehow it usually works on the second attempt however. Or maybe the joint position used in ROS is from before unbraking the robot? (We automatically send "enable robot" when it is in remote mode and motion_possible is false)
I tried increasing the limit but what I compiled with the MotoPlusSDK (it was not the one integrated in VS but the old (?) standalone one) from the partner download area did not match in size and failed to start. Also had to manually define the YRC1000 define or it would not compile the IOServer. We will get a MotoPlus SDK license on Wednesday but if anybody could provide a binary with increased tolerance or with checking against mpGetFbPulse we would be very grateful as the automatica fair is pretty close