Robotic welding / painting

What the service includes

We write control programs for welding and painting robots that already stand on the client's production floor, and we set them up for specific parts and tooling. The work includes building the trajectories of the torch or sprayer, setting the seam and coating-layer parameters, calibrating the tool coordinate system and the base planes, and handling sensor signals. The equipment itself belongs to the customer: their arm welds and paints, while we prepare the logic by which it does so repeatably. Separately we describe the part-changeover scenarios, emergency stops and safe zones, so the line can be reconfigured without rewriting the whole project. The result is handed over as verified code plus documentation on the points, speeds and parameters, tied to the client's machine.

How the work process is set up

Robotic welding and painting come down to the arm guiding the tool along a predefined trajectory with control of speed, angle and distance to the surface. The program breaks the part's contour into reference points and segments, between which the controller interpolates the motion, maintaining a constant linear speed in the seam zone or uniform overlap of passes during spraying. The process parameters (arc current and voltage, wire feed, paint pressure and flow) are synchronized with the position along the trajectory, while sensor feedback corrects deviations in real time. We describe this logic in the controller's code, run it in simulation and on dry passes, then fine-tune it on the metal. The physical work is performed by the customer's equipment; our part is the algorithm and the parameters by which it acts.

Where industrial robots came from

The first industrial robot, Unimate, went to work in 1961 at the General Motors plant in Trenton, New Jersey, where it unloaded a die-casting machine. The machine was conceived by George Devol, who filed the basic patent back in 1954 (granted in 1961), and Joseph Engelberger; together they founded the company Unimation. Robotic welding took shape as a separate field by 1969: at the rebuilt GM plant in Lordstown, Ohio, a resistance spot-welding line on Unimate robots assembled about 110 car bodies an hour. In the 1970s the technology was picked up by European automakers (Mercedes-Benz, Volvo, Fiat), and spot welding of bodies became the first mass task for arms. This pedigree explains why modern welding cells are still built around a repeatable trajectory and stable arc control.

Why the software part is critical

In welding and painting the result is determined not by the arm's power but by the precision of the trajectory and the synchronization of parameters with the motion. A deviation of the torch by fractions of a millimeter or a speed spike in the seam zone produces lack of fusion, an undercut or a burn-through, while an uneven sprayer pass leaves runs and uneven coating thickness. Control of the tool's tilt angle, dwell at corners and smoothness of acceleration directly affects the seam geometry and material consumption. That's why the main engineering work goes into the code and calibration: it's precisely the program that keeps the process within tolerance from part to part. The client's equipment is capable of repeating a movement with high precision, but that precision has to be set correctly and verified, otherwise repeatability works against quality.

What languages we work in

For Universal Robots arms we write in URScript: it's the language of their controller, which sets movements, accesses the inputs and outputs and embeds signal-handling logic right into the control program. For ABB robots we use RAPID, the native language of their controllers, in which the points, trajectories, process parameters and interaction with the cell's peripherals are described. When the task requires machine vision, coordination of several devices or complex processing of sensor data, we bring in ROS2: it links the system's nodes via message exchange and offloads the upper-level logic from the controller. The choice of stack is tied to what equipment the customer has, not the other way around. In all cases the code is written for the client's specific machine and verified on its kinematics and tooling.

When these tools appeared

The RAPID language was introduced by ABB in 1994 together with the S4 controller, replacing the earlier ARLA, and it has since remained the main one for their arms. Universal Robots was founded in 2005 in Odense (Denmark), the first production cobot UR5 reached the market in 2008, and it's controlled by its own URScript language. ROS originated from the STAIR project at Stanford, with the first code commit made on 7 November 2007 at Willow Garage; the next generation, ROS2, got its first stable release, Ardent Apalone, in December 2017. ROS2 was rewritten for industrial requirements of real time, safety and multi-machine systems. These dates show that the stack we work on has been battle-tested by the industry for two to three decades.

Why you can trust this to us

The combined experience of the development team exceeds 45 years in IT, and we approach robots as an engineering task rather than a set of ready-made button presses. Before the production launch the logic is run in simulation and on dry passes, the trajectories and parameters are verified on the client's tooling, and only then does the cell go onto the metal or the coating. We don't manufacture equipment and don't weld ourselves: the customer's machine welds and paints, and we're responsible for the correctness of the program, the calibration and the repeatability of the process. Every project comes with documentation on the points, speeds and parameters, so the line can be maintained and reconfigured without us. This order reduces the risk of scrap and downtime when commissioning a welding or painting cell.