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
If you have a non-deterministic network connection or ROS driver process, it can happen that we miss the control cycle at some point. While we have an extrapolation strategy for this in place on the URScript, this is currently not used since the default behavior of the reverse interface is to require a new package in each control cycle. We could add a ur_driver_->setKeepaliveCount(X); statement to the initialization process.
This should be added together with some documentation clearly stating the culprits that this has (basically, the robot will continue its motion in the last commanded direction until this timeout is hit once the driver disconnects).
The text was updated successfully, but these errors were encountered:
I would like to know how to set interface parameter "robot_receive_timeout" mentioned in #1002 to reduce the likelihood of ”Connection to reverse interface dropped.“ occurring
If you have a non-deterministic network connection or ROS driver process, it can happen that we miss the control cycle at some point. While we have an extrapolation strategy for this in place on the URScript, this is currently not used since the default behavior of the reverse interface is to require a new package in each control cycle. We could add a
ur_driver_->setKeepaliveCount(X);
statement to the initialization process.This should be added together with some documentation clearly stating the culprits that this has (basically, the robot will continue its motion in the last commanded direction until this timeout is hit once the driver disconnects).
The text was updated successfully, but these errors were encountered: