Dear Readers!

I’m happy to announce that I have successfully completed a classroom programming course for KUKA industrial robotic arms, which also culminated in a state-recognized certificate. The course was held by professional robot programmers at a company site, which meant that we (the students) didn’t only receive a thorough theoretical background, but there was also plenty of chance to test our knowledge on a real-world robotic arm (see image below) with professional guidance. In fact, each day consisted of two halves: a theoretical half, and a practical half, where the former consisted of both receiving new knowledge and test questions, whereas latter was used to further reinforce everything we learned earlier that day. I was especially happy about this sort of course structuring, especially considering, that each student was given plenty of chance to go through all the learning exercises on a real robot.

Kuka RobotA KUKA robotic arm placing a test object onto a conveyor driven cart

The image above depicts one of the aforementioned learning exercises, where we had to write a control program for both the arm and the conveyor system to be able to pick/place pieces from/to a storage crate in order to fill/empty conveyor carts depending on their fill state. It was really amazing to see how fast and in the same time how precisely such robotic arms can work! For instance, the arm could empty or load such a cart in just a few seconds (despite the storage crate being on the opposite site of the robot at a much lower height), if maximum speed would’ve been employed (in test/learning environments maximum speed is not allowed). Even at speed restricted to 30%, it was really fast.

Also, there were quite a few interesting (or even surprising) things I learned about robotic arm programming. One such thing was, that in the robot world the shortest (straight) path between two points is not necessary the quickest (in time) path. In many cases the tool can traverse some bent path much quicker than a precisely held straight path, which is a result of how the different axes work together.

The line of interesting things doesn’t stop here. For example, the robot controller supports running two control programs in parallel. One is used to control the arm, and the other can be used for pretty much anything, like controlling external devices. We had a chance to explore this freature as well, and probably the most interesting experience (from a programming perspective) to me came from this: I just found out how challenging it can be to write concurrent programs with basic language features only. Let’s explore this a bit:

In the aforementioned conveyor loading exercise, the robot control program and the conveyor line control program were running in these two separate threads. To make things a bit more difficult, the two threads have very different cycle times, meaning that we had to find ways to exchange data safely between these two threads in order to make the conveyor system and the arm work together as intended. This is quite challenging when even basic sync features, such as mutexes are not available. As a side note, this experience added a considerable amount of appreciation (from me) towards what A. Williams and co. achieved for making C++ concurrency viable. If you’d like to quickly find out what C++ has to offer from this perspective, please read my two overview posts here and here about it.

Of course, the lack of sync featres makes programming harder than it should be, and life seems to iron these problems out by utilizing other tools to build such control systems, as I found out. It seems that the program running on the robot controller is usually kept as simple as possible, which means that the robotic arm simply takes the role of yet another advanced actuator to be controlled by a PLC, very much like a variable frequency drive controlled machine. It is so much true, that even error handling seems to be done in the PLC, as in case of an error the robot program should simply send an error signal (and probably stop), then let the PLC decide what to do next.

There were some strange things as well, like finding out how different development tools can be across the industry. For instance, the KUKA teach pendant code editor was extremely simple, it didn’t have syntax error highlighting or indentation support at all. If one wants to code with such very common features, one has to use the desktop DE provided by KUKA (which is free to download by the way). Also, it was really suprprising to me, that it didn’t support showing variable values in-line during runtime. Instead, one has to go into menus and open up a separate window to be able to actually check what is stored inside a particular variable. I’m not sure why such basic features aren’t supported on the teach pendant, but my guess is, that the pendant is only meant to be used for final checking and fine-tuning of the code. Or maybe not, I’m not really sure.

There were of course many other interesting things I learned, like physical limitations of arms, different arm tools, some industrial trends, etc, but this post is getting quite long, so I’ll wrap it up now. All in all, I was very happy with this course and I think this was time extremely well spent.

As always, thanks for reading.