I would like to build a visual SLAM robot (just for self-learning purpose) but I get frustrated how I know which processor and camera should be used for visual SLAM.

First, for the processor, I have seen three articles, which shows different systems are used for implementing their SLAM algorithm:

  1. Implementing SLAM algorithm (however it uses ultrasonic sensor rather than visual sensor) in Raspberry Pi (processing power is only 700 MHz) in Implementing Odometry and SLAM Algorithms on a Raspberry Pi to Drive a Rover

  2. I have also seen that Boston Dynamics use Pentium CPU, PC104 stack and QNX OS for their Big Dog project, BigDog Overview November 22, 2008

  3. Then, I also found a project uses a modern XILINX Zynq-7020 System-on-Chip (a device that combines FPGA resources with a dual ARM Cortex-A9 on a single chip), for a Synchronized Visual-Inertial Sensor System, in A synchronized visual-inertial sensor system with FPGA pre-processing for accurate real-time SLAM

But after reading those, I have no clue how they end up with those decisions to use those kinds of processors, stacks or even OSes for their project. Is there a mathematical way, or a general practice, to evaluate the minimum requirement of the system (as cheap and as power efficient as possible) for an algorithm to run?

If not, how could I know what processor or system I have to prepare for a visual SLAM robot? If there is no simple answer, it is also cool if you can recommend something I could read to have a good start.

Secondly, I also cannot find clear information which camera I should use for a visual SLAM robot. I also have no idea how they evaluate the minimum requirement of the camera. I found a lot of papers saying they use RGB-D camera but when I Google to find one, there are very few commercially available. The one I found is Xtion Pro Live from ASUS Global (for $170). Are there any practice I can choose a suitable camera system for visual SLAM too?


2 Answers 2


Depending on the camera you are using, your SLAM algorithm has to be adapted. You can simply use a RGB camera (webcam-like camera), it is not necessary that the camera is an RGB-D camera. Nevertheless, using only an RGB cam you'll be doing a bearing only SLAM.

I recommed you stay away from ultrasonic sensors for SLAM, they are not precise. They were used in the past but with LIDARs getting cheaper and more accessible it is a much better choice.

Concerning the CPU, if you're doing a VSLAM and you're just grabbing some opensource code try to use a CPU with similar processing power. Otherwise you can try your algorithm (if you're writing your own code) on a pre-registered dataset offline on any PC and at the end if you cannot manage to run it in real-time then you should opt for a faster CPU. If you were comfortable with GPU programming try to accelerate your code in VSLAM you will end up doing a lot of image processing.

Finally, it is true that the performance depends on the algorithm developed, however, keep in mind that a major factor is the quantity of data you are throwing at it per unit of time. Example with LIDAR-based SLAM processing data coming from a velodyne-16 layers was a lot easier than processing data coming from velodyne-64 layers or 128 layers. The number of points it will generate per second is much higher. One approach would be to down-sample the data acquired.

In case of the camera, you should take into account the size of the processed frame, and the how many frames you're getting per second.

I recommend you start testing offline on any available PC and then estimate your needs based on your algorithms & sensor combination.


In college I served as the team leader in development of an autonomous underwater vehicle (AUV). In the beginning we were confronted with very much the same question you are presenting right now. Ultimately it came down to, we knew that we didn't know what we didn't know. Collectively we had all had some amount of embedded systems development experience, but jumping from making a small dual axis gimbal project to making a completely autonomous robot capable of interpreting it's environment was massive, and we had no idea the level of computing we would need. That being said, we were relying heavily on vision systems which, from doing some small experiments with a Raspberry pi attempting to interpret live video feeds, we knew was going to be processor intensive. Therefore, our solution was to GO BIG. As the centeral processor we crammed in a Gigabyte Core i7-6500U. It more than adequately addressed all our requirements. With something like this, you can't necessarily know what all you are going to need system wise until you are done. Then you can look at how much your system requires and scale down to more appropriate hardware afterwards. I hope this helps. I know it's a frustrating situation to be in.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.