Revision history [back]

Summarizing the helpful answers in the comments above:

In order to fix the lost signal problem a command timeout can be implemented in the motor controller code. When commands are received start a timer, stop the robot if no new commands have been received in a certain period of time. If using the ROS Joy node, the autorepeat_rate parameter should be set to avoid timeouts when moving at a constant speed.

The re-connection problem is trickier so solve. This issue is caused by ROS using TCP to publish and subscribe to topics. TCP will sent old packets once connection is re-established. A better method is to use ROS UDP. If anyone knows of a good example of how to use ROS UDP, please provide a link in the comments.

Thanks @gvdhoorn, @hendrix, and @Maarten for the help

Summarizing the helpful answers in the comments above:

In order to fix the lost signal problem a command timeout can be implemented in the motor controller code. When commands are received start a timer, stop the robot if no new commands have been received in a certain period of time. If using the ROS Joy node, the autorepeat_rate parameter should be set to avoid timeouts when moving at a constant speed.

The re-connection problem is trickier so solve. This issue is caused by ROS using TCP to publish and subscribe to topics. TCP will sent old packets once connection is re-established. A better method is to use ROS UDP. If anyone knows of a good example of how to use ROS UDP, please provide a link in the comments.

Thanks @gvdhoorn, @hendrix, @ahendrix, and @Maarten for the help

Summarizing the helpful answers in the comments above:

In order to fix the lost signal problem a command timeout can be implemented in the motor controller code. When commands are received start a timer, stop the robot if no new commands have been received in a certain period of time. If using the ROS Joy node, the autorepeat_rate parameter should be set to avoid timeouts when moving at a constant speed.

The re-connection problem is trickier so solve. This issue is caused by ROS using because ROS1 uses TCP to publish and subscribe to topics. topics because it was not designed with unreliable connections in mind. TCP will sent old packets once connection is re-established. A

ROS2 provides better methods for dealing with unreliable networks, but if you aren't ready to make the switch one solution would be to use topic_tools/transform to add a timestamp to a message before it is sent over the network, and then compare the timestamp on the receiving side to the system time. The robot and remote PC's clocks would need to be synced in order for this method is to use ROS UDP. If anyone knows of a good example of how to use ROS UDP, please provide a link in the comments.to be used.

Thanks @gvdhoorn, @ahendrix, and @Maarten for the help

Summarizing the helpful answers in the comments above:

Lost Signal Fix
In order to fix the lost signal problem a command timeout can be implemented in the motor controller code. When commands are received start a timer, stop the robot if no new commands have been received in a certain period of time. If using the ROS Joy node, the autorepeat_rate parameter should be set to avoid timeouts when moving at a constant speed.

Reconnection Fix
The re-connection problem is trickier so solve. This issue is caused because ROS1 uses TCP to publish and subscribe to topics because it was not designed with unreliable connections in mind. TCP will sent old packets once connection is re-established.

ROS2 provides better methods for dealing with unreliable networks, but if you aren't ready to make the switch one solution would be to use topic_tools/transform to add a timestamp to a message before it is sent over the network, and then compare the timestamp on the receiving side to the system time. The robot and remote PC's clocks would need to be synced in order for this method to be used.

Thanks @gvdhoorn, @ahendrix, and @Maarten for the help