Runtime performance Clause Samples

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 ▇▇▇▇ rIDS Airport Sequence 03 FP% Miss% MT ML Hz ▇▇▇▇ 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 Only front rgb-d detections (small fov) Method ▇▇▇▇ rIDS Airport Sequence 03 FP% Miss% MT ML Hz ▇▇▇▇ rIDS Motion Capture Sequence FP% Miss% MT ML Hz NNT [9] 59.7% 236 20.8% 19.3% ▇▇▇ ▇▇ ▇▇▇▇ 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 Only laser detections (large fov) Method ▇▇▇▇ rIDS Airport Sequence 03 FP% Miss% MT ML Hz ▇▇▇▇ 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 Multi-modal detections (large fov) Method ▇▇▇▇ rIDS Airport Sequence 03 FP% Miss% MT ML Hz ▇▇▇▇ rIDS Motion Capture Sequence FP% Miss% MT ML Hz NNT [9] 62.1% 226 18.7% 19.0% ▇▇▇ ▇▇ ▇▇▇▇ 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 magnitudes, and require less than 10 percent CPU usage even in very crowded environments.

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.