From-Scratch Build · 01 · Edge Robotics
A virtual replica of a real robot arm that mirrors its every move in real time — and can be split across a laptop, an edge server, or the cloud. Rebuilt from scratch to understand how robotics, networking and containers fit together.
What it is
A digital twin is a live, software copy of a physical machine. Here the machine is a small six-axis robot arm. The twin runs inside a simulator and stays continuously synchronised with the real arm: when the physical joints move, the virtual ones move with them, and an operator can drive the robot remotely through a web page while watching the simulated copy respond.
I built this around one question that interested me — not "can we simulate a robot" (that's solved) but where should the brain live? The control software is broken into independent pieces that can each be placed on the robot, on a nearby edge server, or in a distant cloud, so you can measure how network latency affects remote operation.
The core idea I wanted to learn: robotics software doesn't have to run on the robot. If you containerise each module, the same system can be deployed on one host or spread across a 5G network — and a digital twin lets you see and replay what the real hardware is doing from anywhere.
The stack
The point of this rebuild was the toolchain. Each of these was new to me; here is what each one actually does in the system.
The Robot Operating System. Not an OS — a messaging bus. Nodes publish and subscribe to topics so the driver, planner and interface can talk without knowing about each other.
A physics robot simulator that hosts the "digital replica" — the virtual arm whose joints are slaved to the real robot's state.
Every module ships as its own container. Compose wires them together, which is what makes the same stack deployable on one host or many.
Precision Time Protocol daemon. When modules run on different machines their clocks must agree to the microsecond, or the twin drifts out of sync.
The robot stack — control, motion planning and interface layers — turns "go here" into safe joint trajectories.
A browser GUI for tele-operation, so an operator anywhere can drive the arm and watch the replica react.
Architecture
The digital-twin service is assembled from six containers. Five exist and run; the sixth I've left as future work — a reminder that ambitious builds are never quite finished.
The registry. Provides naming and discovery so every other module can find the topics it needs.
The hardware layer — reads sensors and commands the actuators of the physical arm.
Control, motion planning and interface. The decision-making brain that can be relocated to the edge or cloud.
The CoppeliaSim virtual arm that mirrors the real one — the "twin" itself.
The remote-operation GUI in the browser.
Would replay the last 30 seconds of operation in a separate virtual object. Left as future work in this build.
How it runs
Deployment is the whole game. The build ships scenarios — Compose files describing where each module lives:
In my rebuild I focused on the single-host path: bring up the ROS master, attach the drivers and stack, launch the replica in the simulator, and open the web interface — all through one docker compose up.
Reflection