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

remote 3d slam with limited sensing and bandwidth

asked 2018-05-08 14:43:16 -0500

Toms42 gravatar image

I'm trying to implement a 3d visualization for a remotely operated robot, which will be equipped with either stereo grayscale cameras or one grayscale camera and a line striping system that can generate a point cloud. However, the application is incredibly bandwidth/compute limited, and most SLAM systems I've found don't seem to fit the requirements well. The robot is incredibly slow, and I would likely be able to get a pair of images maybe every 5-10cm it travels, in an outdoor environment.

I've looked at rtabmap, specifically this example, but I can't run stereo odometry on the robot, and at this bandwidth I'm unsure if it would work remotely. I have no access to compass or gps data, only IMU data from accel+gyro.

Does anyone here have experience with remote slam for a low-bandwidth compute-limited platform?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-05-10 11:16:26 -0500

matlabbe gravatar image

How much bandwidth do you have? Based on this tutorial and that answer, you may get 600 KB/sec for 5 Hz images or 4.5MB/sec for 30 Hz images. For stereo odometry, it is preferred that you have at least 10-15 Hz, which would be between 1 and 2 MB/sec. Another option is to do visual odometry onboard (if the onboard computer can compute odometry over 10 Hz), but SLAM remotely. As rtabmap is updating only at 1 Hz (by default), you would only need to publish images at 1 Hz out of the robot with the odometry computed.


edit flag offensive delete link more


We only have about 10Kbps of bandwidth, so image frequency is measured in minutes not hertz. The upside is that the robot is traversing on the order of mm/s, so we will likely only be moving several cm between photos, but very slowly. Odometry on the robot would be ideal, but hopefully unnecessary.

Toms42 gravatar image Toms42  ( 2018-05-10 17:05:16 -0500 )edit

Just another idea, having lower resolution images may also help to save some bandwidth at the cost of less good odometry.

matlabbe gravatar image matlabbe  ( 2018-05-10 17:16:53 -0500 )edit

oh yeah that's the plan for sure. Even at 240p black/white images, it's something like 1-2 minutes per frame at 10kbps. I might be sending point clouds too. I'm mostly worried about even being able to configure RTABMAP to update when I get a frame, rather than at a fixed rate.

Toms42 gravatar image Toms42  ( 2018-05-10 17:20:15 -0500 )edit

We might abandon actual SLAM and rely on standard point cloud registration without loop closure. The mission goal is to map a relatively featureless outdoor environment with several known landmarks, but the bandwidth limitations are very restrictive. We're limited to small embedded devices too.

Toms42 gravatar image Toms42  ( 2018-05-10 17:21:56 -0500 )edit

If you could segment out the 'known landmarks' and identify them (ie: without using a slam approach, sort of like a virtual tag or beacon), perhaps the fiducials pkg could be interesting.

gvdhoorn gravatar image gvdhoorn  ( 2018-05-11 03:24:46 -0500 )edit

Question Tools

1 follower


Asked: 2018-05-08 14:43:16 -0500

Seen: 253 times

Last updated: May 10 '18