SLAM Performance on Embedded Robots Undergraduate Student Research: Individual Project

We explore whether it is possible to run the popular ORBSLAM2 algorithm (simultaneous localization and mapping) in real-time on the Raspberry Pi 3B+ for use in embedded robots. We use a modified version of ORB-SLAM2 on the Pi and a laptop to measure the performance and accuracy of the algorithm on the EuRoC MAV dataset. We see similar accuracy between the two machines, but the Pi is about 10 times slower. Finally, we explore optimizations that can be applied to speed up execution on the Pi. We conclude that with our optimizations, we can speed up ORB-SLAM2 by about 5 times with minor impact on accuracy, allowing us to run ORB-SLAM2 in real-time. INTRODUCTION Simultaneous localization and mapping (SLAM) is the problem of, given an unknown world, mapping the world and localizing within that map. It is used by self-driving cars, uncrewed aerial vehicles (UAVs), autonomous underwater vehicles (AUVs), and vacuum cleaning robots, to name a few. In most of these use cases, the SLAM algorithm needs to run on embedded devices, such as the Pi. Our goal is to find the optimal conditions for running ORB-SLAM2 [5], a popular algorithm used for real-time SLAM with mono, stereo, and RGB-D camera inputs, on the Pi. MEASUREMENT In this paper, we use "performance" to refer to the time it takes to run the algorithm and "accuracy" to refer to the correctness of the output. We use the following accuracy metrics: 1. Absolute Trajectory Error (ATE): ATE measures the holistic accuracy of the algorithm by comparing ground truth trajectories1 to the predicted trajectories [6]. 1The EuRoC MAV datasets provide ground truth pose captured using the Vicon motion capture system and the Leica MS50 laser tracker and scanner ACM ISBN 978-1-4503-2138-9. DOI: 10.1145/1235 Table 1: Raspberry Pi Data. Stereo Camera Mono Camera Dataset ATE RPE ∑ t (s) ATE RPE ∑ t (s) MH01 0.038 4.76 1581.8 3.318 4.55 996.4 MH02 0.046 4.86 1300.6 0.365 5.07 777.0 MH03 0.044 4.09 1150.4 2.951 4.39 636.2 MH04 0.143 8.19 805.3 5.427 7.99 442.1 V1 01 0.087 2.34 1075.5 1.179 2.20 732.4 V1 02 0.064 2.44 635.0 1.262 2.06 360.4 V1 03 0.135 2.12 818.1 1.017 1.85 471.8 Table 2: Laptop Data. Stereo Camera Mono Camera Dataset ATE RPE ∑ t (s) ATE RPE ∑ t (s) MH01 0.037 4.83 202.0 0.538 5.40 92.9 MH02 0.049 4.86 145.4 2.822 4.44 76.5 MH03 0.042 4.08 138.2 3.445 4.68 65.4 MH04 0.064 8.20 85.6 6.185 8.26 40.7 V1 01 0.088 2.34 115.8 1.211 2.23 75.4 V1 02 0.066 2.44 68.8 0.905 2.06 35.8 V1 03 0.071 2.12 85.1 1.195 1.74 43.2 2. Relative Pose Error (RPE): RPE measures the amount of drift in the system by comparing relative transformations between successive poses for the actual and ground truth datasets1 [6]. And the following performance metric, the total tracking time – ∑ t (seconds): ∑ t is the total number of seconds it takes to process all images, excluding any file loading or parsing time. TESTING ENVIRONMENTS The software is built, packaged, distributed, and executed using Docker. We use the following two test machines: 1. Raspberry Pi 3 B+ (4x Cortex-A53; 1 GB RAM; Raspbian) 2. OVERPOWERED Laptop 15+ (Intel i7-8750H; 32 GB RAM; Windows 10 Education)2 DATA AND ANALYSIS The data collected follows below trends: • Stereo camera inputs provide much better accuracy while taking 2× longer to process (see figures 1 and 2). • The laptop is 8.8× faster with stereo camera inputs and 10.3× faster with mono camera inputs. • Both machines show similar RPEs, indicating that there’s not much difference in the drift. • The Pi had a higher ATE on average. However, this can be attributed to a few outliers. 2Docker Desktop for Windows uses the Hyper-V hypervisor to set up a Linux virtual machine to run Docker. This process incurs some performance overhead. Figure 1: ∑ t difference between our machines (higher is better). 0.0 200.0 400.0 600.0 800.