Ask Your Question
0

ROS Unreliable Cell Signal

asked 2018-03-12 17:24:27 -0500

updated 2018-03-14 11:16:45 -0500

Hi,

I am using ROS to control robots that are many miles away. Each robot has a cell modem to connect to the internet. I use my laptop and tinc VPN to access the robots.

I need the ability to drive the robots around manually from inside the office. I find it easiest to plug an Xbox controller into my laptop and run the ROS Joy node. I also want to be able to drive the robot with my phone or tablet if I run out to the field to check on something.

image description

Lost signal problem
Currently if I lose cell signal the robot keeps doing the last command it was told.

Re-connection problem
When the robot reconnects it starts doing old commands

edit retag flag offensive close merge delete

Comments

2

Currently if I lose cell signal the robot keeps doing the last command it was told.

this sounds like your base driver does not have a command time-out built-in. Whatever you do with the 'e-stop', I would start with adding that command time-out. JoyStamped is not needed for that.

gvdhoorn gravatar imagegvdhoorn ( 2018-03-13 01:43:28 -0500 )edit
3

I also suggest using the autorepeat_rate parameter to the joy node to have it publish messages at a regular rate so that you do not get a command timeout when you're not moving the controls.

ahendrix gravatar imageahendrix ( 2018-03-13 02:08:39 -0500 )edit

Stamping allows you to identify delayed messages, but doesn't stop the robot if you lose the connection. For that use @ahendrix's autorepeat_rate and implement @gvdhoorn's timeout in the driver. If you can't change the driver, create a node sending stop when it doesn't receive new commands.

Maarten gravatar imageMaarten ( 2018-03-13 04:20:55 -0500 )edit

I've implemented these using the header from the Joy message. Now I'm realizing if I use my Andriod Teleop app which sends /cmd_vel to the robot this code won't work. I could do the same method with cmd_vel if it had a timestamp but it does not. Why does move_base not use twist stamped. Any advice?

shoemakerlevy9 gravatar imageshoemakerlevy9 ( 2018-03-13 22:14:25 -0500 )edit

There is no need for timestamped messages. As Twists encode velocity (and not position), everything is relative. Record the time you received a Twist and then start your watchdog timer.

Why does move_base not use twist stamped?

because it makes use of velocity control interfaces ..

gvdhoorn gravatar imagegvdhoorn ( 2018-03-14 03:10:45 -0500 )edit

.. exposed by base drivers to implement a position control loop. Everything is relative then, and time is not that important (or at least, not when it comes to interpreting the Twist).

which sends /cmd_vel to the robot

cmd_vel is a topic, so that should be geometry_msgs/Twist?

gvdhoorn gravatar imagegvdhoorn ( 2018-03-14 03:11:44 -0500 )edit

Okay that makes sense for stopping the robot when connection is lost. How about when connection is re-established, I often see the robot start moving because its receiving old commands. I guess this wasn't stated in my original question but I would like to prevent both, scenarios.

shoemakerlevy9 gravatar imageshoemakerlevy9 ( 2018-03-14 09:55:28 -0500 )edit
1

To prevent that, you'll need to tag the messages before sending them. Or you can test that in such cases, the new command arrives quick enough to prevent problems). Of course, time tagging the messages before sending them is by far the most robust approach.

Maarten gravatar imageMaarten ( 2018-03-14 09:58:32 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-03-14 11:23:31 -0500

updated 2018-03-14 13:18:28 -0500

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

edit flag offensive delete link more

Comments

1

ROS2 provides better methods for dealing with unreliable networks, but if you aren't ready to make the switch

the ros2/ros1_bridge makes it so that you don't have to 'make the switch'.

gvdhoorn gravatar imagegvdhoorn ( 2018-03-14 11:48:11 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-03-12 17:24:27 -0500

Seen: 148 times

Last updated: Mar 14 '18