Problem #3: USB Won’t Scale
Kinects have USB connectors. This is great for plugging a couple of them into a computer, but you run into problems with three or more. I believe it is possible on some platforms now with USB 3.0 to get six or more Kinects plugged into one device, but driver support on Linux seems to be problematic. I think people are aware of the problems and fixing them, so eventually the max number of devices that can plug into one computer should be pretty high. But then you have to worry about the maximum practical length of USB cables, which is maybe 20 feet before signal degradation rears its unattractive head. Off-the-shelf USB range extenders I’ve tried have failed, I believe because the Kinect sends power through the USB cable.
A solution is to convert the data to network traffic and then it can be shuttled to a central server using ordinary TCP/IP networking. Ah, but can you deal with the massive amount of data generated by the Kinect? 30 frames per second, 640 x 480 resolution, 11 or 16 bits per pixels. Double that if you are sending camera data along with depth data. And multiply that number by each Kinect in the system. So that is a firehose. The networking hardware (switches, routers, cables, etc.) will be fine with ordinary 100 Mbits/s equipment. But the CPU processing at the sending and receiving side can get overloaded pretty quick. And I mean just at the network stack level. If you hit the CPU wall, you would need to either compress the data before sending or do application-specific processing to send just what info is needed over the network. Since this is being done to fix a CPU bottleneck, the processing must be very simple or efficient to have a net gain in throughput. For example, quantizing the depth data and run-length compressing the results is cheap enough to fix the bottleneck on Intel Atom-based system.