I recently was working on the ROSin5DaysCpp course and had a decent solution working in simulation for the turtlebot3 task to follow a wall. However, when moving to implement the solution in RealRobots, I found I had such a large latency when I or my program would issue commands and when the robot would respond. Somewhere on the order of 15 - 20 seconds for me to see the robot to respond to a command. Has anyone else had this problem? It made it really hard for my program to work as every time the robot would’ve already been running into the wall for at least 15 seconds before my program even realized there was a wall (I have print statements to track what it is executing). I’m in the U.S. so I realize that this would definitely be a networking challenge but I wonder if there is a way to request to run my ROSDS off of a European datacenter rather than one closer to me because I would rather me seeing the feedback late rather than my program. Is this currently possible?
Hi @jaronlundwall i have experienced the same latency issue. I am in Colombia and the latency is similar to yours, about 10 seconds.
I’m also in the US, and the delay is pretty bad. However, I noticed that the lag is worst in the video stream. If you open rviz and use the laser scanner the delay is significantly shorter maybe 0.5-1 seconds.
I am curious, does you wall follow solution involve you issuing commands in addition to the initial launch file?
Hi,
Yeah , the video stream is only for the user to see what the robot is doing. Is not meant to be uised for the algorithms ( you cant even access it in the ros topics). As @52whitekeys said, through rviz the lattency is much smaller. Although you have to consider that even that smaller lattency is significant. The real robot has to be dealt with as you would a robot in the Moon or Mars. All the algorithms have to take into account that delay and therefore issue safer commands and wait for the updated infor to arrive.
@_RM no, my program doesn’t involve issuing commands in addition to the initial launch. I was just referring to how I would try my program, run into issues, and then try just teleop_keyboard to control it and still struggle to control it manually because of the delay.
@duckfrost / @_RM I’m definitely not using the video stream in my program nor am I using rviz. I subscribe to the /scan topic so I don’t see how using rviz would help beyond manually operation. I could play around with changing any constants I have that mark when to change behavior based on how close a wall is but I’ll have to wait a week for another booking. It still seems odd to me that my program wouldn’t even detect that it hit a wall consistently for around 15 seconds after it hit it.