Bristol Interaction Group

Mobile Kinect

A mobile, wireless depth camera based on the Microsoft Kinect


We have developed a mobile, battery-powered, wireless depth camera based on (and compatible with) Microsoft’s Kinect. In order to promote the use of this device across a wide range of domains, we are making the circuit diagrams and PCB layouts for the additional circuitry available. Our design only uses the front ‘camera’ circuit board of the Kinect, a second bespoke board of the same small size that plugs onto the back of this board in place of the standard large kinect board, which in turn plugs via USB into a Gumstix embedded linux computer running an open source driver and streams via an 802.11n dongle. The design would work equally well with a Raspberry Pi or other SBCs with a bit of hacking.

This work is part of the RCUK Digital Economy PATINA project, for more information see

Below is a video of an early version we built last year.



Schematics and Board Layout

The schematics and board layout files are available in both CadSoft Eagle format and also Gerber format for printing.

Parts List

The following is a list of the major non-standard parts needed to build the circuit board for the mobile Kinect. Where possible we have included supplier names and part numbers for difficult to find parts.

  1. 14-way board to board connector for Kinect main circuit board (Part no. 1929681 from Farnell)
  2. LM1085-5V, 5V 3A LDO regulator (Part no. 5339404 from RS)
  3. LD1086-3V3, 3.3V 1.5A LDO regulator (part no 3554831 from RS)
  4. USB connector, Molex OTG (Part no. 5152005 from RS)

 The boards generate a lot of heat when running, so some heatsinks and fans will be needed. The choice of these parts will depend on the shape and size of enclosure that you build for the device.

 Embedded Hardware

The mobile Kinect software runs on a Gumstix Overo Summit board, running a Gumstix Fire COM.

You don’t have to buy a whole Kinect and take it apart, as replacement parts for the ‘sensor’ camera board, CMOS camera and laser projector attachments are separately available. Search online for the following part numbers and choose your supplier: X850036015, X853750001, VCA379C7130 and OG12/0956/D306/JG05A. Note that the spatial offset between the IR projector and the IR CMOS camera is hard coded and critical to the function of the device, so you will need to be very precise if you install these components directly onto your own casing instead of reusing (bits of) the metal casing that comes inside the kinect.

The circuit board produces three different supply voltages to the kinect: 5V, 3.3V and 1.8V. The 1.8V and 3.3V supply lines connect only to the Kinect board through the board-to-board connector. The 5V supply also passes through this connector and is also available at a number of terminals on our circuit board to power other devices as follows:

  • GS5V:  Power for Gumstix board
  • USB5V: USB WiFi adapter
  • FAN1 and FAN2: power for 2 cooling fans

The circuit is designed to work with battery voltages above 6V. We generally use a 7.5V 2.2Ah Li Ion battery pack.


Even with this clunky setup we are currently getting about 24 frames per second (which is fast enough to drive the PointCloudLibrary Kinectfusion implementation as shown in the video) and about half an hour of continuous operation, but significant further miniaturistion and battery life improvements will be possible by using a more integrated embedded system. All that is required is the standard Kinect camera board, cameras, IR projector, our circuit board and something at the back that can be powered by a battery, accept USB data (as a USB2 host), run a kinect camera driver, and stream the data over wifi-N. The processor inside the gumstix is an ARM Cortex-A8, and is not sufficiently powerful to process both the depth and RGB data on the OpenNI driver (so we turned the RGB off) and maxes out our 802.11n network which is why the framerate is so low on the mobile phone display in the video as it is sending to the phone over the same wifi network. This could be fixed by (1) installing a less turgid driver, (2) using a faster processor and/or (3) doing some compression over the streamed data.

(1) OpenKinect.

(2) e.g. Android PC on a stick with Cortex-A9.

(3) Jan Kautz’s depth streaming paper.