Industrial robot digital twin

Why the geometry is entered by hand

The decision the whole project rests on is that you model the kinematic chain, whatever the arm. The interface asks two things before it draws anything: how many axes the arm has, from two to six, and how long each link is in centimeters. With those two answers the software assembles the chain and solves the equations, and that is where the hard work lives. Forward kinematics tells you where the tip ends up when you rotate the axes; inverse kinematics tells you how much each axis has to rotate for the tip to reach a point you chose. The second one does not have a single answer, and it has to be solved while respecting the rotation limit of every axis.

Writing those equations ourselves, instead of inheriting them from the robot maker's software, is what makes fitting the twin to a different arm a matter of typing numbers again, with no new programming. In the capture of the delivered product the same code carries two arms that look nothing alike: the UR5 by Universal Robots, a slim cobot with round joints, and the GP8 by Yaskawa, a compact industrial arm with different proportions and a different reach.

The two-to-six range is not a round number picked at random either. The client had a six-axis Yaskawa in their lab and asked in writing to start there rather than with the easy case, on the argument that scaling down from six axes to two is simpler than scaling up from two to six. Solving the hard case first is what left the rest of the range solved along the way.

The two ways of defining movement

The twin is driven by hand, with no joystick or coordinate console. The first mode moves the end effector: a cone appears to mark the target, you grab it, you put it where you want the tip to land, and the arm solves the pose to get there. The second mode chains points to define a full route.

Standing at real scale on the floor where the cell would go, that answers in seconds the question that normally costs a site visit: whether the arm reaches, whether the space fits it, and where it is going to travel. The capture shows the arm against the room's spatial mesh, with the tape marker on the floor where the base is anchored.

The link to the robot: what was proven and what was not

This is the part worth stating precisely, because it is the first thing an automation engineer will ask. The architecture was designed to close the loop: the twin generates the trajectory, exports it as per-axis angles, and the physical robot executes it. The bridge was working from Unity to the Yaskawa simulator and to Gazebo, over ROS, and the layer to the controller was specified over OPC UA, against DIN EN IEC 62541-5 and the VDMA OPC UA for Robotics profile.

Commissioning on the physical cell did not happen. With that stage still pending, the client entered insolvency in September 2024 and the project stopped there. We say so because a case that implies a close it never reached does not survive the first technical question: what is proven is the configurator, the kinematics and the bridge against a simulator, and that is the part that is hard to build. The stage that remained was shop-floor commissioning.

Frequently asked questions