All the code for this project is available on GitHub：https://github.com/vhp8rc7p/hackster/tree/main/typer
----------------------------------------------------------------------------------------------
"You gave me the syntax, but I provide the pressure. Together we bridge the gap between a thought and mark."
When we think of robotic arms, we usually picture rigid automation—machines built for repetitive, soulless tasks on an assembly line. But what happens when we try to teach a 4-axis robotic arm to capture the analog weight of human writing?
This project is an exploration into bridging the digital and the physical. Using an Elephant Robotics myPalletizer 260, a mechanical keyboard and a cylinder from Elephant Robotics, I built a system that translates digital intentions into the tactile, physical act of typing. It goes beyond simple "go-to-coordinate" commands. By integrating Python for precise kinematics and opentype.js to parse the vector paths of complex handwritten fonts, the robot attempts to mimic the fluidity of a human hand.
It’s an exercise in control, timing, and coordinate mapping. In this article, I'll walk you through how I mapped a flat QWERTY layout into a 3D robotic workspace, why calculating dynamic "settle times" is critical to stop the robot from shaking itself apart, and how I ultimately taught a machine to type its own poetry.
Watch the demo here:
The first major hurdle is translating a flat keyboard into a language the 4-axis MyPalletizer understands. We can't just tell the robot to "press A." We have to tell it exactly where "A" exists in physical space relative to the base of the robot.
In test_press.py, I created a virtual grid system. Because keyboard rows are staggered (they don't line up perfectly straight up and down), I had to account for two main variables:
1. Pitch (PITCH_Y): The horizontal distance between the center of each key (calibrated to 18.0 mm).
2. Row Stagger (ROW_STAGGER): How much the entire row shifts left or right.
By taking the "Home Row" (A, S, D, F...) as the zero reference, we can use a dictionary to define every key based on its row index and column offset.
# Key: (Row_Index, Column_Offset_from_G, X_Coordinate, RX_Angle)
key_map = {
'g': (0, 0, 215.0, -14.94), # The absolute center of our map
'a': (0, -4.5, 215.0, -14.94), # Home row, offset left
'q': (1, -4, 230, -24.6), # Top row, accounting for stagger
'z': (-1, -4, 191.2, -24.69), # Bottom row, closer to the robot
}Step 2: The Z-Axis (The "Pressure")
Knowing where the key is isn't enough; the robot needs to know how hard to press it. This is where the Z-axis calibration comes in. If the Z-axis is too high, the robot misses the keystroke. If it's too low, the motor grinds against the plastic and triggers an error state.
I defined two distinct heights:
* Z_HOVER = 32.0: The safe traveling height. The robot glides across the keyboard at this altitude to avoid catching on the keycaps.
* Z_PRESSED = 19.0: The actuation point. This is the exact depth required to trigger the mechanical switch and provide that satisfying "click."
The typing motion becomes a three-step dance: Hover above the target -> Plunge to Z_PRESSED -> Instantly retract back to Z_HOVER.
Step 3: Beating the Premature Plunge (The Travel Time Bug)Once the coordinates were mapped, I ran into a serious synchronization bug.
To type a letter, the arm needs to move over the key (X, Y), wait until it arrives, and then plunge down (Z) to press it. The MyPalletizer API has a built-in is_in_position(coords) function that is supposed to return True only when the movement is finished.
I wrote a while loop that polled this function, sleeping for 0.1s intervals until the robot confirmed it had arrived.
The Problem:If the 4-axis robot arm was making a short jump (e.g., from 'S' to 'D'), this worked fine. But on long travel distances—say, leaping from 'A' all the way across the board to 'P'—the API would occasionally report a false positive. The software would think the arm had arrived while it was still mid-air, causing it to execute the Z-axis plunge prematurely. It would stab at empty air between keys and miss the target entirely.
Polling the robot's state over serial simply wasn't reliable enough for long sweeps.
The Solution: Distance-Based Determinism
Instead of relying on the robot to tell me when it was done, I decided to calculate the required travel time mathematically
before the arm even moved. I wrote a settle_time algorithm based on Euclidean distance.
def settle_time(char, target_x, target_y):
global prev_key, prev_coords
# First keystroke gets a long settle time
if prev_key is None or prev_coords is None:
return 0.9
# Double letters (e.g., 'tt') need almost no travel time
if char == prev_key:
return 0.1
# Calculate Euclidean distance between previous key and new key
dx = target_x - prev_coords[0]
dy = target_y - prev_coords[1]
dist = (dx**2 + dy**2) ** 0.5
# Scale the wait time: nearby keys ~0.2s, far keys ~0.9s
t = 0.1 + (dist / 120.0) * 1.5
return min(max(t, 0.1), 1.6)By calculating the distance (dist) between the previous key and the target key, I could scale a hard time.sleep() delay. Nearby keys only pause for 0.2 seconds before plunging, while a massive leap across the keyboard forces a guaranteed 1.5-second wait.
By taking control of the timing logic away from the API and making it strictly distance-based, the premature plunging stopped entirely, and the typing became flawless.
How it works:The script calculates the Euclidean distance (dist = (dx**2 + dy**2) ** 0.5) between the last key pressed and the next
target. It uses that distance to scale a delay time t.
* If typing adjacent keys (like 'A' to 'S'), the robot only pauses for a split second (0.2s).
* If making a massive leap (like 'Q' to 'M'), it forces a longer pause (closer to 1 second) to let the arm's vibrations dampen completely before initiating the Z-axis plunge.
This simple piece of math transformed the robot from a shaky, erratic machine into a smooth, deliberate typist.
Conclusion: A Thought Becomes a MarkWatching the myPalletizer tap out those final words—"together we bridge the gap between a thought and mark"—was incredibly satisfying.
By combining the precision of python coordinate mapping with dynamic physics calculations, we proved that a 4-DOF industrial-style robotic arm can perform tasks requiring delicate, human-like cadence. The project successfully bridged the digital intent (the syntax) with the physical world (the pressure).
Conclusion & Future Upgrades: From Blind Typing to True VisionWatching the myPalletizer tap out those final words—"together we bridge the gap between a thought and mark"—proved that we can translate digital syntax into physical pressure. We solved the structural mapping of the QWERTY layout and overcame the asynchronous timing bugs of long travel distances.
However, the current system relies entirely on "dead reckoning." The robot is blind. It assumes the keyboard is perfectly aligned at the exact origin point I calibrated on my desk. If the keyboard gets bumped even half an inch, the entire coordinate map fails, and the robot will type gibberish (or worse, crash its tip into the plastic ridges between the keys).
The Next Step: Hand-Eye CalibrationTo make this project robust, the next major upgrade will be abandoning the fixed coordinate dictionary entirely.
By mounting a camera to the end-effector (or positioning an overhead camera looking down at the workspace), I plan to implement Hand-Eye Calibration (using OpenCV and ArUco markers).
Instead of moving to a hardcoded [X: 215, Y: 0], the robot will dynamically locate the keyboard's bounding box in real-time.
It will mathematically infer the location of every keycap relative to its own base, regardless of where the keyboard isbplaced on the desk. This will turn the robot from a machine that just follows a blind script into a true, adaptable typistvthat can "see" what it's writing.
Developers are welcome to participate in our User Case Initiative and showcase your innovative projects: https://www.elephantrobotics.com/en/call-for-user-cases-en/.
Comments