Greg: What an AI-Designed Robot Reveals About Physical Prototyping

A robot that recognizes a raised hand and returns a high five sounds like a small programming project. In practice, the software has to cooperate with printed plastic, moving cables, uncertain camera geometry, and a power supply that must tolerate several motors starting together.

Greg, a desktop robot built by Andris Gauracs with design and software assistance from Claude, makes those dependencies unusually visible. Its five servos move a printed arm toward an open palm. A camera supplies images, a Mac interprets them, and a separate controller drives the joints. The finished prototype works, but getting there required repeated measurements, revised parts, and calibration against the assembled machine.

AI can accelerate the production of designs and code while leaving physical validation firmly in human hands. Greg is a useful case study because the corrections explain more than the initial design does. They show why generating plausible components and making those components cooperate are different engineering problems.

The robot is a distributed system

Greg divides sensing, interpretation, and motion across three computing devices. A Seeed Studio XIAO ESP32-S3 Sense board captures camera images and sends them over Wi-Fi. A Mac processes the images and selects a response. Another ESP32-S3 board receives motion commands and controls the servos.

This division matters when describing the robot's autonomy. Removing the USB programming cables gives the arm a cleaner physical setup, but it does not move the vision workload onto the microcontrollers. The Mac remains part of the operating system. If it stops processing images or the network connection fails, the boards alone do not provide the demonstrated hand recognition and response.

Each component has a narrower responsibility than the whole machine. The camera board produces observations. The host interprets those observations and decides where the arm should move. The motion controller translates that decision into electrical signals. This arrangement makes it possible to change the vision software without redesigning the motor wiring, although the interfaces between those components still need to remain consistent.

The camera hardware also needs a precise identity. Seeed's XIAO ESP32-S3 documentation distinguishes the Sense model, which includes a camera expansion board, from the standard board. It also documents camera module changes across product revisions. A design that assumes one board stack or lens position can therefore be wrong for the part actually on the workbench.

Parametric designs make revisions cheaper

A parametric computer-aided design (CAD) model describes geometry through variables and relationships. Instead of manually moving every surface when a servo pocket needs to become wider, a designer changes a dimension and regenerates the affected parts. That makes the model especially suitable for an assistant that can edit code and produce another candidate quickly.

For Greg, Claude generated Python that constructed the robot's parts in Blender. The project included the base, arm segments, servo mounts, and camera enclosure. Gauracs supplied the physical work: printing, soldering, assembly, measurements, photographs, and feedback about what failed to fit.

The productive loop was therefore broader than asking for a complete robot and printing the answer. A proposed part became a physical object, the object exposed a constraint, and that constraint became an input to the next revision. The generated model was a hypothesis about the hardware until the real components confirmed it.

Small fit tests reduced the cost of testing those hypotheses. Before committing to a large print, the build used compact pieces containing the servo mounting geometry. These could reveal whether a body or shaft opening fit without reproducing the entire base. The reported base print alone took roughly eight to ten hours, making a failed full-size attempt much more expensive than an unsuccessful test piece.

This is a useful constraint on claims about AI speeding up hardware development. Design iteration may take minutes, while fabrication still takes hours. The practical gain comes partly from arranging experiments so that the next important mistake can be discovered with the smallest possible print.

A component can fit while its connections do not

One shoulder mount accommodated the servo body but omitted a usable route for its cable. The dimensions were plausible when considered as a solid object. They were incomplete when considered as an installed component that had to connect to the rest of the robot.

The revision needed to account for the wire exit as part of the servo's occupied space. A cable is not simply a line on a wiring diagram. It has thickness, a bend radius, a connector, and a route that can change as a joint moves. Clearance at one position does not establish clearance across the full motion range.

The camera enclosure exposed a related problem. Early geometry did not match the actual thickness and arrangement of the stacked boards. A modeled assembly sequence also allowed the antenna to pass through a wall, something a rendering could display without proving that a human could assemble the object that way. Measurements of the real hardware informed another enclosure revision with a screw-fastened lid.

The physical board stack and antenna must fit the enclosure as assembled. A plausible exterior shape cannot verify those internal clearances.

These failures share a cause: a design can represent the intended final arrangement without representing the process of reaching it. Assembly needs access for tools, room to insert components, and a sequence that does not require already connected parts to pass through solid surfaces. A visually convincing model is evidence about appearance, not complete evidence about manufacturability.

Power distribution is part of motion control

The controller's signal pins do not supply the energy that moves the arm. The servos draw power from a separate distribution path, while the microcontroller supplies their control signals. Those paths need a common electrical reference so that the servos can interpret the signals consistently.

Greg used a custom perfboard to distribute power and ground and connect the servo leads. The build reported a 5 V, 6 A supply and a 1,000 µF capacitor near the distribution point. The capacitor was intended to help with brief demand changes when motors began moving.

Those component values describe this prototype. They do not establish a universal power design for every arm using similar-looking motors. Supply demand depends on the exact servos, mechanical load, acceleration, and how many joints move together. A capacitor can buffer a transient, but it cannot compensate indefinitely for an undersized supply or excessive resistance in the wiring.

The build also separated external power from the USB power path during programming using a jumper arrangement. That detail reflects another interface problem: a board connected to both a programming computer and an external supply needs a known power path. The correct arrangement depends on the board's circuitry, so copying a connector layout without checking the exact hardware would miss the reason for the isolation.

Electrical and mechanical debugging can otherwise become confused. A joint that moves unpredictably might have an incorrect command, a binding mechanism, or an unstable supply. Testing one layer at a time makes those explanations easier to distinguish than changing the generated code whenever the arm behaves unexpectedly.

Separate joints need separate control signals

A servo receives a repeating control signal whose pulse width represents the requested position. Pulse-width modulation, commonly shortened to PWM, lets a controller generate these timed signals. Independent positioning requires the relevant outputs to carry independently adjustable commands.

During Greg's development, the base and elbow moved together when they should have responded separately. The reported fix was to assign distinct PWM channels explicitly in the servo software. The important observation was the relationship between the two joints: their coupled behavior suggested a shared control resource rather than two unrelated mechanical faults.

Espressif's ESP32-S3 LEDC documentation describes independently configurable PWM channels and their association with timers and output pins. That supports the underlying control model. It does not mean every paired movement on every servo library has the same cause; library versions and channel allocation strategies still matter.

Greg eventually used five servos rather than the earlier four-joint arrangement. The added twist joint helped orient the palm as the base rotated. Reaching a point and presenting a hand at the right angle are separate goals. An arm can arrive near a human hand while still offering the edge of its palm, which makes orientation part of the interaction rather than a cosmetic refinement.

Seeing a hand does not tell the arm how to reach it

Hand detection provides observations in the camera's frame of reference. The arm needs commands in its own joint coordinates. Connecting those two descriptions is a calibration problem, even when recognition works well.

Greg's host software used Google's MediaPipe for hand analysis. The Hand Landmarker documentation describes detection of hand landmarks and handedness from images or image streams. Recognizing an open palm is only part of the application: the robot must also decide whether the hand is a suitable target and map the observation to a reachable pose.

The build collected examples linking positions in the camera image to joint settings. Colored tape on the printed hand made the robot's own palm easier to track during calibration. A sequence of poses produced a grid of observations that could be used to fit the relationship between image position and arm configuration.

This empirical approach uses the assembled robot as the measurement instrument. It can absorb some differences between the ideal model and the actual build because it records what the real joints and camera produce. It also has limits. A mapping learned over one working region is not evidence of accurate motion everywhere, and two-dimensional image position alone does not uniquely specify arbitrary three-dimensional targets.

Camera placement determines which examples are useful. The initial lens did not cover the desired interaction area well enough, so the build moved to a wider-angle camera and changed its mounting angle. Those changes improved the visible region but also changed the relationship between image coordinates and the arm, requiring calibration to be repeated.

That dependency is easy to underestimate. A new lens can solve a visibility problem while invalidating a previously useful mapping. The camera is part of the robot's geometry, even though its contribution enters through software rather than through a joint.

Human corrections can become calibration data

Position was not the only property that needed adjustment. Greg also needed its wrist and twist joints to align the palm with the approaching hand. The build used a browser interface and spoken corrections to help collect examples of better orientations.

This was a supervised feedback loop. A human could request an adjustment, hold a pose, and associate the resulting configuration with the observed hand orientation. A small set of manually corrected examples helped fit that relationship. A later calibration with the wider camera collected 268 poses for the updated setup.

The counts explain the development process, not a general accuracy guarantee. They do not establish how well the robot behaves under different lighting, at untested distances, or with every hand orientation. The relevant question is whether the data covers the situations the machine will encounter, not whether a particular number of examples sounds large.

This also places the language model's role in context. Claude helped produce the software and revise the implementation, but the operational perception loop used camera analysis and calibrated mappings. It did not require a conversational model to inspect each frame and improvise every servo movement.

A convincing demonstration still leaves operating limits

The completed arm was fixed to a cutting board to make the base more stable. Both microcontroller boards could boot from the shared supply and communicate wirelessly, with colored indicators helping distinguish startup states. The reported prototype still sometimes needed a power cycle to start correctly.

Motion tuning made the interaction feel more responsive. The build reduced a response delay from roughly one second to a quarter second and increased the configured servo speed. A reported 60-degree movement in about 0.2 seconds describes a particular movement setting, not a measured end-to-end guarantee from camera exposure to contact.

The interface separates several motion settings. A speed limit, a target-selection delay, and the ability to stop the arm affect different parts of the interaction; the displayed settings are a development snapshot.

That distinction matters because total response time includes image capture, transport, inference, target selection, command delivery, and physical motion. Improving one delay can noticeably change the experience while leaving another bottleneck untouched. Startup reliability and recovery from lost observations are separate properties again.

A high-five arm also crosses from moving objects to interacting with people. Faster motion improves responsiveness while increasing the importance of bounded travel, stable mounting, and a way to stop the machine. The successful prototype does not establish validated contact forces or a safety rating. Those would require evidence beyond a working interaction.

Final thoughts

Greg shows how AI assistance can extend beyond writing application code into CAD generation, firmware, vision software, and iterative diagnosis. The project repository provides the starting point for examining that combination, while the physical build explains why generated files alone are not the finished system.

The decisive work happened where a proposed design met a measured constraint. Servo pockets needed cable space, control channels needed independence, camera changes needed recalibration, and a responsive arm still needed reliable power and startup behavior. Those lessons make Greg more useful than a claim that a model simply designed a robot: they show how human experiments turn generated designs into a machine that can operate in the real world.