A chatbot gets a hand in the real world
Meet Greg, a high-five robot with a single purpose. Its creator, a seasoned electronics tinkerer, challenged himself to build a complete robot for the first time. He gathered a few servos, an ESP32 board, and an inexpensive 3D printer, then turned to Claude Opus 3.5 for help.
Claude’s involvement went far beyond simple code snippets. The AI assistant designed all the parts in Blender, generating models with Python scripts that allowed for parametric adjustments. It also wrote the robot’s firmware and developed its computer vision system.
This project became a critical test: could an AI assistant bridge the gap between abstract design and physical reality? The goal was to see if Claude could integrate software, mechanics, electronics, and perception into one cohesive, working machine. The base alone took 8 to 10 hours to print, necessitating small fit tests before committing to large runs.
The central question was whether Claude could anticipate the real-world complexities of robotics, like wire clearances or power fluctuations, that often trip up even experienced human engineers. This experiment aimed to push the boundaries of AI assistance in hands-on hardware development.
Blender made redesigns cheap—printing did not
Claude’s design process for Greg’s components was quite clever. Instead of designing parts manually, Claude generated Python scripts for Blender. This meant that if a dimension was off, the maker simply adjusted parameters in the script, and Blender regenerated the model. This procedural workflow made iterative changes much faster and cheaper in the CAD phase.
Iteration was crucial because 3D printing was a time sink. Greg’s base alone required an 8- to 10-hour print. To avoid wasting plastic and time on non-functional parts, the maker performed small fit tests before committing to a full print. This allowed early detection of tolerance issues in miniature, preventing lengthy reprints.
Powering Greg involved a custom-soldered perfboard acting as a central hub. This board distributed power efficiently to all components. To combat voltage drops and prevent the ESP32 from resetting when multiple servos drew current simultaneously, the maker integrated a 1,000 µF capacitor into the power design. This capacitor buffered current spikes, ensuring stable operation.
The hardware found every shortcut
Hardware, it turns out, has an opinion. Claude's designs, while parametrically elegant, often overlooked the nitty-gritty of physical reality. The shoulder servo, for example, fit perfectly—until it was time to connect the wires. Claude hadn't accounted for the connector and cable bulk, leaving no room, forcing a design revision to create necessary clearance.
Another challenge arose in the firmware. Multiple servos moved in unison, a perplexing issue until debugging revealed a PWM channel bug. Claude had assigned overlapping Pulse-Width Modulation channels on the ESP32, causing unintended synchronous movements. Correcting these channel assignments resolved the phantom puppet show.
Greg needed more articulation to properly high-five. An initial four-joint design left the palm facing awkwardly, so a fifth joint was added, allowing the palm to orient flat against a human hand. This seemingly small adjustment drastically improved the robot's primary function.
Vision also presented hurdles. The inexpensive ESP32 camera had a frustratingly narrow field of view, making it difficult for Greg to spot a hand. Swapping it for a wide-angle lens fixed this, giving Greg the peripheral vision he needed. For more on the AI behind such designs, check out Anthropic.
Calibration, too, was an iterative process. Using tape on the robot's palm, it moved through 268 poses for initial learning, followed by 15 manual corrections to perfect its high-five accuracy. Powering the system required a custom perfboard with a 1,000 µF capacitor to prevent resets from simultaneous servo movements.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
268 poses later, Greg can reach for a high five
268 poses later, Greg can reach for a high five
Calibrating Greg involved a visual trick: a piece of tape on the robot’s palm served as a marker. The robot then moved through an astonishing 268 poses, allowing the builder to gather data on its range and precision. A custom web control page provided the interface for fine-tuning, requiring about 15 manual corrections to perfect its high-five motion.
Ultimately, Greg learned to match the builder’s hand. The entire setup now runs efficiently from a single power supply over Wi-Fi, and the robot can execute a 60-degree move in approximately 0.2 seconds. It’s a testament to iterative design and hands-on problem-solving.
This project offers a valuable lesson for makers: AI, like Claude, can dramatically accelerate cross-disciplinary prototyping. However, essential physical considerations remain crucial. Always plan for:
- Precise measurements
- Thorough fit checks
- Careful power planning
- Hands-on debugging
AI can generate the blueprints, but the real world still demands human ingenuity for the final touches. To build your own high-five robot, you can find all the design files, code, and a full parts list on GitHub.
Frequently Asked Questions
What does Greg, the robot, do?
Greg uses a camera and servo-driven arm to recognize a person’s hand and attempt a high five.
How did Claude help build the robot?
Claude helped generate Blender models through Python scripts, write ESP32 firmware, and develop the computer-vision and calibration workflow.
What hardware does the project use?
The build uses an ESP32, multiple servos, a camera with a wide-angle lens, a custom power-distribution board, and 3D-printed parts.
Did the robot work without human debugging?
No. The builder fixed fit and wiring issues, a PWM channel conflict, a missing joint, and the camera’s narrow field of view.
Are the robot’s files available?
The video says the design files, code, and parts list are available on GitHub.