Digitabulum: The last motion-capture glove

Digitabulum is an open motion-capture glove
that was intended to be a full-featured, hacker-friendly user-input and sensor platform.

Similar projects worth following
This is Digitabulum (latin: glove). It is an open-source motion capture glove that was intended to be a full-featured, hacker-friendly user-input and sensor platform with a target price of under $300 per hand in its most complete configuration.

It is the goal of this project to provide an affordable, general open platform on which all other gloves can be emulated, and that does not require a host computer to be used as a high-level tool for sensing things in the environment that we ordinarily cannot.

Additionally, the potential for accelerating human communication with computers has not yet received the attention that the designer feels it is due.

The team

Digitabulum is Manuvr's flagship project. Here is out team.

Ian Lindsay started the project in 2014, and is the hardware designer and low-level bit-pusher.

Brent Long builds 3D augmented-reality applications.

Josh Treadwell is an electronic musician/producer.

Javascript programmers, all.


If it isn't open-source, it isn't worth investing the brain-space to learn. All the firmware is on our github page along with instructions for building it. If the release goes well, we will also post hardware details.

We don't care to pick a "target-market". We would prefer to give creative people good tools to define the markets that everyone else is hung-up on chasing.

Your hands are your own, and no one can possibly code for every conceivable use you have for them. We've watched many companies die trying.

We designed the glove with an expansion port for the sake of novel hardware so that better tools can be developed and shared.

Defense of design

Why are you trying to capture a hand?

The designer's Statement of perspective along with what may be the single most valuable thing that could be done with this technology.
Also, Ian wants to play dubstep with it.

Alright... How are you going to capture a hand? Defend your choices.

What sensors to use.

How co$t was balanced, and my definition of a good tool.

And the best strategy I could think of to make it as cheap as possible without making it garbage.

Other information

KiCAD template for custom bases.

Prototype photo collection

Videos of our team working problems and presenting ideas.

The glove's Trello board. It is updated infrequently, but is still updated.

The same caveat applies to the LibManuvr Trello board.

The firmware on the glove is composed of two original projects: ManuvrOS and Digitabulum-Firmware. Both projects are hosted on Manuvr's github page, but the development forks are here (ManuvrOS) and here (Digitabulum-Firmware).


This paper influenced the hardware designer.

Adobe Portable Document Format - 6.82 MB - 07/04/2016 at 11:43

Preview Download

View file

  • 1 × EPM570T144 Logic ICs / Programmable Logic: PLDs
  • 17 × LSM9DS1 Inertial measurement unit.
  • 1 × ADP8866 LED driver
  • 1 × ATECC508a Secure element

  • 2017.02.18: r2 PCBs have arrived

    J. Ian Lindsay02/21/2017 at 12:16 0 comments

    Full post at our blog.

    LED driver and i2c validate. CPLD image flashed.
    More to come as I implement SPI slave capabilities on the ESP32.

  • 2017.01.21: KiCAD template is now open

    J. Ian Lindsay01/21/2017 at 09:09 0 comments

    With r2 having recently gone to the fabricator, I had to roll a new debugging harness. While I was at it, I exported the key materials into a template project for the sake of those who want to supply their own design.

    This PCB rides underneath the sensor board and breaks out to a breadboard-friendly header. The 10-pin header off on the side is the JTAG port.


  • 2017.01.07: Flex circuits have all arrived

    J. Ian Lindsay01/08/2017 at 05:05 0 comments
  • 2017.01.05: Flex circuits, and a release choice​​

    J. Ian Lindsay01/06/2017 at 08:37 0 comments

    Full post at our blog

    Any advice related to release is requested from those who have done it before. We are quickly nearing that point.

  • 2016.12.14: Digit update

    J. Ian Lindsay12/15/2016 at 03:00 0 comments
  • 2016.11.20: Final flex circuit stackup

    J. Ian Lindsay11/20/2016 at 22:07 0 comments

  • 2016.10.19: Final digit layout

    J. Ian Lindsay10/19/2016 at 07:18 0 comments

    Fabricator is ready to roll with the flex circuits, after a looooong game of ping-pong and a few re-work cycles. Getting things right in such tight constraints was not a trivial task. And after more than a year of refinement, the digits should be landing on my bench around this time next month. I think I've pulled it off. The blue circle is a US dime.

    This layout will accommodate either of two strategies I have for eliminating the preferential flex plane of the flex circuit. Construction is 4-layer polyimide. The dense nodes will be FR-4, giving the components a rigid mounting plane (durability-enhancement).

    The CPLD is ready to accept the digits, and the software is ready to validate them.

    I now have one month to be ready to cast them in silicone. So I'll be blendering.

  • 2016.09.18: Feedback requested

    J. Ian Lindsay09/18/2016 at 19:49 0 comments

    The digit manufacture is still moving (slowly). There were some complications regarding buried vias in the polyimide flex circuits that mandated a rework. Re-work is now completed with no significant size increase.

    With the CPLD finished, the question I have for everyone is:

    Should we release as a sensor-package-only kit?

    This would mean that others would need to bring their own ideas about battery, CPU, comm module, etc. All that would be included would be the sensor package with a 20-pin connector. The digits and textile would be ready-to-wear, and demonstration code and full schematics would be supplied.

    This would be a step away from a consumer-ready product, but considering the release of the ESP32, the improved PIC32MZ, and a few releases from Intel, those of you reading this may not want a compute platform imposed on you. Not only that, but the sensor package will potentially be releasable this year. And if I wait to release until the entire thing is done, it will take months longer.

    Commentary, and opinions are invited.

  • 2016.07.04: CPLD is ready-to-rock

    J. Ian Lindsay07/04/2016 at 10:04 0 comments
  • 2016.06.13: CPLD patent filed

    J. Ian Lindsay06/14/2016 at 07:02 1 comment

    I am now waiting on the USPTO to write me back and tell me what I screwed up.

    But in all seriousness... it's a tremendous relief to be at this point.
    How big a relief?

    I started designing r1 about 13 months ago, and received the populated main-boards in October (8 months ago).

    Arguably, the CPLD contains the majority of the complexity of this project. Once (if?) I publish its schematics, you won't have to take my word for it. We're talking about BGA100 parts on a 6-layer PCB with buried vias, and accounting for ~70% of the trace-length in the board, the odds of recovery from a mistake made here approach zero.

    Even partial-failure of this subsystem would mean a basically useless main board, and (~$2600 + 2 months) blown on a moment's oversight.

    For an engineer that touches the physical world, "invoking GCC" might cost more than he makes in six months. So when you meet someone who routinely codes for 10+ hours in C, and their code not only compiles the first time, but does exactly what they meant it to do, this is one possible explanation for how they got that way.

    And when you fund a project on your own dime, there are only so many stupid small mistakes you can make before economics kills your project. Any given millimeter of trace might be the thing that vaporizes thousands-of-dollars and the possibility of timely market-entry.

    Do Not. Fuck. Up.

    So until I could (in)validate the CPLD, nothing more could be decided about the future. And nearly everything else must be built before this particular piece could be tested.

    So after about one year of experimenting on a working r0, planning, designing, and finally porting firmware, I proved my hardest hardware lemma to myself. The CPLD works.

    This is not to say validation is complete. But it has passed enough tests to convince me that the design goals articulated here will all be met (if they aren't already). Software is going to be *much* cleaner. Hell... the initial working ported code already is cleaner, despite being a sad assemblage of hackery.

    Why the patent?

    I've never held the US patent system in high-esteem as-implemented. But until we have a blockchain-driven patent system that manages itself and pays inventors based on reference in open-source designs, the idea of purely-defensive patents will have to make-due. Provided my filing goes through, I will begin publishing full CPLD schematics and images alongside the firmware.

View all 43 project logs

  • 1

View all instructions

Enjoy this project?



J. Ian Lindsay wrote 02/17/2017 at 07:39 point

The r2 boards should arrive tomorrow. So excited!

  Are you sure? yes | no

J. Ian Lindsay wrote 01/15/2017 at 09:06 point

Flex units all test good up to 3MHz. CPLD validates. Final version of r2 sent to fabricator tonight. Progress continues....

  Are you sure? yes | no

Chris Duncan wrote 12/15/2016 at 08:32 point

Any idea how this stacks up quantitatively to the motion on the hand. How stable are joint angle measurements at MCP, PIP, DIP? What is the standard error of the mean or variance of joint angle and joint velocities?   How well does this compare to the Cyberglove?  I'm considering building one of these vs. leasing a cyberglove for a pilot project for impaired hand dexterity.

  Are you sure? yes | no

J. Ian Lindsay wrote 01/15/2017 at 08:54 point

Sorry it took me a month to reply. I just noticed the comment. These are all excellent data-oriented questions that I am not yet prepared to provide answers for. :-)

However... I notice that CyberGlove uses flex resistors, so in order to give you the interphalangeal angles you want, they would have to have a minimum of 4 flex resistors per-digit and probably at least one additional for the thumb to account for the extra degree of freedom in its proximal joint.
Since we are using IMU's, if you want precise angle, you would be able to derive it fairly easily with excellent accuracy by using gravity as a reference-point.

Here is a video from our prototype tests:

That render you see was derived completely from the angles you are interested in. There was no magnetometer calibration whatsoever, which is why the render is contorted. But, as you can see, the data pipeline is all in-place.

If you want to build your own, I will be rolling the first version for release as a kit in the next few months. And it will cost *lots* less than CyberGlove. Revision 2 of the hardware was sent to the fabricator about 3 hours ago.

  Are you sure? yes | no

J. Ian Lindsay wrote 03/12/2016 at 09:17 point

Flex circuits sent to fabricator. There is normally some back-and-forth at this point. But the first volley has been fired and the production of the digits is now imminent.

  Are you sure? yes | no

J. Ian Lindsay wrote 10/30/2015 at 06:51 point

USB port placed on one of the r1 boards. Repair succeeded. Board is discovered by host....
Bus 004 Device 035: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

CPU therefore validates. I can write firmware.

  Are you sure? yes | no

J. Ian Lindsay wrote 10/28/2015 at 06:46 point

r1 main PCB passes the smoke-test. Current draw with no software and no CPLD programming is ~20 mA and stable.

  Are you sure? yes | no

Gravis wrote 07/04/2015 at 01:24 point

everything about this glove is overkill! you would be better off using the MMA8653FCR1 for the digits and have one LSM9DS1TR for the palm.  the PLD is totally unnecessary and the MCU is overpowered.  the bluetooth module is also overkill but it's the type of MCU (bluetooth) you should be using.  check out using a cheap ESP8266 SoC based module because that's all you need for forwarding the data to a computer.  on the computer is where any post-processing should be done.  do this and you can reduce the cost by an order of magnitude.

  Are you sure? yes | no

J. Ian Lindsay wrote 07/04/2015 at 04:18 point

Your comments suggest that you haven't read this page, and that you haven't thought very hard about the problem being solved here.

The MMA8653FCR1 *is only 10-bit*. Seriously?!? Sure... it costs $1, but it won't do the job.  See this post if you don't understand why it won't do the job:

How would I do post-processing on the host if I can't send all the data to the host as fast as it happens?

How do you have 17 sensors electrically connected without a demux strategy of some sort (CPLD)?

Is the ESP8266 able to act in a peer-to-peer manner with other ESP8266's?

If you want to write software for a low-end piece of hardware, you're free to  design a piece of low-end hardware. I won't design low-end hardware. I design the hardware that I want to program on.

  Are you sure? yes | no

Gravis wrote 07/08/2015 at 12:12 point

actually, i had considered the problem and even read your justification of your choice in sensors and i believe you have overestimated your requirements.  i was merely trying to help but since you clearly don't want it, i'll leave you be.

  Are you sure? yes | no

J. Ian Lindsay wrote 07/09/2015 at 18:12 point

If you are genuinely trying to help, then "thank you". You would help by answering any of the questions I asked after you told us what we should have done. I invite anyone to demonstrate they have a better idea.

  Are you sure? yes | no

J. Ian Lindsay wrote 07/04/2015 at 04:36 point

You drew my attention to the fact that I hadn't updated the parts manifest for hardware r1. The CPU and CPLD are both larger. So we are going in the exact opposite direction you think we ought to.

r0 reads each of the 17 sensors  at 400Hz. r1 will read at 1000Hz.
The CPLD makes that datarate possible by segmenting the bus by anatomical division (which implies an electrical division). Otherwise, you burn too much power because you need to run your sensors' bus at 17x their peak datarates. Not only that, but you have to do so in the face of the worst-possible signal reflection scenarios: a star (branching digits).

(17 sensors) x (1000Hz) x (12 bytes per sample) = 204KB/sec
Want to sustain that datarate over a radio? That's very extravagant of power, you know.... I'm guessing you wern't thinking about the fact that this thing has to be battery powered.

I would advise you try doing the things you suggest. After upgrading every part and fighting with the constant lack of headroom in the hardware, you can come to the same conclusions I did, and spend an extra $10 to have a device that doesn't suck.

  Are you sure? yes | no

visualkev wrote 07/20/2014 at 15:05 point
Can you post pictures of your current prototype glove? I'm curious to see how to crammed all the outlined functionality into it.

  Are you sure? yes | no

J. Ian Lindsay wrote 07/20/2014 at 15:42 point
My prototype didn't have all this awesome on it. I also can't post any more images to this project page. I'm in the process of constructing a more complete doc page. I will update the project with links as soon as I have finished. :-)

  Are you sure? yes | no

J. Ian Lindsay wrote 07/20/2014 at 18:40 point

There are two additional pages. The POC Postmortgem is where the things you are interested in will end up. ATM I just have photos of the phalanx assembly, but I'll be posting more as I collect it.

[edit: Correcting broken link]

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates