Open-source myoelectric hand prosthesis

Similar projects worth following
Dextra is a printable human-sized robotic hand that is being developed as a part of a personal project aimed to develop an open-source and affordable robotic hand prosthesis. The key design points of Dextra are: adaptive grip, compact size, mechanical simplicity and ease of replication.

The main element of Dextra is the finger module. The hand is modular: the four fingers are interchangeable, and the thumb is a variation of the finger module. The finger module comprises the printable mechanical finger, the actuator and an encoder. The compact actuator uses a DC micro gearmotor to rotate a spool that winds a fishing line, converting the rotational motion of the motor into a linear motion.

The position of each finger module is controlled by a PID loop that uses the value provided by the magnetic encoder of the DC motor as the feedback signal. To be controlled by an amputee, Dextra uses a EMG interface that uses the user's myoelectric signals as the high-level control input.

The human hand is the most versatile tool we use in our daily lives. It is a highly dexterous organ that gives us a wide range of manipulation capabilities: its large number of degrees of freedom allows us to perform many tasks. Besides making us able to manipulate, operate or deform objects, its sensory ability allows us to, among other things, identify objects just by touch and shape, without seeing them. Our hands have played a major role in our own evolution and the development of our intelligence. They were our very first tools, and with them, we made our first artificial tools. Art (music, painting, writing) would be nothing without our hands. We give love and comfort with them. The hands are essential in the way we interact with our world as they are involved in almost every action we perform.

People suffering a limb amputation are forced to face their daily life tasks with the disadvantage of not having all their limbs. In the case of upper limb amputations, not having one or both hands is a major barrier in carrying out the daily tasks for those who suffer the amputation. Actions as simple as getting dressed, tying shoelaces or pouring water into a glass, have an added difficulty which restricts the autonomy and independence of the amputee. Given this scenario, there is a clear need for a tool to partially restore the functionality of the missing upper limb. That is why researchers and companies around the world have developed prostheses that help these people on living their lives in a more independent and simpler way.

Among the different types of prosthetic hands that exist, robotic prostheses are those with greater functionality. DC motors, or other kind of actuators, drive the motion of each finger, or groups of fingers. To control this devices, EMG signals, the electric signals generated by human muscles, are the common choice as user input. However, due to their complexity and the technologies they employ, commercial robotic hand prostheses are very expensive. If their cost is already high for the average Western citizen, the problem is exacerbated in the case of developing countries where, besides having a much lower level of income, the number of amputations is greater due to several factors such as war, a poor health system and defective safety measures at work. Another group that is affected by the high cost of these devices are children, who need to change their prosthesis every so often to adapt them to their physical growth.

Dextra is another example of the growing field of open-source, replicable, robotic hand prostheses, in the spirit of the designs of the Open Hand Project or Openbionics. There is a need for low-cost and hackable prostheses, as commercial ones are very expensive and cannot be modified to suit the needs of each individual. Moreover, and from a different perspective, robotic hands for a more general purpose also suffer from the same problems than robotic hand prosthesis. Robotic hands used in humanoid robots, robotic manipulators and research have a very high cost, in many cases unaffordable for startups, small universities and research centers. The existence of robotic hands that can be built and programmed by oneself could widen the field of application of these devices. They can be used by hackers everywhere in their own projects, and they can be introduced in schools and universities to taught robotics with a real device that can be used from the assembly stage to the development of different applications.

Main features

  • Replicable and modifiable.
  • Completely open-source. Designed with open-source software.
  • Compact design.
  • Modular and easy to assemble.
  • Underactuated fingers.
  • Adaptive grips.
  • Closed-loop position control.
  • Human-robot interfaces: EMG control and PC interface.
  • Built with cheap off-the-shelf components.
  • Cost to build a unit < 260$.

Compact design

To be accepted by the user, the prosthesis has to be close to the human hand in size and appearance. Also, to be used by any upper limb amputee,...

Read more »



sla - 199.98 kB - 02/26/2016 at 23:56




sla - 265.32 kB - 02/26/2016 at 23:56




sla - 291.59 kB - 02/26/2016 at 23:56




sla - 174.35 kB - 02/26/2016 at 23:56




sla - 211.70 kB - 02/26/2016 at 23:55


View all 15 files

  • 5 × Pololu Micro Metal Gearmotor 1000:1 HP with extended motor shaft
  • 5 × DRV8838 Single Brushed DC Motor Driver Carrier
  • 5 × Pololu magnetic encoder for Micro Metal Germotors
  • 1 × Turnigy TGY-EX5252MG Twin BB Digital Micro Servo Can be replaced by a Corona DS-843MG servo or other with the same dimensions
  • 1 × Teensy 3.1

View all 14 components

  • Hackaday Prize Finals, here we go!

    Alvaro Villoslada10/09/2016 at 22:29 2 comments

    After spending the last few weeks working really hard to get everything ready for the finals, it is finally all over. I have just posted the video for the finals, every file needed to replicate Dextra is uploaded and the assembly instructions are updated. It has been quite an experience, and the whole HAD prize thing has helped to give a huge boost to the project.

    I want to give my most sincere thanks to Hackaday for giving hackers and makers around the world this great opportunity to show people what we can do, and to demonstrate the tremendous power and potential that the open source philosophy and the community have.

    And finally, I want to wish all my fellow semifinalists the best of luck. The die is cast!

  • The cost of Dextra

    Alvaro Villoslada10/08/2016 at 20:02 0 comments

    One of the things that I still had to do was to calculate the total cost of Dextra. As I say in the project description, Dextra is a low-cost robotic prosthesis, but how low?

    ComponentPcsUnit priceSubtotal
    Pololu Micro Metal Gearmotor 1000:1 HP with extended motor shaft
    DRV8838 Single Brushed DC Motor Driver Carrier5$2,99$14,95
    Pololu magnetic encoder for Micro Metal Germotors3x packs of two pcs$8,95$26,85
    Turnigy TGY-EX5252MG Twin BB Digital Micro Servo1$9,73$9,73
    Teensy 3.11$19,80$19,80
    PLA or ABS filament spool750 g$21,60$21,60
    Fishing line spool (0.6 mm diameter)1$8,90$8,90
    1/8'' orthodontic elastic rubber bandsBag of 100$5,49$5,49
    M3x14 boltBag of 50$6,25$6,25
    M3x12 boltBag of 50$7,53$7,53
    M3x8 boltBag of 50$6,92$6,92
    M3x6 boltBag of 50$5,42$5,42
    M3x12 spacer2$0,471$0,942
    M3 nutBag of 100$5,26$5,26
    Total cost$259,392

    So the total cost of building a Dextra hand is $260. Of course, the "per unit" cost is less than this price, because for some components you have to buy more than what is needed to assemble the hand. For example, the total amount of plastic to print the mechanical components of the hand is 142 g (with 20% infill in all the pieces), so the unit cost of the plastic would be a little more than $4. The same happens with the screws, that come in bags of 50 units. When calculating the cost for the unit prices of each component and for the necessary quantities of each one, the price of building a Dextra hand drops to $197.3342. Pretty affordable I think!

  • Reproducing the Cutkosky grasp taxonomy

    Alvaro Villoslada10/06/2016 at 12:29 0 comments

    When robotic hand designers want to evaluate the dexterity of their latest design, the most common method is to try to reproduce as many grasps as possible from the Cutkosky grasp taxonomy. Mark Cutkosky wrote a paper in 1989 where he classified a set of manufacturing grasps in order to evaluate analytical models of grasping and manipulation with robotic hands. Since then, this taxonomy has been widely used to test the dexterity of robotic hands, to the point of becoming one of the basic benchmarks for these devices. This is the hierarchical tree of grasps:

    In the next image, this hierarchical tree is reproduced with images of Dextra performing the same grasps identified by Cutkosky:

    As can be seen, Dextra is able to reproduce 12 of the 16 Cutkosky grasps. To put this in perspective, the Robonaut 2 hand is able to reproduce 15 of the 16 grasps. I think it is not bad at all that a robotic hand that can be built at home is able to perform just 3 grasps less than a robotic hand designed by NASA.

    The robotic hand is also able to reproduce some grasps that are not present in the original grasp taxonomy. Cutkosky admits in his paper that the taxonomy is incomplete, because there are grasps, that he considers as "children", or combinations, of the classified grasps, that are not included. One of these children grasps is the one we use to write with a pencil. In view of the great obtained results, why not test whether Dextra is also able to perform this kind of grasp?

    And indeed it can! Of course to do this, I have helped the hand a little bit to put the pencil between the fingers. But once grasped, Dextra grabs the pencil very firmly and, thanks to the anti-slip pads of the fingers, it stays in place. I have to admit that I did not expect such good results at all.

  • Anti-slip fingerprints

    Alvaro Villoslada10/05/2016 at 09:21 0 comments

    One of the things that have been on the drawing board for some time is the improvement of the stability of the grips. PLA, which is the material of which Dextra is made, does not have very good anti-slip properties. For this reason, when handling small or thin objects the grip was not very stable and they always fell, and so did moderately heavy objects, such as a filled bottle, held upright.

    When I designed the current version of Dextra, I took into account this problem, so I included a small rectangular cavity on the underside of each phalanx. My idea was to fill these cavities with some material with a high friction coefficient and that was cheap and easy to get. However, after finishing the mechanical design, I started working on the software and other aspects of the project and I put aside the issue of grasp stability.

    This week I decided to tackle this problem, to be able to reproduce the Cutkosky grasp taxonomy (which is the most used benchmark for robotic hands) for the video of the Hackaday Prize finals. First, I tried with bathroom silicone sealant, but it was more slippery than I thought. I also thought of using laptop rubber feet, cut to fit inside the cavities of the phalanges, but they are usually quite bulging. Some years ago I used hot-melt adhesive for a similar purpose, so yesterday I went to the nearest hardware store to buy a hot glue gun and some glue sticks. I love hardware stores, so I took a walk to see what products they had. Then, on a shelf, I found a much better solution: a 9x10 cm rectangle of self-adhesive anti-slip foam. It is simply perfect. It is not only cheap (about $1,5 the unit) and easy to get, but also it is much better than hot-melt adhesive or laptop rubber feet because it is much softer. This means that when grasping an object, the pads will adapt to its surface, which will allow to perform much firmer grips, and even (a must try) hold delicate objects like an egg. In addition to that, being self-adhesive, its integration is a piece of cake.

    Today I have cut the pads with the dimensions of each of the cavities and installed them on the fingers. The result can be seen in the image below. I have spent the rest of the morning reproducing almost all of the grasps from the Cutkosky grasp taxonomy, and I am really happy with how the new anti-slip "fingerprints" work. Tomorrow I will post a new log showing the results of the grasping experiments, because I am frankly surprised by the dexterity of the hand, even though I am its designer!

  • First force control tests

    Alvaro Villoslada10/03/2016 at 15:25 1 comment

    As I said in the project details, I think a position controller alone is not enough to have a fully functional robotic hand. With only a position controller, to grasp any object without breaking it (or without risking damaging the hand), the approximate finger positions to grasp that object must be known beforehand. For example, to grasp a bottle, the hand must roughly know what are the positions of each finger to grasp that particular bottle. To grasp a ball, a different set of positions is needed, and so on for any other object. Thanks to the underactuation mechanism used in the mechanical design of Dextra, the exact positions are not needed, since the fingers can adapt to the shape of the grasped object. But it is obvious that it is not practical to have a preprogrammed set of grasps, because this set can be enormous and the task of programming each one can be very time consuming.

    For me, the solution to this problem is to use a force controller. In fact, I think the ideal solution would be to use a hybrid position-force controller. With the position controller, the fingers could be configured to adopt a preconfigured pose from a small set consisting of the main hand grasp types (in the robotics field this is known as pregrasping). From this pregrasp pose, the fingers would be commanded to close, and the final grasp would be controlled by the force controller. Thanks to the adaptive grip, the fingers would conform to the shape of the grasped object.

    But before working on hybrid controllers, I have to implement a force controller. The first question one asks when developing a closed-loop controller is, how do I measure the variable I want to control? In this case, where I want to control the force exerted by the fingers, the first answer that came to my mind was: force sensing resistors. FSRs are small and have a low profile, so its integration would not increase the volume of the robotic fingers, they are very easy to use (they are variable resistors) and they are moderately priced. The question is, how many sensors would each finger need? Just one on the fingertip? One per phalanx? Ideally, the best option is the second one, but this would increase the cost and complexity of the system. But even if only one sensor on the fingertip is used, there is another problem: wiring. Having sensors on the fingers implies wiring them up to the micrcontroller. Integrating cables into an articulated mechanism such as a finger has a certain complexity, but for me the biggest problem is that the assembly of the hand would be more complicated. And one of the main objectives of this project is precisely that the hand has to be easy to assemble.

    A while ago, a pair of colleagues from my university implemented a zero-gravity compensator for the arms of a humanoid robot. To measure the torque exerted by the motors, instead of using a force sensor, they modeled the motors and used their current consumption to get a torque estimation. I decided that this is a very suitable method for this project, because a single sensor can measure the total force exerted by one finger, and the sensors can be integrated into the control board along with the microcontroller and the rest of the components, without using wires.

    To begin testing this idea, I bought a Hall effect current sensor, the ACS712 (the model that measures up to 5 A). I printed and assembled a new finger module without soldering an encoder to the DC motor, since the feedback for the control loop is provided by the current sensor. With all the necessary elements, today I have set up the following test bench.

    I have decided to use a PID for the force controller, just like I have done with the position controller, so to get things moving I only have had to adapt the control code of the Dextra firmware. The results of the first force control tests can be seen in the video below.

    For a proof of concept, the results are not bad at all! I have had a couple of problems related to the current sensor. First,...

    Read more »

  • Myoelectric control system for Dextra

    Alvaro Villoslada10/02/2016 at 19:16 0 comments

    Today I have been working on the integration of the EMG control (using Mumai) with the latest version of Dextra. EMG control was already implemented in the first Dextra prototype, but it was not yet implemented in the current version of Dextra, the one that can be found here on and on its repo. In the following video, a demonstration of the implemented myoelectric control is shown.

    Developing version 1.0 of Dextra has been a lot of work (and there are still things that I would like to implement). Besides greatly modifying the mechanical design, a lot has been developed on the software side: a new firmware that includes closed-loop control, a serial communication protocol made from scratch, the control GUI... All this work delayed me on the integration of the EMG control, and it was something that had to be done as soon as possible, considering that the project started as an attempt to develop an open-source and low-cost myoelectric prosthesis. However, I could not implement the EMG control before finishing at least the new firmware and the communication protocol, since controlling the hand depends on how it works and how it receives the motion commands.

    So, how does the implemented myoelectric control system (MCS) work? First of all, the MCS runs on a separate microcontroller, not in the Teensy that runs the Dextra firmware. In the first Dextra prototype, both the hand controller and the MCS ran on the same microcontroller. But as I mentioned on the previous project log, the new firmware is quite more complex, with a bunch of interrupts firing here and there, so adding a MCS to the equation would probably make something not work properly, mainly because the EMG signal sampling also depends on a timer interrupt. Currently, the MCS is implemented on an Arduino Nano.

    EMG data is acquired with one Mumai circuit from the flexor digitorum profundus muscle on the forearm, which is in charge of flexing the fingers. The output of the EMG circuit is connected to one of the analog inputs of the Arduino to digitize it. The EMG signal bandwidth goes from 20 Hz to 500 Hz, so it has to be sampled at least at a 1 KHz rate. To this end, a function that reads the analog input is set to run every 1 ms using the MsTimer2 library. With this simple configuration, the raw EMG signal is acquired.

    The simplest form of EMG control, and the easiest to implement in a microcontroller, is the threshold-based MCS. These controllers compare the amplitude of the EMG signals with a predefined threshold. If the amplitude exceeds the threshold, a hand close command is generated, and if not exceeded, a hand open command is generated. However, a raw EMG signal, like the one in the image above, cannot be used in a threshold-based MCS; it has to be processed. This is why most "hacker-friendly" EMG circuits output only the amplitude of the signals, doing the signal processing (rectification and smoothing) on the hardware side, so they cannot be used to acquire raw EMG signals (which is quite useful depending on the application). For this reason, I designed a circuit that outputs the raw signals for a more general use, with which the signal processing is done on the software side.

    As the EMG circuit is powered with a 0-5 V supply voltage, the EMG signal is centered around 2 V, to measure the full range of the signal. In order to rectify the signal, first its baseline voltage has to be lowered to 0 V. On power-up, the first calibration step of the MCS, the zero level setting, is in charge of that. In this first mode, the user has his muscles at rest for 30 s. During this period of time the EMG signal is measured. With the muscles at rest, the acquired signal is just the baseline voltage. After this time, the average of the measured signal is calculated. The resulting value is subtracted for now on from all the values converted by the ADC, so that all new measurements are centered around 0 V.

    Now, rectifying the signal is just a matter of applying the abs() function...

    Read more »

  • Need for (microcontroller) speed

    Alvaro Villoslada10/01/2016 at 17:43 0 comments

    Why did I chose a Teensy 3.1 as the "brains" of Dextra? At the beginning of the project, when the fingers were open-loop controlled, I used an Arduino Uno to send the motion commands to the motor drivers. Once I had the mechanical design of the hand more or less finished, I decided that it was time to start working on closing the control loop.

    Since the fingers are underactuated, it didn't make much sense to put one angular sensor for each joint of the finger, as they cannot be independently controlled. So I thought that to close the control loop, I just needed to know the total linear displacement of the finger tendon. Instead of using a linear sensor, which would take a lot of space, I decided to measure the angular displacement (in radians) of the motor shaft with an encoder and transform this quantity into a linear displacement by multiplying it by the radius of the spool that winds and unwinds the tendon.

    Pololu sells small quadrature magnetic encoders for their micro motors, that can be directly soldered to the motor power pins, so choosing the sensor was easy. After researching how quadrature encoders work, and how to implement them with an Arduino (I have never worked with encoders before), I realized that I needed a microcontroller with at least five external pin interrupts (a quadrature encoder can use one or two interrupts, depending on if you want to have half or full resolution). An Arduino Uno only has two pin interrupts, so I took an Arduino Mega I had lying around and started developing the control firmware.

    After adjusting the PID gains and tweaking the code here and there, the first tests, where I moved only one finger at a time, went very well. But as soon as I started moving several fingers at the same time, the hand started to operate worse. After a few closing-opening cycles, some fingers closed more than commanded and others opened more than they should. To make an analogy with stepper motors, it was as if the motors were losing steps.

    To better understand what was going on, I will explain how the finger controller works (it is very simple actually). Basically it consists of two elements: the encoder counter and the actual control function. Every time one of the encoders generates a pulse, a function that increments or decrements the number of encoder "ticks" is executed. This is the only thing that this function does, to reduce its computational cost so it runs as fast as possible. The conversion from the number of encoder "ticks" to the linear displacement of the tendon is done in the PID function. The five PID loops that control the five fingers of Dextra are executed sequentially, from the thumb to the little finger, every 10 ms inside a timer interrupt (using the fantastic MsTimer2 library).

    So, what do we have here? A lot of interrupts. Being a timer interrupt, I know when the controller interrupt runs, but there is no way of knowing when the encoder interrupts are going to execute, or if they are blocking each other. Going back to the problem I had with the fingers not moving as they were commanded, I assumed that what was happening was that sometimes, for some fingers, the function that counts the pulses of the encoders was not executed. I thought this was happening because the speed of the microcontroller was not enough to run a counting function before the interrupt of another encoder was fired. My reasoning was as follows: if while the counting function of a finger is running the encoder of another finger triggers its interruption, the counting function of the second finger will not run because the counting function of the first finger is still running, and thus, the motor of the second finger will skip a pulse while it is moving, causing the finger to close or open more than it should.

    With that reasoning in mind, I switched to a Teensy 3.1 which has enough pin interrupts for my purposes, runs at 72 MHz (96 MHz if overclocked) and is Arduino-compatible. After making some small changes to the code and...

    Read more »

  • Madrid Mini Maker Faire 2016

    Alvaro Villoslada09/27/2016 at 14:33 0 comments

    This past weekend I've been at the Madrid Mini Maker Faire 2016 giving a talk about Dextra and showing it to the fair visitors. It was a lot of fun and it also served as a stress test for the hand; until now, it had not been running for such a long time. Thankfully everything worked as expected: the batteries had autonomy for the two days, the electronics worked flawlessly and no piece of the hand broke. So it seems that the design is quite robust, yay!

    Last week I worked like crazy to have some new features ready for the fair. Among other things, the palm and the back of the hand have undergone a major redesign to integrate a wrist with an embedded M10 screw, to make it compatible with the International Committee for the Red Cross’s (ICRC) transradial prosthetics manufacturing guidelines. I also designed a base to allow putting the hand in a vertical position. Thanks to this, now I can do grasping experiments in a much convenient way, and it also looks much better than having the hand lying on the table.

    To show what Dextra is capable of, I programmed a bunch of Python scripts to execute different motions as well as to perform some basic grasps. I've updated the videos on the project details to show how the last version of Dextra works. Below, there is a video (in Spanish) I prepared to show the main features of Dextra during the Maker Faire.

  • Control board prototype

    Alvaro Villoslada09/16/2016 at 17:58 0 comments

    This is the first prototype of the Dextra control board, which I've been testing today and works like a charm. Until now I have been working with all the components placed on a breadboard. The mess of wires was horrible, so I designed this very simple PCB containing a Teensy 3.1, the five DRV8838 motor drivers and a voltage regulator to lower the battery voltage to that required by the abduction servomotor. The Teensy board and the driver boards are inserted into a series of sockets to be able to replace the components in case something burns.

    The next step in the electronic part of the project is to start working with the current sensors to implement a force controller for the hand. Also, thinking on an easy way of controlling the hand when used as a prosthesis, I'm planning to use an accelerometer to switch between different grip patterns by moving the hand in different directions. In this way, the user would change the grip pattern by just moving the hand in one direction, and the grip would be activated by just contracting one muscle, using only one EMG sensor. I will detail this idea in depth in one of the next project logs.

    Once I have all this working, my plan is to integrate all these components in a control board that will be integrated inside the hand, with just three external connections: USB to program the hand, a connection for the EMG sensor (serial, SPI or I2C, I still have to decide) and the power connection (for a battery or a wall adapter power supply).

  • Development of the Dextra control GUI

    Alvaro Villoslada09/14/2016 at 17:02 0 comments

    Although this project focuses on its application as a prosthetic hand, Dextra is, after all, a robotic hand. By this I mean that it has no elements that make it specifically a prosthesis, so it can be used for other purposes. Especially, due to its open-source nature and the possibility of replicating it with a 3D printer, I think it has a great potential to be used in education and research.

    When I studied my master in robotics, we had a Shadow robotic hand in our lab, but I could never get to use it, because it was too expensive to risk a student breaking it. Although I understand this fear, for me it was something really frustrating. So, why not use robotic hands that are low-cost and easy to repair to let frustrated students, researchers and makers get their hands on a real device to do real experiments rather than perform boring and unrealistic simulations? With all this in mind, I thought it would be interesting to provide other means of controlling Dextra besides the EMG interface that controls the hand when it is used as a prosthesis. So one of the things I've been working on lately is a simple and intuitive graphical interface to control Dextra from a computer.

    It started as a simple Python script with which the desired positions could be sent to the hand microcontroller through the serial port one by one. This script was very useful for the first control tests and to check that the mechanics of the hand worked properly. It worked for me, but for a hypothetical future user it was too basic. Besides, the serial communication part could also be greatly improved, since each position was sent separately instead of sending all the positions at once in some kind of packaged format.

    Building on that basic interface, I developed a serial communication protocol called Synapse (which in turn is based on a serial communication protocol called seCo, which I'm developing to send arrays of floating point numbers in an efficient way). The protocol sends the position of each finger and of the abductor in a floating point format converted to binary format, each value with an identifier (something like a hex address). All these values are packed in a message delimited by a header and a footer and with a checksum to check the integrity of the transmitted message. Furthermore, it is possible to send values from the microcontroller to the computer following the same message format, to allow retrieving information from the hand sensors. I've also developed a Python module to be able to use this protocol on the PC side.

    But I still needed some kind of interface better than the original text interface. With no experience in designing GUIs, I needed something that was easy to learn and use, so I researched what are the options to design GUIs with Python (which is a great language to get things done quickly and easily, and with which I could integrate the communication protocol). I ended up using Kivy, which I found very appealing for being open-source and cross platform (it even runs on Android and iOS!). After a few days of learning and tinkering, I had a first version of the GUI finished.

    The first tab manages the connection with the serial device running the Dextra firmware. The second tab is the one that allows controlling the fingers. This can be done either by entering the desired value directly into a text box, moving a slider, or through small increments with the buttons next to the text boxes to adjust the position accurately.

    For the next version of the GUI, I'm planning to include a way of storing and reproducing different hand positions. In this way, it would be really easy to program the hand behaviour, and use these programmed gestures in different applications.

View all 11 project logs

  • 1
    Step 1

    This is a step-by-step visual guide to assemble a Dextra hand. Before starting the assembly, all the mechanical parts of Dextra should be printed. The .stl files are available on the files section, on its Github repository and on Thingiverse.

    These instructions are also available in .pdf format.

    NOTICE: these instructions are to assemble a Dextra hand v1.0. Future versions of Dextra may have different features with respect to this version and assembly steps may be different to the ones explained here.

  • 2
    Step 2

    These are all the components needed to assemble a Dextra hand:

    3D printed parts:

    • 4x finger module:
      • 4x motor_holder.
      • 4x proximal.
      • 4x middle.
      • 4x distal.
    • 1x thumb module:
      • 1x motor_holder_thumb.
      • 1x proximal_thumb.
      • 1x distal_thumb.
    • 5x spool.
    • 1x abductor.
    • 1x dorsal.
    • 1x palm.

    Other components:

    • 5x Pololu Micro Metal Gearmotor 1000:1 HP with extended motor shaft.
    • 5x Pololu magnetic encoder for Micro Metal Germotors.
    • 5x right angle female connector (2mm pitch).
    • 1x Turnigy TGY-EX5252MG Twin BB Digital Micro Servo.
    • 1x fishing line spool.
    • 14x small rubber bands (orthodontic elastic bands).
    • 14x M3x14 bolt.
    • 10x M3x8 bolt.
    • 2x M3x12 bolt.
    • 1x M3x6 bolt.
    • 2x M3x12 spacer.
    • 26x M3 nut.


    • 2.5 mm Allen key (for M3 bolts).
    • Phillips screwdriver (for servomotor bolts).
    • Needle file or sandpaper (to rework the 3D printed parts if needed).
    • Scissors (to cut the fishing line).
    • Soldering iron and solder.
  • 3
    Step 3

    Step 1 (actuator assembly):

    The first step is assembling the micro actuator that pulls and releases the tendons.

    To assemble one micro actuator we need:

    • 1x Pololu Micro Metal Gearmotor 1000:1 HP with extended motor shaft.
    • 1x Pololu magnetic encoder for Micro Metal Germotors.
    • 1x right angle female connector (2mm pitch).
    • 1x spool (printed part).

    First, we have to integrate the magnetic encoder into the micro motor. Solder the 2 mm pitch right angle connector to the encoder PCB. The pins have to be soldered on the side of the PCB that has text labels and no components, as the image above shows.

    The encoder has to be installed as in the pictures above. Put the encoder PCB on the back of the micro motor with the side that has no components facing the back side of the motor, and with the female pins facing the side of the motor opposite to the one that has a small gap in the gearbox.

    Using a PCB vise or something similar may help securing the motor and the encoder PCB to make soldering easier.

    Once the encoder PCB is soldered to the motor, gently push a magnetic disc onto the back shaft of the motor.Insert the motor shaft inside the spool. One side of the hole of the spool is flat and must match the flat side of the motor shaft. The hole is quite tight, so you may have to exert some force to have the spool fully inserted.

View all 7 instructions

Enjoy this project?



tyler palmgren wrote 09/21/2020 at 05:02 point

Hello! I love your design, but I'm having some trouble replicating it. I haven't worked with Teensy or with Pololu's products, so I'm a little lost on how to wire everything together. The documentation and images you posted are nice, but aren't super clear as to how to wire the Teensy to the motor carriers, and then the carriers to the motors. Would you mind sharing your circuit diagram so I could try to replicate it?

  Are you sure? yes | no

kalitajibon wrote 07/04/2020 at 06:54 point

hello.. i am from india ...actually I was willing to assemble the parts that you have given above (.stl files ) in solidworks ......but it is not happening because it's too meshy (since these are stl files ) can you please provide the solidwork part files of the parts

  Are you sure? yes | no

avaneeshritwik wrote 01/08/2019 at 00:22 point

"I decided to measure the angular displacement (in radians) of the motor shaft with an encoder and transform this quantity into a linear displacement by multiplying it by the radius of the spool that winds and unwinds the tendon." Kindly help, how does this give the linear distance? I am unable understand

  Are you sure? yes | no

Bhavesh Kakwani wrote 01/08/2019 at 19:45 point

s = r * θ is the formula you are looking for. Here, s is the linear distance, r is the radius and θ is the angle in radians. For example, for an angle of 360°, θ = 2π therefore s = 2π*r, the formula for the circumference of a circle that we know and love

  Are you sure? yes | no

avaneeshritwik wrote 01/08/2019 at 20:12 point

Ah! I got the concept, Thank you. But, how does one calibrate the linear distance to the corresponding distance moved by the fingers? and is there a way to mathematically model the joint displacements of the fingers for this type of single string tendon actuation?

  Are you sure? yes | no

Vamps wrote 11/22/2018 at 15:21 point

Hello. I'm hobbyist that tries to build this project of yours sir. This is so great by the way. However, may I ask some help from you as I am facing some problems while building this project. 

First, what kind of fishing line should I use so that it won't slip off the spool? Every time I tried to rotate the motors, the fingers won't completely close until a certain position rather it would go back in its opened position since my fishing line will slip off the top of the spool. Could there be a wrong step done while I am assembling the device?

Second, I would like to control the prosthetic using EMG.. however I have no idea what to do to set positions or default positions on the motors.. I can already position them when I close my fist, once it reached the value that I programmed the motors will stop rotating, however whenever I open my fist it does not seem to go back to its original position.

I'm sorry if this is too much to ask. I really hope you could help me sir, thank you!

  Are you sure? yes | no


[this comment has been deleted]

Alvaro Villoslada wrote 09/26/2018 at 10:14 point

Well, the 1000:1 motor is used for a reason: it was the only micro motor that provided enough torque to achieve a firm grip with the hand. With the motor you have bought, you could try to use softer rubber bands to reduce the force opposing to finger flexion. From what you are saying, it seems that the 100:1 motor doesn't provide enough force to overcome the force of the elastic bands, and that's why your finger doesn't move. If you can make it work, your hand is going to have a really weak grip.

In any case, the parts where the motors are housed (motor_holder.stl and motor_holder_thumb.stl) are designed to fit the 1000:1 motors, which have a longer gearbox and body than the other Pololu micromotors. That's why, in the component list, it specifically states that 1000:1 motors are used and not another model.

  Are you sure? yes | no

Georgie wrote 08/28/2018 at 10:29 point

Hello. May I know the use and importance of the magnetic encoders in the project? Sorry. It's my first time using them.

  Are you sure? yes | no

Alvaro Villoslada wrote 08/28/2018 at 14:37 point

Without them, you wouldn't be able to control the position of the fingers! :D

The magnetic encoders are used in this project as position sensors; by counting the number of times the rotor of the DC motor rotates one full turn, we can know the angular position of the output shaft of the motor (which rotates 1000 times less than its rotor due to the gearbox). This position is used as a feedback signal in a PID controller, which is responsible for, depending on the desired finger position, moving the finger (by generating a control signal for the motor) until the difference between the desired and the actual position is 0.

If you have ever used a commercial servomotor, you have used exactly what I've explained. Servomotors consist of a DC motor with gearbox, an encoder (usually a potentiometer) and some electronics in which the PID controller is implemented. What I have done in this project is basically a custom-made servomotor.

Info about PID controllers:

  Are you sure? yes | no


[this comment has been deleted]

Alvaro Villoslada wrote 08/27/2018 at 12:44 point

You can find the stand and all the modified parts in the GitHub repo, in the "develop" branch:

I haven't updated those parts here because the assembly instructions correspond to the previous version of the hand and, until I update the instructions, I don't want to upload the new parts, to avoid confusion (although I have to admit it's a bit confusing to see a different version of the hand in the photos than the one available here for download).

  Are you sure? yes | no

eturner303 wrote 01/07/2019 at 22:37 point

Hi Alvaro, thanks so much for making this project available!  Regarding the STL files on your Github repository -- can you indicate which parts have changed to facilitate the hand?  Is it only the wrist/etc?  I have already printed/built fingers, but they were the original STL files on hackaday before the stand was introduced.  I'm attempting to determine if i need to re-make the fingers if I want to incorporate a stand into my hand, or just the wrist/other parts?  Any information would be greatly appreciated, and thanks again for this project!

  Are you sure? yes | no

mireya_421993 wrote 08/17/2018 at 01:17 point

1Buenas noches, muchas gracias por su respuesta respecto a la batería, me ha servido de mucho, aun no logro el correcto control de la posición, por favor podría enseñarme como tomar los parámetros: K,P,I del controlador PID, no tengo el modelo  matemático o función de transferencia del motor con el encoder de cuadratura.

  Are you sure? yes | no

Alvaro Villoslada wrote 08/21/2018 at 07:53 point

Lo cierto es que no he usado ninguna de las técnicas de ajuste de PID que se enseñan en los libros de texto; fue un proceso más bien experimental en el que iba probando distintos valores de ganancia hasta obtener una respuesta aceptable.

Realmente con estos motores, que tienen un factor de reducción tan grande, no es necesario un control PID completo. Un control proporcional (es decir, con Kd = 0 y Ki = 0) es suficiente para conseguir una respuesta aceptable. En realidad, tiene oscilaciones en el eje del motor en el que está colocado el encoder, pero la reducción absorbe esa oscilación y apenas se nota a la salida del motor.

De todas formas, es raro que el control no funcione bien del todo; se supone que si ha usado los mismos componentes (electrónica, motores...) debería funcionar bien con los parámetros por defecto.

  Are you sure? yes | no

Georgie wrote 08/15/2018 at 07:01 point

Hi Sir! Do you happen to have the left hand version of this? thank you :)

  Are you sure? yes | no

Georgie wrote 08/16/2018 at 13:35 point

and what are the use of the DRV8838 Single Brushed DC Motor Driver Carrier? Can they be used in a 100:1 gear motors and not the 1000:1 ratio? ..

I'm sorry I'm such a beginner.

  Are you sure? yes | no

Alvaro Villoslada wrote 08/21/2018 at 07:38 point

The DRV8838 is an H-bridge driver for small DC motors, such as the ones used in this project (and yes, you can use it with 100:1 motors). An H-bridge is a component that basically delivers the current needed to power and move the DC motor, and it can reverse the flow of that current, allowing the motor to turn in both directions.

  Are you sure? yes | no

Alvaro Villoslada wrote 08/21/2018 at 07:34 point

I don't have a left hand version, but it is really easy to print one. You just have to print mirrored versions of the dorsal and palm parts. Any slicing software or 3D printer graphical interface (Cura, Repetier Host) will allow you to print mirrored versions of any .stl file.

  Are you sure? yes | no

mireya_421993 wrote 07/11/2018 at 19:48 point

Excelente proyecto, por favor podría indicarme el modelo de batería que usa para alimentar los pines marcado como Vbatt, en el diagrama que se encuentra en dextra_control_board.pdf, de antemano gracias

  Are you sure? yes | no

Alvaro Villoslada wrote 07/31/2018 at 10:31 point

¡Gracias Mireya! El requisito de tensión es de 6V, que es la alimentación de los motores, así que puedes usar cualquier batería que te de esa tensión. En mi caso uso una batería LiPo de dos celdas y 5000 mAh de capacidad, que me da una tensión de 7.4V. Como soy un poco bruto, esa tensión va directamente a los motores (que según su hoja de características deberían alimentarse a un máximo de 6V). Así consigo más velocidad de giro, pero probablemente reduzca algo su vida útil. Podría usarse un regulador de tensión que reduzca esos 7.4V a los 6V requeridos, pero tienes que elegir uno que sea capaz de dar toda la corriente que van a necesitar los motores en el peor de los casos (los 5 motores activos consumiendo el máximo de corriente, que son 1.6A por motor si no recuerdo mal).

  Are you sure? yes | no

lardot wrote 08/13/2017 at 16:33 point

I am building a similar but simpler prosthetic hand that I intend to open source when I am happy with it. I am using the same motors and encoders as the ones that you chose and was wondering if you would be willing to share the encoder code you are using. I have been a long time in mfg. but I am new to programming and it is a bit of a struggle so far. I like the work you have done on your hand.

  Are you sure? yes | no

Alvaro Villoslada wrote 03/12/2018 at 15:04 point

Hi! You can find all the code (including the encoder part) in the compressed file in the "Files" section. Sorry for the late response!

  Are you sure? yes | no

avaneeshritwik wrote 06/17/2017 at 03:44 point

Hi, Could I use 298:1 instead of 1000:1 motor?, because I can't find the motor you have used in my country

  Are you sure? yes | no

Alvaro Villoslada wrote 03/12/2018 at 15:26 point

Hi! You can use that motor, but you'll have to modify the "motor_holder_thumb" part, because the 1000:1 motor is longer than the other Pololu micro motors. You can find the source file of that part in the compressed file "" in the files section. Parts are designed with FreeCAD.

Anyway, you should know that I've tested the 298:1 motors and the torque they generate is not enough to have a firm grasp with the hand. That's why I opted for the 1000:1 ones.

Sorry for the late response!

  Are you sure? yes | no

Udo wrote 05/30/2017 at 20:49 point

I have completed most of the hardware required for the project per the instructions


However am at a loss on how to wire the controller

.In the original a printed circuit board is used. I seem to have no access to that hardware.

So I am trying to use a project Board.

I am a hobbyist with little electrical background, can you help.

  Are you sure? yes | no

Alvaro Villoslada wrote 03/12/2018 at 16:00 point

I've sent you a PM.

  Are you sure? yes | no

Udo wrote 05/30/2017 at 20:47 point

Can you send me schematic and or CAD(.dxf) file of your ciruit board?

  Are you sure? yes | no

koshand wrote 05/02/2017 at 09:27 point

this is really awesome project. I want to build the Hand. Where I can buy the Servo Motor? Can I use the engine?

  Are you sure? yes | no

Alvaro Villoslada wrote 05/03/2017 at 08:37 point

Yes! You can use that model for the abduction servo, it has the same dimensions than the one I used. In fact, I think the only difference is that the TGY-EX5251 uses plastic gears instead of metal gears, but aside from that, is the exact same motor. If you have any more doubts when building the hand, don't hesitate to ask them here, I will be pleased to help you!

  Are you sure? yes | no

koshand wrote 05/09/2017 at 07:20 point

Thank you, I've ordered the Corona DS-843MG servo. 

  Are you sure? yes | no

Germán Diez Marina wrote 02/10/2017 at 23:40 point

hi there, im in college and we are trying to recreate the hand but using mioelectrical sensors (directly by the arm muscles) but the srews M3x14 are very difficult to find, can you pass me the link or where can we find the screws?

  Are you sure? yes | no

koreaphj91 wrote 02/08/2017 at 01:31 point

Hi!! This is really awesome project~!

I wanna modified "motor holder.stl", but as you know, the *.stl file is not perpectly modified....
So I need .*stp files about your prothetic robot hand. 

Would you give a these files?? 

  Are you sure? yes | no

Alvaro Villoslada wrote 02/22/2017 at 11:48 point

Hi, and thanks for your interest!

On the files section ( and also on the project repository hosted on Github (, you can find the source files of all the mechanical parts of Dextra. They are designed with FreeCAD, which is an open source CAD program you can download for free. I think FreeCAD allows you to export the designs in step format, so you could give it a try!

  Are you sure? yes | no

it's me wrote 12/03/2016 at 09:15 point

Hi, Can you define the dimensions of motor holder to finger & to thumb, please?

  Are you sure? yes | no

Alvaro Villoslada wrote 02/22/2017 at 11:55 point

I'm so sorry, but I don't understand your question. What dimensions do you need exactly? From which point of the motor holder to which point of the finger?

The source files of the mechanical parts of Dextra can be downloaded from the files section ( and are also hosted on Github ( You can open them with FreeCAD, which includes a measuring tool.

  Are you sure? yes | no

Domen wrote 10/16/2016 at 07:32 point

Hi! This is a great project! Well documented and presented, you did a wonderful job!

One thing about the motors tho. Why not buy them from ebay? They cost 11 dollars and have the encoder included! See for yourself:

  Are you sure? yes | no

Alvaro Villoslada wrote 02/22/2017 at 11:51 point

Hi! Thanks for your comment!!

Yeah, I was aware of those micromotors with integrated encoder, but the torque they generate is not enough to have a firm grasp with the hand. I couldn't find any micromotor with a 1000:1 gear ratio and integrated encoder, that's why I had to integrate the encoders myself.

  Are you sure? yes | no

rickshoenbrg2 wrote 07/20/2016 at 03:06 point

or memory wire (nichrome)

  Are you sure? yes | no

Alvaro Villoslada wrote 07/25/2016 at 17:21 point

That is an interesting alternative. In fact, a while ago I integrated some flexible SMA actuators designed by me into an InMoov hand, and it worked quite well. There is a paper with more details.

The problems with SMA wires are basically speed and power consumption. SMAs are not very efficient, and being thermal actuators, they are quite slow (although there are several ways to improve this). For a robotic prosthesis where autonomy matters and speed is important to some extent, I'm not sure if SMAs would be a better alternative, although I would be delighted to see a fork of the design actuated with SMAs, or by any other form of actuation.

  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