Mano Robótica Inalámbrica Impresa en 3D Controlada por Guante

Descripción

I built this project to explore what happens when software must interact with the physical world instead of ending at a screen or an API. The goal was to create a wearable glove that could read the movement of a human hand and reproduce that movement on a separate 3D-printed robotic hand over a wireless connection. It combined embedded programming, sensor acquisition, radio communication, mechanical design, power management, and iterative prototyping. More importantly, it forced me to treat latency, calibration, safety, and physical tolerances as architectural concerns rather than implementation details that could be addressed later.

The input side began with flex sensors positioned along the glove so that bending each finger produced a measurable electrical change. Raw readings were not useful by themselves, because different sensors and different hands produced different ranges, noise patterns, and resting values. I applied the same normalization mindset used in data engineering and machine-learning preparation: establish a baseline, identify practical minimum and maximum values, smooth unstable readings, and translate them into a consistent control range. That calibration layer separated imperfect physical measurements from the control logic and made the behavior easier to tune without rewriting the entire system.

On the transmission side, I designed a compact message flow for sending finger positions through RF modules. A robotic control loop benefits from small, predictable messages rather than verbose payloads, so I focused on the essential state, a stable update rhythm, and basic validation before accepting a command. This reflected my experience with real-time systems, event-driven architecture, and network boundaries: producers and consumers should agree on a clear contract, tolerate missing or delayed messages, and fail safely when the contract is not satisfied. Even in a small prototype, communication reliability determined whether the hand felt responsive or erratic.

The receiving controller converted those messages into target positions for micro servos mounted inside the printed hand. Mapping a sensor value to a servo angle sounds straightforward, but the useful range was constrained by tendon routing, joint geometry, servo travel, friction, and the risk of forcing a component beyond its mechanical limit. I added bounded mappings and tuned each finger independently. That work connected software architecture with physical feedback: a mathematically valid command can still be unsafe for the mechanism, so domain constraints must be represented explicitly at the point where a digital decision becomes physical movement.

The 3D-printed structure introduced another layer of engineering. Printed joints, cable paths, fasteners, and servo mounts all affected the control response, and small mechanical changes could alter the software calibration. I treated the hand as a system of cooperating components rather than a collection of isolated parts. When a finger moved poorly, I examined the full path from sensor reading to radio message, controller mapping, servo behavior, tendon tension, and joint resistance. That diagnostic approach mirrors how I investigate distributed applications: follow the signal across boundaries, identify where assumptions diverge from reality, and change the narrowest responsible component.

Power and failure behavior were equally important. Servos can create short bursts of current demand, radio modules can become unstable when supply quality drops, and a disconnected transmitter should not leave actuators moving unpredictably. I considered shared grounds, power separation, battery limitations, neutral positions, range limits, and the behavior of the receiver when updates stopped. These decisions reflect the security and resilience principles present throughout my work: define safe defaults, validate inputs, limit the effect of malformed state, and make failure visible. The project was experimental, but its control boundaries were designed with the same care I bring to production services.

My background in C#, C++, IoT telemetry, edge computing, distributed systems, and production diagnostics shaped how I organized the prototype. I kept sensor acquisition, calibration, transport, and actuator control conceptually separate so each stage could be tested and improved independently. Knowledge from AI and predictive-system work also influenced how I thought about future extensions, such as learning personalized motion mappings or detecting gestures, but I deliberately kept the implemented control path deterministic. A direct, explainable mapping was the right foundation before introducing models whose behavior would require additional data, evaluation, and safety controls.

The result is a compact example of end-to-end engineering: a human gesture becomes sensor data, normalized state, a wireless message, an actuator command, and visible mechanical motion. Building it strengthened my understanding of the gap between a convincing diagram and a dependable working system. It also reinforced a principle that carries into secure AI and cloud architecture: every abstraction eventually meets a boundary it does not control. Good engineering makes that boundary observable, constrains what can cross it, and creates a feedback loop for learning. This robotic hand made those lessons tangible in the most literal way.