ROS Unreliable Cell Signal
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.
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
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.
JoyStampedis not needed for that.I also suggest using the
autorepeat_rateparameter to thejoynode 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.Stamping allows you to identify delayed messages, but doesn't stop the robot if you lose the connection. For that use @ahendrix's
autorepeat_rateand 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.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?
There is no need for timestamped messages. As
Twists encode velocity (and not position), everything is relative. Record the time you received aTwistand then start your watchdog timer.because it makes use of velocity control interfaces ..
.. 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).cmd_velis a topic, so that should begeometry_msgs/Twist?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.
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.