ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Is that a good choice for the architecture?

asked 2018-11-19 16:01:51 -0500

stevemartin gravatar image


I want to ask whether this idea will be good: 1. All of my navigation and other high level algorithms will be written in ROS 2 and will be stored in cloud (AWS,Heroku). 2. I have a sensor (more specifically camera), which will be mounted on a robot and will send the image data to my cloud via ROS2 bridge. 3. After receiving data, further computations will be done in the cloud.

edit retag flag offensive close merge delete


This really depends on if you have the bandwidth to transfer enough sensor data to the could, if the latency is not going to be a problem and if you really need the processing power of the amazon cloud. Also are there any safety concerns around an unexpected loss of connection?

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-11-19 16:49:27 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-11-19 18:39:17 -0500

ahendrix gravatar image

This is not a good idea.

Navigation, path-planning and path-following controllers generally requires loop rates between 10 and 100Hz, and a corresponding processing (and network) latency of less than 10 to 100mS.

The average WiFi and 3G/4G/LTE cellular networks can barely meet these latency guarantees, and even when they do, there isn't a lot of latency budget left over to do computation. If the AWS or Heroku servers are more than a few hundred kilometers away, the round-trip time to the servers and back can start to add up, too!

You might be able to get acceptable performance if you work directly with a wireless carrier to get dedicated bandwidth and latency guarantees, or if you control your local wifi network and communicate with servers that are in the same building, but those options are out of reach for most users.

It is possible to offload some of your very heavy processing to cloud services, but keep in mind that the latency will be high. This could be good for things like recognizing objects, updating a very large map shared between many robots, or a variety of other things that aren't terribly sensitive to latency.

edit flag offensive delete link more


What will be your suggestion? Basically, we have a low level stuff happening in the cloud (actually moving the wheels and etc) and latency there will not be a problem. So should I get the hardware to implement navigation locally? What will be a good choice here?

stevemartin gravatar image stevemartin  ( 2018-11-20 02:23:20 -0500 )edit


Basically, we have a low level stuff happening in the cloud (actually moving the wheels and etc) and latency there will not be a problem

can you clarify this sentence? Are you saying you already have this working?

gvdhoorn gravatar image gvdhoorn  ( 2018-11-20 02:33:11 -0500 )edit

@gvdhoorn What I mean is that the actual wheel encoders are already implemented in the cloud. So I was thinking to implement navigation internally in a robot and use some socket communication to obtain the wheel encoder values (for odometry), do navigation and send the required motions back to cloud

stevemartin gravatar image stevemartin  ( 2018-11-20 03:40:42 -0500 )edit

What sort of connections are you using? Decoding encoder signals is typically something done with cycle times of milliseconds or less. How are you delegating that to a cloud instance? Or are you describing a system in which a base driver publishes ints (for example) and a remote node ..

gvdhoorn gravatar image gvdhoorn  ( 2018-11-20 07:19:45 -0500 )edit

.. subscribes to that and publishes the conversion to engineering units (and proper ROS msgs)?

gvdhoorn gravatar image gvdhoorn  ( 2018-11-20 07:20:08 -0500 )edit

Question Tools

1 follower


Asked: 2018-11-19 16:01:51 -0500

Seen: 200 times

Last updated: Nov 19 '18