How to navigate into a high latency system?
Hello everyone.
I am now working with a remote robot system, which provides topics with high delay like 0.037 (tested under rostopic delay) for the robots: /joint_states, /scan, /odom etc. This resulted in a Max Dely about 0.4 for the wheel_links showed in the tf monitor and bad performance for navigation such as passing through a goal that should lead to a stop or deviate to a local arc path that should be followed showed in rivz.
For the navigation, I used the default navigation package and chose DWA as local planner. I have try to slow down the max linear velocity limits to prevent goal crossing and increase the angular vel. as well as the acc. to prevent deviate, but they give little effect.
Can someone give any ideas to figure this out? Do I need a extra synchronization?
How about synchronization using message filters?
I would suggest to move the controller as close as possible to the sensors + actuators.
Your controller in this case is
move_base.If you have the option, run the navigation stack close(r) to the robot. That should resolve the latency issues (by avoiding communication over high-latency channels). Sending goals to
move_baseis much less affected by latency.If you must keep
move_baseoff the robot itself / have to deal with high-latency communication, you would probably have to adapt at least the local planner plugins to model the latency, so they can adapt velocity commands they send out.Thanks for the reply guys. The ROS packages are running through a server thus I think the best way is to adapt the latency or improve the communication performance. For latency adaptation, how to model the latency? Seems that there is no features about latency within the navigation package.
No, there is no support for this. You'll have to add it yourself, or find someone who has already done this.
An alternative might be to use Move Base Flex, where you can run the local planner on a different machine. That would allow you to run the global planner and the rest of the navigation stack on the server you mention, but keep the controller (ie: local planner) close to the sensors and actuators.