Open-source hand exoskeleton that reads all twelve finger joints and drives them through tendons. Motion capture, teleoperation and haptics research. Everything to build one: CAD, KiCad PCBs, Teensy firmware, live 3D twin, BOM, embedded EMG channels.
See the code
TAKTO ONE is an open-source hand exoskeleton: it reads twelve finger joints at the joint itself and pulls them back through tendons, with the control loop on the device, not on a laptop. Wear it and your hand becomes an instrument: every motion measured, recorded, and answered with force. This repository is every file needed to build one.
The device in 360°, the live digital twin and the console. No hardware needed.
Recorded through a Quest headset. Nothing from the headset moves the twin's fingers: the twelve encoders bend them and the two IMUs turn the wrist. The web twin runs on the monitor behind. The AR layer is a prototype.
takto.one is the official home of TAKTO ONE, and its source is
software/web/ in this repository. One scrolling page: the device in three
finishes, the six parts that make it, the numbers behind it, a full 360° turn, and the live twin
and operator console, all in the browser and none of it needing hardware. Without a device the
console runs a clearly labelled simulation; it talks to a real TAKTO ONE only on your own
machine, and only when you connect it.
The main page. Pick a finish, scroll through the parts and the numbers, turn it through 360°.
The console. The whole arm in space with the twin's fingers closing and opening, the twelve encoder channels, the motors and the effort gauge, here on the built-in simulation (top right: SIMULATED DATA). Connect a real TAKTO ONE on your own machine and the same view runs live.
node software/web/tools/build-site.mjs <outDir> bundles, minifies and
hashes the site into a folder any static host can serve (it uses esbuild, or fetches it with
npx).
Your hand is the highest-bandwidth interface you own, and machines still read it badly. A camera loses fingers the moment they cross, curl, or leave frame. A glove full of flex sensors drifts. TAKTO ONE puts a magnetic encoder on the joint itself, three per finger, twelve in all, so the measurement ignores occlusion, lighting, and where you happen to stand. And because the microcontroller owns the motor bus, the device acts without a computer in the loop.
Per-joint truth going in, tendon force coming out, no host required. It is a hand-shaped input and output device, and what you point it at is up to you.
On the arm: the black build, filmed with a phone on 14 October 2026.
Two of the most useful things a hand platform can do are built and in this repository.
Motion capture that writes to the device, not to a browser. The firmware logs to the Teensy's own SD card, one row per frame: all fourteen encoder channels, the hand, forearm and thumb quaternions, EMG envelope and RMS, the crown, and full motor telemetry. One sensor acquisition feeds the SD row, the serial stream and the display, so the log and the live view can never disagree. The rate is a firmware constant, not a display refresh. The result is serious hand-motion data: per-joint, occlusion-free, timestamped, labelled by physics instead of by another model's guess.
Teleoperation and assistance. The control law runs on the Teensy in three modes: idle, direct current, and a blend that moves continuously between transparent, where the device follows the wearer and stays out of the way, and assist, where it drives toward a setpoint. The blend is a live parameter, so the hand can lead the device, the device can lead the hand, or anything in between. Setpoints, gains and current limits are all exposed over the serial protocol, which is what lets one hand drive another.
Together they close the loop that matters: read a hand precisely, record it, and play it back into a hand.
Designed from scratch in KiCad for this device and published in full: schematic, layout and
manufacturing outputs for each board are in electronics/. The renders come
straight from those files.
 |  |
| Palm carrier | Encoder board |
palm_carrier/). Shaped to the curved palm plate. Two TCA9548A I²C
multiplexers fan the bus out to fourteen encoder channels: twelve joints, plus two reserved
for a thumb.encoder_board/), one per joint. An AS5600 magnetic angle sensor centred
under a through-board aperture, so the joint's magnet sits on the sensor's axis.Both were fabricated and assembled in one JLCPCB order (June 2026, USD 170.73 delivered),
itemised in the bill of materials.
One known erratum, documented rather than hidden: on the palm carrier the second multiplexer's
SDA and SCL net labels are swapped on channels 8 to 13, so those six channels are wired
crossed. electronics/README.md has the detail. The 74HC241 servo-bus
interface is separate from these boards; its pins are in the firmware and in the wiring below.
Sensing → aggregation → control → interface:
And the full point-to-point wiring: every pin terminated, both I²C multiplexers, all fourteen encoder channels, all three IMU positions, and the 74HC241 servo bus. The PDF is the printable version.
Record a hand once and it replays anywhere the twin runs. The viewer rebuilds the session as a 4D scene: the real device GLB articulated by the twelve recorded joint angles, the wrist flying the 6-DoF path the headset measured, the room drawn from the environment mesh stored with the take, and the flexion and effort traces under the scrubber. Any speed, any angle, forever.
take_demo_signature, played at 2× in the shipped viewer. One of three sample takes
in software/bridge/samples/ — choreographed, synthetic, and
generated by a script that ships beside them. Three commands and this plays on your machine
with no hardware.
The format is the same one the device writes to its SD card, so your own recordings drop straight in. The environment store is wired end to end, but dense room reconstruction from the Quest 3S is still open work: the viewer, the store and the upload path are all waiting for it, and putting a real scanned room behind these trajectories is one of the most satisfying contributions this project has to offer. See Contributing.
Source included: software/ar/
A spatial layer that puts the hand twin and its data into the room instead of on a monitor. It reads the same WebSocket stream as the console, needs no separate backend, and runs in a plain browser on the desktop, which is how the frames below were captured. Through a headset it looks like this recording from October 2026.
Running live in the desktop preview: twin, the articulated hand driven by joint angles and seen from a moving viewpoint · touch, objects that answer the wearer's fingers · atelier, the hub, where the four modes are objects you reach toward rather than buttons. Butterflies drift through every one of them.
Five modes ship: atelier as the hub, plus twin, touch, rhythm and capture. The scene
carries the device's own geometry, so what you reach toward is the machine on your arm. It is
also inhabited: butterflies wander the room, settle on the desk edge to rest their wings, and
lift off again, and rare comets cross the upper air. None of it competes with the work; it just
means the space is alive while you are in it.
Prototype, captured on the desktop preview rather than in a headset. Known high-DPI bug: the render target is sized from CSS pixels while the canvas backs at the device ratio, so on a 2x display the scene draws into a quarter of the canvas. Force a device pixel ratio of 1 as a workaround; fixing it properly is a good first contribution.
Source included: software/app/
A pocket instrument for the times the laptop is not the right one: watch the twin, replay a recorded session, and read the twelve joints and the activation channel, from the same stream and protocol as everything else here. One Expo codebase for iOS, Android and the browser.
Overview, the device at a glance · Analytics, the twelve joints and the activation channel · Logs, the source, the bundled sessions and the rates
The travelling wave, index to pinky, on the synthetic feed. Twelve joints driven independently, and all three surfaces pinned to the same clock: one instant of the app, not three screens shot at three different moments.
The twin is the real CAD driven by the shared mechanical model in
kinematics.js: the angles, the telescopic slides those
angles demand, and the spool rotations that produce them. It runs with no hardware at all on
the same synthetic feed as every other surface, and the three bundled sessions are the
repository's own sample takes. Point it at a bridge and it reads a real device.
An earlier Android-only build is superseded by this one; its emulator captures are gone from this page.
The Teensy drives a round display, and the face engine that paints it is part of the firmware. One face ships, thesis, in three colourways (Sapphire Depth, Graphite and Amber), and it covers every device state: battery, boot, calibrate, fault, idle, linked, recording, saved, standalone, stop and teleop. Two earlier design studies, rams and ferro, stay in the source for reference; they are not built into the firmware.
None of these are static screens. Every face animates: boot sweeps and self-tests, the teleop ring tracking assist, the recording counter and its take meter, idle breathing while nothing is happening. The engine runs a dirty-tile renderer inside a fixed frame budget, so the paint never starves the control tick.
Faces rendered by the firmware's own rasterizer from a mock feed and played at the speed they were authored: the boot sequence of the shipping thesis face and of the two studies, then recording counting a take up, and idle breathing.
The shipping face and the two studies against every state. These are renders, not photographs of the physical screen.
The thesis face is the one the firmware builds. Source, the face engine, the frame budget
and the flashing runbook are in
firmware/takto_one/watch/.
Most hand devices sense position. TAKTO ONE also listens to the muscles.
The front end is a MyoWare 2.0 muscle sensor on a standard three-lead setup: two electrodes along the target muscle belly and one reference on electrically quiet tissue, a nearby bone or joint. The board does the analogue work — differential amplification of the two muscle leads against the reference, rectification and envelope detection — and hands the firmware a clean envelope on pin 14. The device carries the Ag/AgCl snap interface for it, so it takes the same disposable gel electrodes used for ECG and EMG in clinical and lab work: skin contact costs cents, not a custom part, and anyone can replace a pad mid-session.
The firmware oversamples that envelope at roughly 1 kHz between 50 Hz frames, reduces it to a mean envelope plus RMS, and writes both into every frame of the stream and every row of the SD log — on the same clock as the twelve encoders and the IMUs.
That single time base is the point. Encoders say what the hand did, IMUs say how it moved through space, and EMG says what the wearer intended, fractions of a second before the joints follow. Three signals, one clock: training data for models that learn intent, and a third input for whoever builds the next control layer. The operator console and the public front end both draw the live effort channel.
Simulation, from the project's intent-fusion research on a documented synthetic signal model: in a stick-slip scenario the encoder-only observer takes 172 ms to engage assist; fusing the activation channel cuts that to 12 ms, inside an energy-budgeted control law that provably cannot drive motion on its own. Not a measurement on a person.
Behind that figure sits a research track in the wider project, not in this release: a causal acquisition pipeline (band-pass, notch, RMS envelope), a whitened Bayesian decoder, and an energy-tank shared-control law where activation leads the encoder during isometric loading while a passivity certificate guarantees it can never self-drive the joint. Developed and validated against a documented synthetic signal model with reproducible pass reports, and stated as exactly that: signal-processing and control research, ready for hardware trials, not claims about human experiments. If multi-source intent detection is your field, this device was built to be your testbed.
The clearest proof that this is a platform is TAKTO-SIGN: a German Sign Language capture,
training and live-recognition stack built on exactly this hardware. It records finger bend and
hand orientation at 60 Hz, learns a designed vocabulary, and recognises signs live. Like
everything else here, it runs end to end with no hardware through --sim.
Its scope statement is worth repeating because it is the right way to talk about work like this: a signer-dependent isolated-sign recogniser with a continuous scripted-sentence path and a measured cross-signer result. It is not open-vocabulary translation.
One application, built by one person, on this platform. An example of what the hardware supports, not the limit of it.
Read every finger and drive every finger, and a whole class of problems opens up. These are directions, not delivered features; each is a project of its own, and open-sourcing the platform is how they happen in parallel instead of one at a time. Every one of them starts from the files already in this repository.
Current status is stated plainly in Where the project really stands.
| Mechanism | Tendon-driven, four instrumented long-finger assemblies |
| Actuation | Series-elastic, through elastic tendons and ratchet-based spools |
| Joint sensing | 12 × AS5600 magnetic encoders, 3 per finger |
| EMG | Embedded Ag/AgCl electrode interface for standard snap gel electrodes; envelope + RMS in every frame |
| Controller | Teensy 4.1 |
| Motor bus | Dynamixel Protocol 2.0 over a 74HC241 half-duplex interface, the microcontroller owns the bus; no host PC required |
| Electronics | 2 custom PCBs, full KiCad sources + manufacturing outputs |
| Interface | Browser operator console with a live 3D twin, over a serial→WebSocket bridge |
| Structure | 3D printed; as built, a mix of PETG and PLA |
| Parts | 71 printed parts, 8 servos, 12 encoder boards as designed. Full bill of materials |
Eight motors, twelve instrumented joints, seventy-one printed parts. The servos are nearly the whole bill; every other group put together is under a fifth of it, which is why cutting the motor count is the most useful thing anyone could contribute.
Part numbers, suppliers, quantities and the caveats are in docs/BOM.md,
with a machine-readable copy in docs/bom.csv.
Clone to a moving hand in under a minute: the console opens in simulation, so you can explore the whole stack before you print a single part. (No clone needed just to look around: takto.one runs the same twin and console in your browser.)
git clone https://github.com/molanocortes/takto-one.git
cd takto-one
# see the console and 3D twin immediately, no hardware needed
python3 -m http.server 8096 --directory software/console/app
# open http://localhost:8096/
Then read docs/README.md: system architecture, the illustrated build
guide, and the known corrections between the documentation and the current hardware.
| Step | Where |
|---|---|
| Source the parts | docs/BOM.md |
| Choose and print parts | cad/README.md |
| Order and wire the boards | electronics/README.md |
| Flash the Teensy | firmware/README.md |
| Connect the twin to hardware | software/README.md |
The embedded Dynamixel driver is also maintained standalone as dynamixel-on-device.
Precision here matters more than a longer feature list.
Verified on hardware. The firmware runs on the device. The Teensy owns the Dynamixel bus through the 74HC241 and drives one finger with two XC330 servos: motor-controlled finger movement was demonstrated and tested on the bench, with the transmission run both with and without its elastic element in series. The full design takes eight servos; the other six are not fitted yet. All twelve magnetic encoders have read live together on the worn device and fed the browser twin in real time. Two BNO085 IMUs are fitted, on the hand and the forearm. Four long-finger assemblies are built and instrumented, and both PCBs exist as manufactured designs with complete sources.
On the bench today (October 2026). After a wiring fault, four encoder channels (00, 04, 05 and 11: the middle finger and the ring finger's abduction) answer nothing on I²C, so eight of the twelve joints read live until the harness is repaired. The fault is in the wiring, not the firmware.
The firmware and the wiring carry a third IMU channel for a thumb-tip unit that is not
fitted, in the same way the two multiplexers carry fourteen encoder channels for twelve
populated encoders. The unfitted channel reports MISSING in the s bus scan, streams a live
flag of zero, and logs an identity quaternion, so nothing downstream mistakes it for data.
Not established by this repository. Force rendering, transparency control, and assistance behavior are not characterized by measurements here. Verify the actuator count, limits, and safety behavior on your own hardware before any worn experiment. Repository-preparation checks are in the verification record.
Known limitations. Eight motors makes this an expensive build. The series-elastic actuation is a simple implementation, elastic tendons and ratchet spools, not an advanced SEA design. Recent soft-robotics work achieves comparable sensing with simpler mechanisms. This is a working, well-instrumented research platform, not a claim to the state of the art, and those gaps are exactly where contributions help most.
Loop rate, sampling rate, telemetry rate and console update rate are four different numbers; collapsing them into one is the easiest way to mislead someone.
SAMPLE_HZ in the sketch in this release, the
serial-line rate. The development firmware, not yet released here, streams 100 Hz; that is
the figure on takto.one.The ceiling on encoder sampling is set by the I²C bus and multiplexer switching, and it has not been characterised here. If your application depends on a specific rate, measure it on your own build.
TAKTO ONE is an experimental research prototype. It is not a medical device and not a certified protective product. Do not use it for diagnosis, treatment, unsupervised rehabilitation, or safety-critical operation.
Keep actuator power independently removable, begin with torque disabled, test away from the body, confirm mechanical limits, and validate watchdog and fault behavior before any worn experiment.
This project is under active development and contributions are genuinely wanted. The limitations above are not fine print; they are the to-do list, and some of the most interesting problems are still unclaimed.
docs/README.md; find more.See CONTRIBUTING.md. Open an issue with questions, ideas, or photos of
your build; showing what you made is always welcome. For anything that does not belong in a
public issue, write to sebastianmolano.eng@gmail.com.
Software Apache-2.0 · Hardware CERN-OHL-S-2.0 · Documentation and media CC-BY-4.0.
Full detail, attribution format, and the text-and-data-mining reservation: LICENSE.md.
The hardware licence is strongly reciprocal: distribute a modified design and you publish your
modifications. If that does not suit your situation, licensing on other terms is available,
see LICENSE.md. Contributors are asked to agree to a short CLA, which
keeps relicensing possible and leaves your copyright with you.
TAKTO and TAKTO ONE are trademarks of Sebastian Molano, asserted as unregistered marks and
not covered by any licence above. Build it, change it, sell it, and say it is based on TAKTO
ONE; just give your own version its own name. Details in LICENSE.md.
Open-source hand exoskeleton that reads all twelve finger joints and drives them through tendons. Motion capture, teleoperation and haptics research. Everything to build one: CAD, KiCad PCBs, Teensy firmware, live 3D twin, BOM, embedded EMG channels.
See the code
TAKTO ONE is an open-source hand exoskeleton: it reads twelve finger joints at the joint itself and pulls them back through tendons, with the control loop on the device, not on a laptop. Wear it and your hand becomes an instrument: every motion measured, recorded, and answered with force. This repository is every file needed to build one.
The device in 360°, the live digital twin and the console. No hardware needed.
Recorded through a Quest headset. Nothing from the headset moves the twin's fingers: the twelve encoders bend them and the two IMUs turn the wrist. The web twin runs on the monitor behind. The AR layer is a prototype.
takto.one is the official home of TAKTO ONE, and its source is
software/web/ in this repository. One scrolling page: the device in three
finishes, the six parts that make it, the numbers behind it, a full 360° turn, and the live twin
and operator console, all in the browser and none of it needing hardware. Without a device the
console runs a clearly labelled simulation; it talks to a real TAKTO ONE only on your own
machine, and only when you connect it.
The main page. Pick a finish, scroll through the parts and the numbers, turn it through 360°.
The console. The whole arm in space with the twin's fingers closing and opening, the twelve encoder channels, the motors and the effort gauge, here on the built-in simulation (top right: SIMULATED DATA). Connect a real TAKTO ONE on your own machine and the same view runs live.
node software/web/tools/build-site.mjs <outDir> bundles, minifies and
hashes the site into a folder any static host can serve (it uses esbuild, or fetches it with
npx).
Your hand is the highest-bandwidth interface you own, and machines still read it badly. A camera loses fingers the moment they cross, curl, or leave frame. A glove full of flex sensors drifts. TAKTO ONE puts a magnetic encoder on the joint itself, three per finger, twelve in all, so the measurement ignores occlusion, lighting, and where you happen to stand. And because the microcontroller owns the motor bus, the device acts without a computer in the loop.
Per-joint truth going in, tendon force coming out, no host required. It is a hand-shaped input and output device, and what you point it at is up to you.
On the arm: the black build, filmed with a phone on 14 October 2026.
Two of the most useful things a hand platform can do are built and in this repository.
Motion capture that writes to the device, not to a browser. The firmware logs to the Teensy's own SD card, one row per frame: all fourteen encoder channels, the hand, forearm and thumb quaternions, EMG envelope and RMS, the crown, and full motor telemetry. One sensor acquisition feeds the SD row, the serial stream and the display, so the log and the live view can never disagree. The rate is a firmware constant, not a display refresh. The result is serious hand-motion data: per-joint, occlusion-free, timestamped, labelled by physics instead of by another model's guess.
Teleoperation and assistance. The control law runs on the Teensy in three modes: idle, direct current, and a blend that moves continuously between transparent, where the device follows the wearer and stays out of the way, and assist, where it drives toward a setpoint. The blend is a live parameter, so the hand can lead the device, the device can lead the hand, or anything in between. Setpoints, gains and current limits are all exposed over the serial protocol, which is what lets one hand drive another.
Together they close the loop that matters: read a hand precisely, record it, and play it back into a hand.
Designed from scratch in KiCad for this device and published in full: schematic, layout and
manufacturing outputs for each board are in electronics/. The renders come
straight from those files.
| |
| Palm carrier | Encoder board |
palm_carrier/). Shaped to the curved palm plate. Two TCA9548A I²C
multiplexers fan the bus out to fourteen encoder channels: twelve joints, plus two reserved
for a thumb.encoder_board/), one per joint. An AS5600 magnetic angle sensor centred
under a through-board aperture, so the joint's magnet sits on the sensor's axis.Both were fabricated and assembled in one JLCPCB order (June 2026, USD 170.73 delivered),
itemised in the bill of materials.
One known erratum, documented rather than hidden: on the palm carrier the second multiplexer's
SDA and SCL net labels are swapped on channels 8 to 13, so those six channels are wired
crossed. electronics/README.md has the detail. The 74HC241 servo-bus
interface is separate from these boards; its pins are in the firmware and in the wiring below.
Sensing → aggregation → control → interface:
And the full point-to-point wiring: every pin terminated, both I²C multiplexers, all fourteen encoder channels, all three IMU positions, and the 74HC241 servo bus. The PDF is the printable version.
Record a hand once and it replays anywhere the twin runs. The viewer rebuilds the session as a 4D scene: the real device GLB articulated by the twelve recorded joint angles, the wrist flying the 6-DoF path the headset measured, the room drawn from the environment mesh stored with the take, and the flexion and effort traces under the scrubber. Any speed, any angle, forever.
take_demo_signature, played at 2× in the shipped viewer. One of three sample takes
in software/bridge/samples/ — choreographed, synthetic, and
generated by a script that ships beside them. Three commands and this plays on your machine
with no hardware.
The format is the same one the device writes to its SD card, so your own recordings drop straight in. The environment store is wired end to end, but dense room reconstruction from the Quest 3S is still open work: the viewer, the store and the upload path are all waiting for it, and putting a real scanned room behind these trajectories is one of the most satisfying contributions this project has to offer. See Contributing.
Source included: software/ar/
A spatial layer that puts the hand twin and its data into the room instead of on a monitor. It reads the same WebSocket stream as the console, needs no separate backend, and runs in a plain browser on the desktop, which is how the frames below were captured. Through a headset it looks like this recording from October 2026.
Running live in the desktop preview: twin, the articulated hand driven by joint angles and seen from a moving viewpoint · touch, objects that answer the wearer's fingers · atelier, the hub, where the four modes are objects you reach toward rather than buttons. Butterflies drift through every one of them.
Five modes ship: atelier as the hub, plus twin, touch, rhythm and capture. The scene
carries the device's own geometry, so what you reach toward is the machine on your arm. It is
also inhabited: butterflies wander the room, settle on the desk edge to rest their wings, and
lift off again, and rare comets cross the upper air. None of it competes with the work; it just
means the space is alive while you are in it.
Prototype, captured on the desktop preview rather than in a headset. Known high-DPI bug: the render target is sized from CSS pixels while the canvas backs at the device ratio, so on a 2x display the scene draws into a quarter of the canvas. Force a device pixel ratio of 1 as a workaround; fixing it properly is a good first contribution.
Source included: software/app/
A pocket instrument for the times the laptop is not the right one: watch the twin, replay a recorded session, and read the twelve joints and the activation channel, from the same stream and protocol as everything else here. One Expo codebase for iOS, Android and the browser.
Overview, the device at a glance · Analytics, the twelve joints and the activation channel · Logs, the source, the bundled sessions and the rates
The travelling wave, index to pinky, on the synthetic feed. Twelve joints driven independently, and all three surfaces pinned to the same clock: one instant of the app, not three screens shot at three different moments.
The twin is the real CAD driven by the shared mechanical model in
kinematics.js: the angles, the telescopic slides those
angles demand, and the spool rotations that produce them. It runs with no hardware at all on
the same synthetic feed as every other surface, and the three bundled sessions are the
repository's own sample takes. Point it at a bridge and it reads a real device.
An earlier Android-only build is superseded by this one; its emulator captures are gone from this page.
The Teensy drives a round display, and the face engine that paints it is part of the firmware. One face ships, thesis, in three colourways (Sapphire Depth, Graphite and Amber), and it covers every device state: battery, boot, calibrate, fault, idle, linked, recording, saved, standalone, stop and teleop. Two earlier design studies, rams and ferro, stay in the source for reference; they are not built into the firmware.
None of these are static screens. Every face animates: boot sweeps and self-tests, the teleop ring tracking assist, the recording counter and its take meter, idle breathing while nothing is happening. The engine runs a dirty-tile renderer inside a fixed frame budget, so the paint never starves the control tick.
Faces rendered by the firmware's own rasterizer from a mock feed and played at the speed they were authored: the boot sequence of the shipping thesis face and of the two studies, then recording counting a take up, and idle breathing.
The shipping face and the two studies against every state. These are renders, not photographs of the physical screen.
The thesis face is the one the firmware builds. Source, the face engine, the frame budget
and the flashing runbook are in
firmware/takto_one/watch/.
Most hand devices sense position. TAKTO ONE also listens to the muscles.
The front end is a MyoWare 2.0 muscle sensor on a standard three-lead setup: two electrodes along the target muscle belly and one reference on electrically quiet tissue, a nearby bone or joint. The board does the analogue work — differential amplification of the two muscle leads against the reference, rectification and envelope detection — and hands the firmware a clean envelope on pin 14. The device carries the Ag/AgCl snap interface for it, so it takes the same disposable gel electrodes used for ECG and EMG in clinical and lab work: skin contact costs cents, not a custom part, and anyone can replace a pad mid-session.
The firmware oversamples that envelope at roughly 1 kHz between 50 Hz frames, reduces it to a mean envelope plus RMS, and writes both into every frame of the stream and every row of the SD log — on the same clock as the twelve encoders and the IMUs.
That single time base is the point. Encoders say what the hand did, IMUs say how it moved through space, and EMG says what the wearer intended, fractions of a second before the joints follow. Three signals, one clock: training data for models that learn intent, and a third input for whoever builds the next control layer. The operator console and the public front end both draw the live effort channel.
Simulation, from the project's intent-fusion research on a documented synthetic signal model: in a stick-slip scenario the encoder-only observer takes 172 ms to engage assist; fusing the activation channel cuts that to 12 ms, inside an energy-budgeted control law that provably cannot drive motion on its own. Not a measurement on a person.
Behind that figure sits a research track in the wider project, not in this release: a causal acquisition pipeline (band-pass, notch, RMS envelope), a whitened Bayesian decoder, and an energy-tank shared-control law where activation leads the encoder during isometric loading while a passivity certificate guarantees it can never self-drive the joint. Developed and validated against a documented synthetic signal model with reproducible pass reports, and stated as exactly that: signal-processing and control research, ready for hardware trials, not claims about human experiments. If multi-source intent detection is your field, this device was built to be your testbed.
The clearest proof that this is a platform is TAKTO-SIGN: a German Sign Language capture,
training and live-recognition stack built on exactly this hardware. It records finger bend and
hand orientation at 60 Hz, learns a designed vocabulary, and recognises signs live. Like
everything else here, it runs end to end with no hardware through --sim.
Its scope statement is worth repeating because it is the right way to talk about work like this: a signer-dependent isolated-sign recogniser with a continuous scripted-sentence path and a measured cross-signer result. It is not open-vocabulary translation.
One application, built by one person, on this platform. An example of what the hardware supports, not the limit of it.
Read every finger and drive every finger, and a whole class of problems opens up. These are directions, not delivered features; each is a project of its own, and open-sourcing the platform is how they happen in parallel instead of one at a time. Every one of them starts from the files already in this repository.
Current status is stated plainly in Where the project really stands.
| Mechanism | Tendon-driven, four instrumented long-finger assemblies |
| Actuation | Series-elastic, through elastic tendons and ratchet-based spools |
| Joint sensing | 12 × AS5600 magnetic encoders, 3 per finger |
| EMG | Embedded Ag/AgCl electrode interface for standard snap gel electrodes; envelope + RMS in every frame |
| Controller | Teensy 4.1 |
| Motor bus | Dynamixel Protocol 2.0 over a 74HC241 half-duplex interface, the microcontroller owns the bus; no host PC required |
| Electronics | 2 custom PCBs, full KiCad sources + manufacturing outputs |
| Interface | Browser operator console with a live 3D twin, over a serial→WebSocket bridge |
| Structure | 3D printed; as built, a mix of PETG and PLA |
| Parts | 71 printed parts, 8 servos, 12 encoder boards as designed. Full bill of materials |
Eight motors, twelve instrumented joints, seventy-one printed parts. The servos are nearly the whole bill; every other group put together is under a fifth of it, which is why cutting the motor count is the most useful thing anyone could contribute.
Part numbers, suppliers, quantities and the caveats are in docs/BOM.md,
with a machine-readable copy in docs/bom.csv.
Clone to a moving hand in under a minute: the console opens in simulation, so you can explore the whole stack before you print a single part. (No clone needed just to look around: takto.one runs the same twin and console in your browser.)
git clone https://github.com/molanocortes/takto-one.git
cd takto-one
# see the console and 3D twin immediately, no hardware needed
python3 -m http.server 8096 --directory software/console/app
# open http://localhost:8096/
Then read docs/README.md: system architecture, the illustrated build
guide, and the known corrections between the documentation and the current hardware.
| Step | Where |
|---|---|
| Source the parts | docs/BOM.md |
| Choose and print parts | cad/README.md |
| Order and wire the boards | electronics/README.md |
| Flash the Teensy | firmware/README.md |
| Connect the twin to hardware | software/README.md |
The embedded Dynamixel driver is also maintained standalone as dynamixel-on-device.
Precision here matters more than a longer feature list.
Verified on hardware. The firmware runs on the device. The Teensy owns the Dynamixel bus through the 74HC241 and drives one finger with two XC330 servos: motor-controlled finger movement was demonstrated and tested on the bench, with the transmission run both with and without its elastic element in series. The full design takes eight servos; the other six are not fitted yet. All twelve magnetic encoders have read live together on the worn device and fed the browser twin in real time. Two BNO085 IMUs are fitted, on the hand and the forearm. Four long-finger assemblies are built and instrumented, and both PCBs exist as manufactured designs with complete sources.
On the bench today (October 2026). After a wiring fault, four encoder channels (00, 04, 05 and 11: the middle finger and the ring finger's abduction) answer nothing on I²C, so eight of the twelve joints read live until the harness is repaired. The fault is in the wiring, not the firmware.
The firmware and the wiring carry a third IMU channel for a thumb-tip unit that is not
fitted, in the same way the two multiplexers carry fourteen encoder channels for twelve
populated encoders. The unfitted channel reports MISSING in the s bus scan, streams a live
flag of zero, and logs an identity quaternion, so nothing downstream mistakes it for data.
Not established by this repository. Force rendering, transparency control, and assistance behavior are not characterized by measurements here. Verify the actuator count, limits, and safety behavior on your own hardware before any worn experiment. Repository-preparation checks are in the verification record.
Known limitations. Eight motors makes this an expensive build. The series-elastic actuation is a simple implementation, elastic tendons and ratchet spools, not an advanced SEA design. Recent soft-robotics work achieves comparable sensing with simpler mechanisms. This is a working, well-instrumented research platform, not a claim to the state of the art, and those gaps are exactly where contributions help most.
Loop rate, sampling rate, telemetry rate and console update rate are four different numbers; collapsing them into one is the easiest way to mislead someone.
SAMPLE_HZ in the sketch in this release, the
serial-line rate. The development firmware, not yet released here, streams 100 Hz; that is
the figure on takto.one.The ceiling on encoder sampling is set by the I²C bus and multiplexer switching, and it has not been characterised here. If your application depends on a specific rate, measure it on your own build.
TAKTO ONE is an experimental research prototype. It is not a medical device and not a certified protective product. Do not use it for diagnosis, treatment, unsupervised rehabilitation, or safety-critical operation.
Keep actuator power independently removable, begin with torque disabled, test away from the body, confirm mechanical limits, and validate watchdog and fault behavior before any worn experiment.
This project is under active development and contributions are genuinely wanted. The limitations above are not fine print; they are the to-do list, and some of the most interesting problems are still unclaimed.
docs/README.md; find more.See CONTRIBUTING.md. Open an issue with questions, ideas, or photos of
your build; showing what you made is always welcome. For anything that does not belong in a
public issue, write to sebastianmolano.eng@gmail.com.
Software Apache-2.0 · Hardware CERN-OHL-S-2.0 · Documentation and media CC-BY-4.0.
Full detail, attribution format, and the text-and-data-mining reservation: LICENSE.md.
The hardware licence is strongly reciprocal: distribute a modified design and you publish your
modifications. If that does not suit your situation, licensing on other terms is available,
see LICENSE.md. Contributors are asked to agree to a short CLA, which
keeps relicensing possible and leaves your copyright with you.
TAKTO and TAKTO ONE are trademarks of Sebastian Molano, asserted as unregistered marks and
not covered by any licence above. Build it, change it, sell it, and say it is based on TAKTO
ONE; just give your own version its own name. Details in LICENSE.md.