You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I observed an issue with the driver/communication between the ROS side and the RAPID side when the connection is lost. Most notably, if the ros2_control is restarted while the RAPID program is already running will make it so that the robot no longer moves when the commands are sent.
To reproduce (with RobotStudio):
Start the RAPID program that has EGM communication/control
Start the ros2_control nodes
Trigger a motion and wait that it concludes
Restart the ros2_control nodes
Trigger the motion again --> the robot does not move
reconnect.mp4
To get back into a controllable state, one needs to restart the RAPID program (stop, pp to main, start).
It is important to mention that I am using slightly modified lauchfiles. But the underlying code is the same. At this point, I did not have the opportunity to dig deeper why this happens. I also didn't try the exact same steps on the real robot but I do recall having some issues with restarts.
I observed an issue with the driver/communication between the ROS side and the RAPID side when the connection is lost. Most notably, if the ros2_control is restarted while the RAPID program is already running will make it so that the robot no longer moves when the commands are sent.
To reproduce (with RobotStudio):
reconnect.mp4
To get back into a controllable state, one needs to restart the RAPID program (stop, pp to main, start).
It is important to mention that I am using slightly modified lauchfiles. But the underlying code is the same. At this point, I did not have the opportunity to dig deeper why this happens. I also didn't try the exact same steps on the real robot but I do recall having some issues with restarts.
Did anyone note similar behavior?