A program written for an ABB robot will not run on a KUKA, a Fanuc or a Universal Robots: it has to be rewritten from scratch. Each maker keeps its own language: ABB uses RAPID, KUKA uses KRL (KUKA Robot Language), Fanuc uses TP for teach-pendant programs and KAREL for more involved logic, Universal Robots uses URScript. For robot arms there is nothing like IEC 61131-3, the standard that unified PLC programming. Anyone who needs the same cell to run on different brands pays for this fragmentation in specialist hours and in skills that do not move from one controller to the next.

Context

The fragmentation is not accidental. Robot languages grew up around their controllers, and each controller has its own execution model: exception handling, coordinate systems, digital I/O, motion primitives. RAPID and KRL are full imperative languages, with types and modules; URScript is a Python-style scripting language documented in the e-Series manual; Fanuc’s TP is a numbered-instruction format built for the teach pendant, with KAREL as the procedural layer underneath. The motion primitives resemble each other in concept — joint move, linear move, blending between points — but they change in syntax, in units, in the semantics of approximation zones, and in how a target is expressed (joints, Cartesian pose, user frame).

Offline programming tools have stepped over these differences for years. RoboDK and Visual Components keep libraries of post-processors: you build trajectories and logic in a neutral environment, and a controller-specific post-processor emits native code — .mod/.prg for ABB, .src for KUKA, .ls/.tp for Fanuc, .script/.urp for Universal Robots. Visual Components lists post-processors for more than twenty brands. On the open-source side, ROS-Industrial brings ROS into industrial automation with drivers, URDF models and MoveIt packages for the manipulators of the major makers.

Architecture

The two worlds abstract at different levels, and that is the interesting part.

The post-processor model abstracts downstream, at the source code. The authoring environment holds an internal representation of the trajectory; the post-processor translates it, serialising it into the dialect of the target controller. The generated program then ends up on the controller like any hand-written program: at runtime the robot is self-contained, and the external tool only served to produce the file. It is the right model when the cell must stay independent after deployment.

The ROS-Industrial model abstracts upstream, at the command interface. Here no native code is generated: a joint_trajectory node sends joint-position commands to the controller, and a robot_state node publishes position and status read back from it. The exchange goes over the simple_message protocol, described in REP-I0006. The protocol’s design constraint is spelled out in full: it must be decodable “with the limited capabilities of the typical robot programming language without overwhelming the limited resources of the robot controller”. So a small server written in the native language — RAPID, KRL, KAREL — runs on the controller, speaks simple_message, and turns commands into motion. The planning stays outside, in MoveIt; the controller executes.

The critical point

The level you abstract at decides what is portable and what is not.

With post-processors the program is portable: the same trajectory design produces source for different controllers, but at runtime the behaviour depends entirely on how each controller interprets that source — blending, accelerations, singularity handling. Two robots of different brands, starting from the same authored trajectory, can move in markedly different ways, because the motion semantics live in the firmware, not in the file. The translation is static: whatever the post-processor cannot express in the target dialect does not get through.

With ROS-Industrial the application that drives the robot is portable, not the resident program. The high-level logic — planning, collision avoidance, vision integration — is written once above the abstraction, and stays portable as long as a driver exists for that controller. The cost is that the robot is no longer self-contained: it depends on an external computer and a communication channel, and on a production cell latency and reliability weigh. The native driver, then, has to be written and maintained for each controller, and that is where each maker’s idiosyncrasies resurface.

In both cases there remains a fixed point you cannot escape: the low-level motion semantics — how a controller blends two segments, how it handles a wrist singularity, how it treats joint limits near the edge of the workspace — cannot be captured in full in a shared model, because it is not documented uniformly and partly lives in proprietary firmware. Any cross-brand abstraction is exact on kinematics and approximate on dynamics.

Implications

Whoever designs a cross-brand abstraction layer does not first ask which brands to include, but which level to bind the shared model to. Abstracting at the source gives self-contained robots and static translation, with runtime behaviour delegated to firmware. Abstracting at the command gives portable applications and runtime control, at the cost of an external computer and a driver to maintain for each controller. An intermediate layer — a neutral model of trajectory and I/O, with interchangeable backends that, depending on the deployment, emit source or drive via a driver — can be built, but it multiplies the surfaces to test: every primitive has to be validated on real firmware for every controller, because documentation alone does not guarantee equivalence. A concrete case of this intermediate layer, applied to a web-based multi-brand robot programming software for ABB, KUKA, Fanuc and Universal Robots, is described in noze’s insight on the YK-Robotics startup: https://www.noze.it/en/insights/yk-robotics/.

Limits

All of this concerns kinematics and the command flow, not cycle times or functional safety. Conformance to ISO 10218 for industrial robots and certified safety functions (protective stops, speed and space limits) stay tied to the controller and its safety chain: no abstraction layer makes them portable, and none should try. Translating a trajectory between brands is a problem of geometry and code emission; the guarantee that the robot stops when it must stays where the maker put it.

Cover image: Yellow FANUC industrial robot arms operating on an assembly line in a factory — photo by Steve Jurvetson, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:FANUC_Robot_Assembly_Demo.jpg