Search the Community

I've been supporting the implementation of a Kassow KR1410 collaborative robot for a pack out application, I wanted to provide some tips on integrating a collaborative robot based on my experiences. Fully understand the system requirements I cannot emphasize how important it is to understand the system requirements, or if there is a machine that already does a similar job it is very important to study that machine and fully understand the process. After I’m confident in the requirements, I try to come up with a plan or a sequence in my mind on how I should be programming the robot, which brings me to the second step. Make a sequence of operations document Write down the sequence of operations. This is different from how the machine is going to work, this is how components of the machine are going to communicate. Take a look at the snippet below; This sequence can be tweaked when actually programming the machine. Often there are multiple programmers working on a machine so for example it is good to have a document where the PLC guy understands what the Robot guy is going to do in their program, and vice versa. As you can see in the snippet above, feel free to assign the I/O and registers on how the communications are going to work. Write pseudocode For those who don’t know what pseudocode is, it’s just a simplified program. This step cuts down the time that’s spent on the machine by a lot. I usually have most of the program already written out before I even start working with the cobot. Take a look at the code below, it’s mostly comments but now I know what exactly I need to program. Work with the cobot and machine After having the pseudocode, I go on the machine and start by setting up all my communications, Modbus, TCP/IP, check digital I/O, etc.. Next, I start teaching positions and building the sequence step by step. Test I am not going to call this the last step because you would be more successful if you have already been testing along with the rest of the above steps. Whenever I feel like a part of the program is done, I test to make sure that part works. This works well when you’ve written your code in a modular way. For example, the main program that I run on the robot will only consist of several lines. I usually have two loops, one that runs once, my initialization loop, and a loop that has my main program that always runs. In the initialization loop, I make sure all my variables are reset, I read all the sensors tied in and make sure I am aware of everything that is going on that the robot should know. This should happen only once in the program. My main loop is most often a “while (1) loop”. This is an infinite loop that never ends, unless I call a “break” from the loop. This break prevents me from getting stuck anywhere inside my program and I never leave the robot in a state that’s not great. For example, I always try to go back to a home or safe position when a task is complete. One situation where I make this loop to rely on a variable is if I have another controller, a PC or a PLC that tells the robots what to do. Going back to the testing, (it is really hard but) make sure to try to account for all cases that can happen. This could be safety related, operation related or even part related. Testing all the “what-if” scenarios can be the most time consuming but the more you test the lower your risk of unexpected problems later. I believe that everything seems very complicated until you break it down into pieces and tackle them one by one. With these 5 steps, hopefully it will be easier for you to implement a collaborative robot. If it still seems confusing or you need any help following these general steps, please reach us at https://www.gibsonengineering.com/ or leave a comment below!