01LIVE
Robotic Hands
Mechanical hands, servo control, gesture systems and experiments in turning text interaction into physical movement.
RoboticsRaspberry PiPhysical Language
Open Hand001 →Read the journey →WEZLAB / v0.1
Projects. Experiments.
Engineering. Ideas.
A working lab for robotics, software, systems, fabrication and the occasional idea that refuses to stay on the whiteboard.
THE LAB / BEYOND THE BENCH
Build. Learn. Explore. Repeat.
WEZLAB is more than the hardware on the bench. It is the mix of projects, music, machines, curiosity, home life and good company that gives the work its character.
CURRENT WORK
Projects in the lab
WEZLAB is deliberately broad: physical builds, software tools, infrastructure, experimentation and documentation all belong here.
02BUILD
WEZUTIL / Fleet
Fleet administration, diagnostics, reporting and tools for managing a growing collection of Raspberry Pi systems.
LinuxPowerShellTailscale
Read the journey →
03
SYSTEMS
Raspberry Pi Lab
Small Linux systems, cameras, network experiments, remote access and useful utilities built around Raspberry Pi hardware.
Raspberry Pi
Linux
Networking
Project page →
04
ELECTRONICS
Controllers & Interfaces
Web controls, small device interfaces, servo controllers and experiments that connect software to physical hardware.
Python
Web UI
Hardware
Project page →
05WORKSHOP
Fabrication & 3D Printing
Servo mounts, spacers, enclosures and small mechanical experiments designed, iterated and printed in the workshop.
OnshapeCAD3D Print
Project page →
06
IDEAS
Creative Lab
Story concepts, speculative systems and thought experiments that sit somewhere between engineering, technology and fiction.
Stories
Concepts
Worldbuilding
Generation Ship Earth →
BACKSPACE →
07
ROVERS
Rovers / Early Robotics
An early WEZLAB-style robotics build from around a decade ago: a 3D printed rover developed alongside its CAD model, with custom bodywork and distinctive multi-roller wheels. A reminder that the current fleet has much older roots.
Rovers
3D Print
CAD
Early Build
Project page →
Hand / Fleet Project
From First Gesture to Governed AI Fleet
This report tells the story of an experimental physical-computing project that began with a pair of servo-driven robotic hands and evolved into a distributed Raspberry Pi fleet, remote administration tooling, read-only diagnostics, AI-assisted control, evidence collection, and a progressively stricter governance model for any action that can affect physical hardware.
1. Executive overview
What started as “can two robotic hands communicate through gestures?” steadily became a much broader engineering exercise: mechanical prototyping, servo calibration, web control, secure remote access, service management, fleet visibility, controlled AI integration, evidence capture, resilience testing and policy enforcement.
Physical layer
2 hands
Independent five-finger servo control with a gesture vocabulary and conversation-oriented motion sequences.
Fleet layer
Multiple Pis
Hand001, Hand002, Rover nodes and WEZUTIL were progressively managed as a small distributed fleet rather than isolated devices.
Control model
Governed
The project moved from direct experimentation toward explicit read-only observation, approval gates, correlation, provenance and bounded action.
The key progression: the project stopped being “a robotic hand demo” and became an exercise in how an AI-enabled system can observe,
reason about and, only when explicitly permitted, interact with real physical devices in a controlled and auditable way.
2. Where it began
The original concept
Two small robotic hands on a desk would act as a physical communication channel. Instead of expressing meaning only through text or emoji, a remote user could cause one hand to wave, point, give a thumbs-up, make a fist, perform a finger-heart or execute a short sequence.
The deeper idea
The hands were not intended merely as puppets. The long-term idea was that one side could represent a human participant while the other could represent an AI participant, giving a text-based AI a physical expressive layer.
Early work therefore had to solve two problems at once: the obvious mechanical problem of moving fingers reliably, and the less obvious systems problem of making that movement remotely accessible, repeatable and safe.
3. Project timeline
Early phase
Mechanical hand prototypes and servo experimentation
Multiple handmade hand prototypes were developed, refining the physical form, tendon/servo behaviour and the practical arrangement of left- and right-hand mechanisms. This established the basic movement model before the software stack matured.
July 2026
Hand001 becomes a remotely controlled web device
A Flask-based controller exposed gesture controls through a browser. A secure remote-access path was established over Tailscale. An external user successfully authenticated, ran a demo and controlled the hand remotely — an important proof that the project worked outside the local LAN.
July 2026
Two-hand conversation mode
The project expanded from single gestures to coordinated sequences across two hands. Conversation-oriented builds introduced generated gesture sequences and then dynamic behavioural language concepts, moving toward hand-to-hand expression rather than simple button-driven movement.
July–August 2026
Dynamic and speaker-aware behaviour
Successive software versions introduced dynamic topic sequences and speaker-aware execution. The user interface was refined so left and right controls visually matched the physical hands, while calibration and hand-orientation issues were corrected.
August 2026
Hand002 takes on the AI role
The architecture became explicit: Hand001 represents the human side; Hand002 represents the AI side. The desired interaction became “human speaks through Hand001, AI responds through Hand002,” with finger movement acting as a physical interpretation of AI-generated output.
August 2026
Rover and controller experiments
Rover nodes were introduced as additional Linux endpoints. AI-assisted controller experiments demonstrated live observation of Hand001 status and tightly guarded physical execution. Correlated verification was then added so that an action request and the observed result could be linked as one auditable event.
August 2026
MCP and read-only AI tooling
Hand001 was exposed through a small MCP service so an AI client could inspect status, service health and system information. The first successful live query showed the AI calling Hand001 tools, reading its controller state and reporting back without relying on manual copy/paste.
Late August 2026
Node Admin evolves into a fleet console
Administration moved beyond SSH shortcuts. Node Admin gained diagnostics, Bash execution under guardrails, HTML evidence reporting, editable connection data and increasingly strong provenance around what was run and where.
Late August – September 2026
WEZUTIL becomes the fleet administration workstation
A Raspberry Pi 400 named WEZUTIL became the dedicated Raspberry Pi OS 64-bit utility/admin console. PowerShell, Python, Tailscale and diagnostic scripts were brought together into a reusable fleet-health and reporting environment.
Current mature architecture
Resilient, governed, multi-endpoint operation
The later architecture treats Hand001 as the required governed physical endpoint, while Hand002 and Rover nodes may be optional. Optional endpoint failures no longer need to collapse the whole console. Read-only diagnostics, bounded AI tool calls, approval gates and separate physical-action authority are central design rules.
4. How the system fits together
The project is best understood as several layers rather than one application.
Human / operator
Jas / colleague
Uses browser UIs, WEZ/Node Admin, diagnostic tools or an AI client.
→
Management layer
WEZUTIL + Node Admin
Fleet visibility, connection management, diagnostics, evidence and guarded execution.
AI / tool layer
WEZ client / MCP
Structured model-facing tools, largely observation-only, with bounded discovery and explicit authority boundaries.
→
Secure transport
Tailscale
Private connectivity between workstation, hands and rover nodes without exposing controller ports publicly.
Device layer
Hand001 / Hand002 / Rovers
Linux services, status endpoints, scripts and hardware interfaces.
→
Physical layer
Servo-driven gestures
PCA9685 PWM control, ten servo channels across the two hands, gesture definitions and calibrated actuation.
5. The fleet
| Node | Role in the project | Typical capability |
|---|---|---|
| Hand001 | Primary governed physical endpoint; often treated as the human-side hand. | Controller service, web UI, status APIs, gesture execution, MCP observation and supervised physical action. |
| Hand002 | Second robotic hand; evolved toward the AI-side physical participant. | Independent controller, gesture execution, read-only model-facing observation in later architecture. |
| Rover007 / Rover007-1 | Experimental Linux/AI controller and fleet endpoint. | Observation, guarded scripts, AI-client experiments and fleet diagnostics. |
| Rover008 | Additional optional fleet node. | Fleet observation and diagnostics. |
| WEZUTIL | Dedicated administration workstation built on Raspberry Pi 400. | PowerShell 7, Python, Tailscale, fleet testing, HTML reporting and admin-console functions. |
6. Software evolution
Hand controller lineage
The controller progressed through conversation, dynamic-behaviour and speaker-aware versions, culminating in an end-user interface suitable for demonstrations and remote interaction.
Conversation Mode
Dynamic BHL
Speaker-Aware BHL
End-User UI
Node Admin lineage
What began as connection/administration convenience grew into a multi-service diagnostic console with version-aware controller discovery, generated HTML reports and stricter separation between observation and execution.
v2.1.0.x family
Controller discovery
Fleet diagnostics
WEZ client lineage
AI clients moved through several iterations, including resilient startup and optional-endpoint handling. Later designs kept model-facing capabilities tightly bounded and made the authority of each tool explicit.
v0.4.3.x family
Degraded startup
Bounded tools
One of the important engineering lessons was that versioning mattered. As controllers, APIs and services changed, the tooling
increasingly needed to discover what was actually running rather than assume a fixed file name, service layout or endpoint behaviour.
7. Safety, control and governance
The most significant architectural change was the deliberate separation of seeing from doing. Earlier experimentation proved that remote physical actions were possible; later work concentrated on making sure they could not happen casually or ambiguously.
Observation path
- Read system and controller status.
- Inspect service health and version evidence.
- Run bounded, guarded read-only diagnostics.
- Generate local HTML evidence reports.
- Allow optional endpoints to fail without collapsing the whole client.
Physical-action path
- Kept separate from normal diagnostics.
- Supervised rather than automatically retried.
- Correlated with request/result evidence.
- Subject to explicit policy and GUI approval.
- Restricted to the intended governed endpoint and permitted gesture scope.
Important design rule: “AI can reach the device” is not treated as equivalent to “AI may operate the device.”
The mature design uses separate authority, explicit approval and evidence so that physical control remains intentional.
8. Significant outcomes and proofs
Remote physical control proved
A user outside the local LAN authenticated over the private network, ran a demo and successfully controlled a hand.
Two-hand sequences proved
Coordinated gesture sequences demonstrated that the project could express a conversation-like exchange, not merely isolated motions.
AI tool integration proved
An AI client successfully called live Hand001 tools and reported current controller and system state from machine evidence.
Governed action proved
Later controller work demonstrated supervised physical action with correlation between the requested action and observed execution.
Fleet administration proved
WEZUTIL and Node Admin turned multiple Raspberry Pis into a manageable fleet with reusable diagnostics and HTML evidence.
Resilience improved
Optional Hand002/Rover endpoint problems were designed not to prevent operation of the required Hand001 path.
9. Where the project stands now
The current direction is much more disciplined than the original prototype. Hand001 is treated as the required, governed physical device; Hand002 and Rover nodes can be optional participants. Administration and diagnostics are primarily read-only, while physical execution is a separate, explicitly controlled capability.
| Area | Current maturity |
|---|---|
| Mechanical hand concept | Proven through multiple prototypes and working servo-driven hand assemblies. |
| Remote access | Proven using private Tailscale connectivity and browser/controller access. |
| Human ↔ AI physical metaphor | Architecture established: Hand001 as human side, Hand002 as AI side. |
| Fleet visibility | Established through WEZUTIL / Node Admin and multi-node diagnostics. |
| AI observation | Proven through structured MCP/read-only tools and live device interrogation. |
| Physical AI action | Possible, but deliberately governed, bounded, supervised and kept separate from read-only tooling. |
| Reporting / evidence | HTML fleet reports, session logs and provenance have become first-class parts of the system. |
The project’s most useful lesson for colleagues: the visible robotic hand is only the front end. The majority of the
engineering effort has been in the infrastructure around it — secure connectivity, Linux services, fleet management, version discovery,
diagnostics, failure handling, auditability and defining exactly what an AI system is and is not allowed to do.
10. What this demonstrates beyond the hand project
Although the project is experimental, the design problems are directly relevant to enterprise engineering.
Least authority
Give a tool only the capability required for its task. Observation and action should not automatically share the same permissions.
Evidence before assumption
Discover the running service, version and state rather than assuming the environment matches a static design.
Resilient dependency handling
Optional systems should degrade gracefully; failure of one secondary endpoint should not make the required path unusable.
Human approval for consequence
Where an action has real-world effect, explicit approval and clear presentation of intent are valuable controls.
Audit and provenance
Knowing who initiated an action, what code or script was involved and what result was observed becomes as important as the action itself.
Prototype → platform
A useful prototype often exposes the need for administration, configuration, diagnostics and governance long before it needs more features.
11. Closing perspective
The Hand/Fleet project began as a creative question about giving digital communication a physical form. It now represents a much broader experiment: how to build a small fleet of real devices that an AI can understand, observe and — under tightly controlled circumstances — help operate.
The result is not one finished product so much as a working engineering platform: robotic hardware, private networking, Linux services, browser interfaces, administration consoles, fleet diagnostics, AI-facing tools and an increasingly deliberate safety model. Each layer was added because the previous layer exposed a real operational need.
FROM THE BENCH / FIELD NOTE 001
An Unexpected Visitor
26 SEP 2026 · WEZLAB
CAPTURED IN THE LAB
Not every visitor to WEZLAB arrives through Tailscale.
In the middle of an ordinary session at the desk, a local python quietly appeared and came close enough to investigate what was going on. The camera happened to be within reach, turning an entirely unplanned encounter into one of those small moments worth keeping.
LAB NOTE / 001
Build small. Document everything. Keep the useful bits.
WEZLAB is not intended to present only finished work. It is a record of the process: prototypes, revisions, mistakes, discoveries and the occasional “aha” moment that sends a project in a completely different direction.
01Build
Turn an idea into something that can actually be touched, run or tested.
02Observe
Pay attention to what really happens rather than what was supposed to happen.
03Iterate
Keep the useful parts, change the weak ones, and make the next version better.
ABOUT
What is WEZLAB?
WEZLAB is an independent project space for documenting hands-on experiments across software, robotics, infrastructure, fabrication and creative technology.
It is intentionally a workshop rather than a showroom. Some projects will be polished. Others will be half-built, under test or heading back to the drawing board. That is part of the point.
Public material is deliberately separated from private, customer, employer and production information.