Close
0%
0%

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.

j-ian-lindsayJ. Ian Lindsay
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Public Chat
Similar projects worth following
8k views
15 comments
1.7k followers
View Gallery
Public Chat
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.

Core-values

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.

shamanic-interface.pdf

This paper influenced the hardware designer.

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

Preview

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

View all 46 project logs

  • 1
    Step 1

View all instructions

Enjoy this project?

Share

Discussions

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.

http://manuvr.io/blog/2017/01/06/2017-01-05-flex-circuits-and-a-release-choice/

  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:
http://manuvr.io/blog/2015/06/14/defense-of-design-choices-sensors/

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]

http://manuvr.io/blog/2015/04/15/hardware-r0-photo-collection/

  Are you sure? yes | no

Similar Projects

Turning the BeagleBone Black into a retro gaming appliance
Project Owner Contributor

Beagle Entertainment System

andrew-hendersonAndrew Henderson

An open hardware-software framework based on inertial sensors that anyone can use to build a human motion capture system.
Project Owner Contributor

Motion Capture system that you can build yourself

bruno-laurencichBruno Laurencich

General purpose low cost handheld terminal with screen/kbd, wifi, barcode and RFID reader for industrial or commercial (or any other) use
Project Owner Contributor

Data Collection Terminal

bozBoz

A multi-platform asynchronous operating system wrapper.
Project Owner Contributor

LibManuvr

j-ian-lindsayJ. Ian Lindsay

Does this project spark your interest?

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

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2025 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "Digitabulum: The last motion-capture glove", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.