Vantage Arm Digital Twin

The challenge

Dry_Run started from a robotics prompt: make a Vantage Robotics stylus arm visible, controllable, and testable before any real hardware is connected. The implementation is a browser-based digital twin where the robot, keypad, motion state, safety checks, and control panels all run as one coherent simulation.

The important design choice is that every mode touches the same robot. Manual jog, voice commands, agentic plans, autonomous PIN entry, and replay do not maintain separate ideas of where the arm is. They all propose structured motion, pass through the same validation boundary, and update the same Zustand-backed robot state.

One controller for every control surface

The arm can be moved directly through Cartesian targets, joystick jogs, keyboard jogs, voice commands, a Gemini-powered planner, an autonomous PIN state machine, or a recorded motion replay. That sounds like many features, but the runtime is intentionally narrow: every surface is converted into an explicit command or target, then sent through ArmMotionController.

That controller owns the real robotics path: workspace validation, damped-least-squares inverse kinematics, joint-limit checks, forward-kinematics verification, collision tests, and smooth joint-space interpolation. Keeping the pipeline centralized means a feature added for one mode becomes a safety property for all modes.

Agentic, but not trusted with safety

The agentic mode uses Gemini to translate free-form instructions into strict JSON commands. The model never executes motion directly. Its output is re-parsed, schema-checked, policy checked, and then passed through the same safety gateway as hand-authored commands.

That distinction matters. The LLM is useful for intent translation, but the deterministic robotics layer remains the authority on reachability, limits, collisions, emergency stop state, and command ownership.

Autonomous PIN entry

The PIN flow accepts exactly six digits, maps each digit to the configured 3D keypad position, and creates approach, contact, hold, and retract waypoints for each press. Before the arm starts, the system preflights the whole sequence so an unreachable key fails early instead of halfway through a demo.

The state machine also supports pause, resume, stop, and emergency stop. Those controls are not bolted onto the UI; they interact with the same ownership lock and motion cancellation logic used by manual control and replay.

Safety in the scene

Collision checking uses simplified link capsules, obstacle boxes, safety zones, and reach envelopes. It is not an industrial motion planner, but it is the right fidelity for a browser digital twin: enough geometry to catch unsafe paths, visualize the failure, and teach the user why the command was rejected.

The Three.js scene is only the view. Meshes follow the store instead of becoming a second robot model, which keeps the dashboard, joint readouts, stylus-tip coordinates, and rendered arm synchronized at all times.

Hardware bridge

The repository also includes a Wokwi ESP32 DevKit V1 schematic for a six-servo arm layout. That makes the project more than a visual mock: the simulated joint model, command pipeline, and safety story have a concrete hardware direction even though the current app does not send commands to a physical robot.