Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@robotarm Move the cup from station 2 to station 3 with the left hand."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A dual-arm robot with a camera and dexterous hands, planned by Claude through MCP, executed by a local learned policy (LeRobot) and kept safe by real-time firmware.
Claude decides what to do ("move the cup from station 2 to station 3 with the left hand"). A local policy decides how to move the fingers, 30 times per second. The firmware closes the loop on every joint at 1 kHz and owns every safety limit.
flowchart LR
subgraph Cloud
C[Claude<br/>planner<br/>1–3 s per decision]
end
subgraph "Local PC"
M[MCP server<br/>this repo<br/>< 5 ms]
P[Policy<br/>SmolVLA / ACT<br/>~30 Hz]
V[Detector<br/>YOLO + ArUco]
end
subgraph Robot
F[Firmware<br/>PID, limits, e-stop<br/>~1 kHz]
S[Servos + encoders]
K[Cameras]
end
C -- tool call --> M
M -- result + scene --> C
M -- task --> P
P -- joint targets --> F
F -- PWM / current --> S
S -- position, current --> F
K -- frames --> P
K -- frames --> V
V -- scene JSON --> MClaude is the planner, never the controller. It sees the scene as JSON (plus an image only when needed), calls a small set of tools and reads back a result code. It is never in a real-time loop.
Objects live in fixed stations. Every object the hands handle sits in a numbered station with self-centring guides and an ArUco marker. Claude addresses stations, not coordinates. This removes most of the uncertainty in manipulation.
Safety lives in firmware and hardware. Joint limits, current limits, watchdog and the e-stop are enforced below every layer that can be wrong, including Claude and the policy.
Same interface from simulation to the real arms. The MCP layer talks to a Backend;
the simulated backend, the SO-101 test arms and the custom arms all implement it.
Related MCP server: mcp-esieabot
This image was enhanced with AI (neural rendering) from the CAD concept. It is an illustration, not the engineering model: details such as the spray bar, control cabinet and signage are artistic and may differ from the final design.
Created with Autodesk Inventor. Dimensions and parts are not final.
Rotating reel and dual-arm carriage: twelve cultivation tubes mounted on two 12-spoke hubs around a central shaft. The reel rotates to bring each tube to the arms. Both arms sit back to back on one sliding carriage that runs along a rail above the reel.
Dual-arm carriage on the rail:
The reel has no motor: the arms turn it by pushing pegs on the hub, a ratchet keeps it from rolling back, and a spring latch locks it at each of the 12 positions. Design decision.
First 3D sketches, also created with Autodesk Inventor.
Reel-shaped grow rack with the arm: cultivation tubes arranged as a reel on a steel frame, with the arm mounted beside it.
Arm: base joint with a large stepper and housing, two links, and smaller steppers at the elbow and the wrist.
Phase | Goal | State |
0 | Repository, specs, MCP server with simulated backend | ✅ this commit |
1 | Validate the pipeline on LeRobot SO-101 arms | planned |
2 | Record datasets, train a manipulation policy | planned |
3 | Design and build the custom arms and hands (Autodesk Inventor) | planned |
4 | Integrate cameras, stations and Claude on the real cell | planned |
Details and exit criteria: docs/roadmap.md.
git clone https://github.com/walcorg/robotarm-lab
cd robotarm-lab
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest -q
# Register the MCP server with Claude Code and talk to the simulated cell
claude mcp add robotarm -- robotarm-mcp --backend sim
claude
> Move the cup to the handover station, then pass it to the right hand and put it in outbound.
> Then bring tube 7 to the arms.--grip-fail-rate 0.3 makes the simulator drop grasps and --latch-fail-rate 0.2 makes the
reel latch miss, so you can see how Claude recovers.
Path | Contents |
| MCP server, validation controller, backends ( |
| Stations, hands and reach; initial objects for simulation |
| Architecture, MCP tool spec, scene schema, safety, roadmap |
| Animated view of one decision travelling from the model to the servos |
| Inventor sources and exports for arms, hands and workcell |
| Joint controller firmware (requirements first, code in phase 1–3) |
| LeRobot configs, dataset notes and trained policy cards |
Architecture: layers, timing budget, interfaces
MCP tools: every tool, its arguments and result codes
Scene schema: the JSON Claude reads
Safety: what each layer is allowed to do
Reel indexing: why the arms turn and lock the reel
Roadmap: phases and exit criteria
Software (everything outside hardware/): MIT
Hardware designs in hardware/: CERN-OHL-W-2.0
© 2026 WALCORG
Turn the cultivation reel forward until tube (1-12) faces the arms. The arms turn
it themselves; both hands must be at home and the operating hand empty.
Inputs: tube (required), hand.
Current objects per station, what each hand holds, and whether the cell is stopped.
Inputs: no named parameters.
Stations (id and label) and which stations each hand can reach.
Inputs: no named parameters.
Return a hand to its home pose without releasing what it holds.
Inputs: hand (required).
Move the object in from_station to to_station with one hand ('left' or 'right'), then return that hand home. Nothing moves if the plan is impossible.
Inputs: hand (required), to_station (required), from_station (required).
Grasp the object in a station. Use for hand-overs; prefer move_object otherwise.
Inputs: hand (required), station (required).
Release the held object into an empty station.
Inputs: hand (required), station (required).
The last n actions with their result codes.
Inputs: n. Returns: result
Clear a software stop. Only call after the human confirms the cell is safe.
Inputs: no named parameters.
Advance the reel a number of positions with one hand. Forward only (ratchet). Prefer bring_tube unless you need an exact number of steps.
Inputs: hand (required), steps (required).
Halt all motion immediately. Latches until reset.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Scored across 11 tools
Most tools target distinct operations, but pick/place/move_object and bring_tube/rotate_reel overlap somewhat in manipulation and reel control. The descriptions explicitly resolve these boundaries by recommending move_object over pick/place for normal transfers and bring_tube over rotate_reel unless exact steps are needed.
All names use snake_case, but the set mixes bare verbs (pick, place, home, stop, reset) with verb_noun names (move_object, bring_tube, rotate_reel) and a noun-like name (recent_actions). The convention is readable but not a predictable verb_noun pattern throughout.
Eleven tools is well within the expected range and each appears to earn its place: state inspection, movement, pick/place, homing, reel control, emergency stop, reset, and action history. The surface is neither bloated nor thin for a robotic workcell controller.
The set covers sensing, manipulation, reel handling, safety stop/reset, and audit history, which is strong lifecycle coverage for the domain. A notable minor gap is the lack of a direct reel-state query, such as which tube currently faces the arms, though agents can partially work around it via bring_tube or recent_actions.
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.
Deploy sims to any screen. Control your displays with Claude.
Deploy sims to any screen. Control your displays with Claude.
Connect your AI to your own devices, 3D printers, factory tools and a shared agent task pool.
