How to Program a Robot Conveyor Without Going Crazy

program robot conveyor

Programming a robot conveyor is trickier than many people imagine. Good simulation is the key to success, but how do you do it without going crazy?

Conveyor belts are an easy way to move products to your robot, right?

Well… not really. We often think of conveyors as a simple solution but, in actual fact, they are one of the more complicated methods of workpiece delivery. They require the robot to detect and track objects moving on the conveyor. They need to be controlled via the robot program. They also suffer from various mechanical issues over their lifetime, like poor tracking, belt wear, and slipping. All these mean that conveyors can drive you a little crazy.

Instead of being simple, they can be tricky to use.

We can’t solve the mechanical issues of your conveyors — for that, you need a good maintenance schedule like the one shown in this handy checklist from Cisco-Eagle. However, we can help you to simulate the conveyor easily so that you can test it and integrate it with your robot programming.

Here’s how to program your robot conveyor without going crazy.

The 5 Tricky Moving Parts of a Robot Conveyor

First, it’s important to understand why programming a conveyor is challenging.

There are 5 “moving parts” which make it hard to integrate robot programming with conveyors.

1. Control of the conveyor itself

It might look like conveyor control is just an “on/off ” deal but it is usually a bit more complex than that. Conveyors have a variety of control options, depending on the model. Some have a fixed speed whilst others can be controlled with variable speeds. Some have a reverse mode, active braking, or fast switching. Then there are different control methods, the three most common being pulse control, velocity control, and distributed control.

You may have to control the conveyor inside the robot program itself. If not, you may have to interface with the conveyor through a network. Both of these options add programming complexity.

2. Tracking and detection of objects

In order to pick up objects from a moving conveyor, the robot must be able to reliably locate them. This means you need some sort of sensor to detect when an object arrives in front of the robot. What’s more, the robot may need some way to track the objects as the conveyor moves.

The most common sensors for this are vision sensors (e.g. 2D or 3D cameras) and part detection sensors (e.g. light beams, magnetic sensors, inductive sensors, etc). Some are simpler to integrate than others but all of them add extra complexity to your program.

3. Handling moving objects

A moving target is always harder to handle than a static one. This introduces complexity when grasping from a conveyor belt. The robot must be able to move into position, grasp the object firmly, and move away while new objects keep arriving.

The speed of the conveyor must be precisely tuned to the speed of the robot, otherwise objects may be missed. If you have seen the famous “chocolate scene” from the 1950’s comedy I Love Lucy, you’ll know what I mean (and here it is if you haven’t seen it yet).

4. End effector choice

The robot arm is not the only part of the system which needs to keep up to speed. The end effector can have a significant effect on the cycle time and, thus, the speed of the conveyor. Some types of end effector are faster than others.

This means that we now have to control and coordinate 3 independent speeds simultaneously: the conveyor speed, the robot arm velocity, and the end effector grasping speed.

5. Use of fixtures

The final moving part is, actually, not a moving part at all. Fixtures are static mechanical parts which are fixed to the conveyor to move the objects into position. They are a reliable way to order the objects on the conveyor without using sensors.

For example, you can use a fixture as an alternative to using a vision sensor. With specially formed sheet metal, you can funnel objects into a static queue, allowing the robot to pick them up without extra sensors. They make programming simpler, but they increase the complexity of the mechanical design.

How to Simulate a Conveyor With RoboDK

You can overcome the five challenges above by simulating your robotic system and testing it thoroughly before you use the physical system. This is not always easy with robot simulators, many of which do not have a simple capability for adding conveyors.

Thankfully, conveyors are pretty simple in RoboDK. There are even two options for adding them, depending on how much control you need.

The two types of conveyor in RoboDK are:

Option 1: Python programming

The most flexible method of creating a conveyor in RoboDK is to program it in Python. You can see this in action in the example video Conveyor Simulation with RoboDK.

Advantages of python programming are:

  1. It is very flexible. The movement of the conveyor is only limited by your programming skill. You can program the simulated conveyor to match the properties of your real belt.
  2. It is completely customizable. You can program the conveyor to move in whichever way you want. You have complete control over its movements and how it handles objects.
  3. It allows for more complex conveyors. If your conveyor has advanced control modes, these can be included in the python code. Also, if you have placed a fixture to move objects to the side of the belt, for example, this can be programmed into the code.

Disadvantages of python programming are:

  1. It requires programming skill. You have to be able to program in python. This is one of the easier languages to learn, but it still requires a learning curve if you have only used RoboDK’s graphical interface up to now.
  2. It takes a bit longer. Compared to the linear mechanism option, python programming does take time. Plus, the more complex your conveyor the longer it will take to program.

Option 2: Linear mechanism

The other option is to create a linear mechanism using the “Model Mechanism” wizard. This allows you to create a simple conveyor with a single linear axis.

Advantages of the linear mechanism are:

  1. It’s quick. You can create a linear mechanism in a matter of minutes and add the conveyor to your robot simulation very quickly.
  2. It uses the graphical wizard. You can create the mechanism using the wizard using only reference frames and targets.
  3. It requires little to no programming. You don’t have to do any python programming to create the conveyor. However, be aware that you will probably have to do some programming to detect objects on the conveyor.

Disadvantages of the linear mechanism are:

  1. It is limited. The simple nature of the mechanism means that you can only model a single axis conveyor.
  2. It is inflexible. This option makes it hard to model the more advanced control options of your conveyor. It also makes it hard to detect when objects fall from the conveyor.

How to Get Started

Which option you choose largely depends on much you want to avoid python programming. Unless you have a good reason to choose the linear mechanism, we would usually recommend picking the python option. It is far more flexible and — I think (though I am a programmer) — it is easier to understand and implement.

Whichever option you choose, you don’t have to create the conveyor simulation from scratch.

We have both options available for download in our Robot Library. Just pick “Object” from the “Type” menu and you will see the two options: “Model Python” for the python option; and “Model Mechanism” for the linear mechanism option.

If you get stuck, you can always post a comment on the RoboDK Forum and we’ll do our best to help you out.

Alex Owen-Hill

About Alex Owen-Hill

Alex Owen-Hill is a freelance writer and public speaker who blogs about a large range of topics, including science, presentation skills at, storytelling and (of course) robotics. He completed a PhD in Telerobotics from Universidad Politecnica de Madrid as part of the PURESAFE project, in collaboration with CERN. As a recovering academic, he maintains a firm foot in the robotics world by blogging about industrial robotics.

View all posts by Alex Owen-Hill

Leave a Reply

Your email address will not be published. Required fields are marked *