remote 3d slam with limited sensing and bandwidth

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

Toms42
1 ●1 ●1 ●1

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?

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

matlabbe

6409 ●11 ●96 ●80

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.

cheers,
Mathieu

edit flag offensive delete link

Comments

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 ( 2018-05-10 17:05:16 -0600 )edit

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

matlabbe ( 2018-05-10 17:16:53 -0600 )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 ( 2018-05-10 17:20:15 -0600 )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 ( 2018-05-10 17:21:56 -0600 )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 ( 2018-05-11 03:24:46 -0600 )edit

add a comment

remote 3d slam with limited sensing and bandwidth

1 Answer

Comments

Question Tools

Stats

Related questions

remote 3d slam with limited sensing and bandwidth edit

1 Answer

Comments

Question Tools

Stats

Related questions

remote 3d slam with limited sensing and bandwidth