Part 1 - Type text, robot engraves it

In the winter term 2025/2026, I worked on a semester-long university project that became the foundation of EngaVis: let a user type text on a PC and have a KUKA robot engrave or draw it onto parts at defined positions. When I first scoped the problem, two solutions came to my mind.

The first one was to write a dedicated program for each character in the alphabet, which is simple in concept, but immediately problematic. I’d need to write around 70-90 programs just to cover basic characters. Each one would also need to accept position parameters to offset coordinates, otherwise I could only draw at a fixed location. On top of that, character size would also be hardcoded, requiring separate programs for every size variant.

While I could perform all these transformations inside KRL (KUKA Robot Language), but KRL is a limited language designed primarily for telling the robot to move from point A to point B and interact with tools. My gut told me this path would become an unmaintainable mess fast.

This led me to the second solution: vectorise all characters, calculate their positions, and transform (e.g. translate, scale) these coordinates programmatically, then send the resulting motion commands to the robot. To make the second approach work, I used a KUKA add-on package called EKI (Ethernet KRL Interface). EKI allows an external computer to send motion commands directly to the KUKA controller over a standard network connection. The robot side simply reads the incoming data and executes the commands.

This splits the system into two subsystems:

• The command generator: Takes the user’s input text, vectorises the characters, and derives all motion commands (such as LIN for linear movement and PTP for point-to-point movement).
• The command sender: Transmits those commands to the robot controller via TCP, which EKI supports natively.

EKI supports either XML or binary data formats. After weighing the options, I chose binary for two reasons. First, binary is more compact, therefore, I could pack more commands into a single packet. Second, and more importantly, since the command generator is independent of any KUKA-specific format, it could be reused with robots from other manufacturers. After some research, I found that binary is widely supported across the industry, making it the obvious choice for a vendor-agnostic design.

However, there was one remaining problem: I couldn’t simply append commands one after another into a raw binary stream. Doing so would make future extensions (new command types, new robot integrations) brittle and difficult. I needed a defined structure, a protocol that defines how data is structured and validated. My idea was to use this protocol to make the system predictable, extensible, and clean.

Designing that protocol became the next challenge, which I’ll cover in Part 2.