Runtime performance. In the last column of Table II, we show the median of the extrapolated processing rates of the tracking algorithms based upon actually measured cycle times (without taking the detection stage into account). All methods have been hand- optimized for runtime performance. For an equal compari- son, and with the application scenario of the service robot with limited on-board processing capabilities in mind, we restrict the tracker’s CPU usage to a single thread. It can be seen that the NNT, even with our extensions, is extremely efficient due to its simplicity, being able to theoretically process over 5000 tracking cycles per second in moderately crowded scenarios (Main Station), and still over 600 in very crowded scenarios (PedSim). The entire tracking framework, with 2 separate laser detectors for front and rear, runs in real-time at 35 Hz on our robot platform, with the tracker itself consuming less than 30% of a single CPU core even in crowded scenarios. Looking at the cycle rates of the basic NNT on the PedSim dataset, which are in the order of around 1000 Hz, it easily becomes apparent why in such highly crowded scenarios with over 30 tracks in sensor range at a time, a hypothesis- oriented multi-hypothesis approach cannot succeed without massive parallelization. Since in the MHT, the data asso- ciation step performed by the NNT needs to be repeated for every single hypothesis, we cannot expect more than 1000 Hz : 500 hyp. ≈ 2 Hz on a single CPU core assuming we want to generate at least 500 hypotheses. Even on a processor capable of executing 8 threads in parallel, the expected frame rate would drop below 20 Hz without yet running any detection or higher-level perception components.
Runtime performance. In the last column of each table, we show the median of the extrapolated processing rates of the tracking algorithms based upon actually measured cycle times (without taking the detection stage into account). All examined tracking systems are implemented in C++. Note that the rate of MHT is fixed to 30 Hz, generating as many hypotheses per cycle as possible in this time frame (at lower rates, the performance gets worse due to less frequent updates of the EKF). The simple NNT is about 3 times computationally more efficient than the Extended NNT. Both outperform the two more complex methods MDL and MHT by two orders of Method XXXX rIDS Airport Sequence 03 FP% Miss% MT ML Hz XXXX Motion Capture Sequence rIDS FP% Miss% MT ML Hz NNT [9] 27.7% 227 39.4% 32.5% 92 47 13701 60.7% 131 23.6% 14.3% 4 0 20726 Extended NNT [8] 44.4% 210 13.1% 42.1% 63 60 4287 69.8% 151 7.8% 20.9% 4 0 5637 MHT [10] 26.9% 338 39.4% 33.0% 87 51 28 57.9% 173 24.7% 15.6% 4 0 28 MDL-Tracker [7] 43.7% 428 12.5% 43.1% 36 59 53 60.7% 373 4.8% 31.3% 1 0 139 TABLE I Only front rgb-d detections (small fov) Method XXXX rIDS Airport Sequence 03 FP% Miss% MT ML Hz XXXX rIDS Motion Capture Sequence FP% Miss% MT ML Hz NNT [9] 59.7% 236 20.8% 19.3% 000 00 0000 25.6% 54 70.4% 3.3% 4 0 17968 Extended NNT [8] 62.8% 331 3.4% 33.5% 68 35 2307 68.8% 60 25.3% 5.2% 4 0 4988 MHT [10] 58.9% 700 16.6% 23.9% 85 26 29 28.0% 85 67.3% 3.8% 4 0 28 TABLE II Only laser detections (large fov) Method XXXX rIDS Airport Sequence 03 FP% Miss% MT ML Hz XXXX rIDS Motion Capture Sequence FP% Miss% MT ML Hz NNT [9] 45.7% 325 36.4% 17.7% 123 19 4590 14.8% 55 81.7% 2.7% 4 0 15703 Extended NNT [8] 62.1% 313 8.2% 29.4% 96 26 2005 74.9% 58 20.1% 4.3% 4 0 4690 MHT [10] 46.3% 692 34.9% 18.2% 117 22 31 8.6% 74 87.6% 2.9% 4 0 29 TABLE III Multi-modal detections (large fov) Method XXXX rIDS Airport Sequence 03 FP% Miss% MT ML Hz XXXX rIDS Motion Capture Sequence FP% Miss% MT ML Hz NNT [9] 62.1% 226 18.7% 19.0% 000 00 0000 18.1% 52 77.6% 3.7% 4 0 15857 Extended NNT [8] 64.2% 262 3.3% 32.4% 77 33 2222 77.4% 62 16.5% 5.4% 4 0 4744 MHT [10] 60.2% 676 17.2% 22.0% 97 24 29 17.8% 76 77.7% 3.6% 4 0 28 TABLE IV Multi-modal detections without hog (large fov) magnitudes, and require less than 10 percent CPU usage even in very crowded environments.
Runtime performance. Our system runs in real-time at 20–25 Hz using the configuration described in Sec. 6.4 on two Intel Core i7-4700MQ gaming laptops with 8 GB RAM and nVidia GeForce GTX 765M graphics10. These laptops are dedicated to percep- tion tasks on the robot. We avoid expensive streaming of RGB-D images over network by executing the RGB-D detectors directly on the laptop where the cor- responding sensor is connected via USB. The computationally most expensive components are the person detectors, each requiring about one CPU core, with the people tracker itself requiring only 10–15% of a single CPU core when 20–30 tracks are simultaneously being tracked.
