5 Easy Ways to Avoid Robot Collisions (& a last resort)

Production line with KUKA robots

How do you stop your robot from colliding with objects in its workspace? Here’s how to avoid robot collisions without making life hard for yourself.

A recent question over on the RoboDK Forum highlighted a common issue with robots. User Micronexx asked how to avoid collisions. They asked if RoboDK generates collision-free paths automatically, or whether the user has to make manual adjustments.

This is a more complicated issue than it first appears. RoboDK does certainly include functionalities which help you to avoid collisions, including some automatic routing. However “collision avoidance” in robotics is a deep and complex topic. Entire research projects are devoted to trajectory planning and collision avoidance. Advanced Artificial Intelligence algorithms have even been developed for it.

The good news is that, for most of us, things don’t have to be so complicated. There are easier ways to stop your robot colliding with objects.

5 Easy Ways to Avoid Robot Collisions

It’s usually best to start simple.

This is a good rule-of-thumb when trying to solve any problem in your robot programming. Even though robots are capable of advanced functionality, the simple engineering solutions are often the best.

Here are 5 simple ways to stop your robot colliding with objects.

1. Plan Your Workspace Properly from the Start

Collisions occur most often when the workspace hasn’t been well planned. You should start any robot integration by planning the space, e.g. by sketching it out on paper.

Plan which areas the robot will move around in and which areas will be outside of its reach. Try ‘acting out’ the robot’s sequence of motions with your own arm before you start to program them into the robot — this is a very effective method for reducing potential issues before they arise, and it’s very quick to do.

2. Physically Remove Potential Obstructions

The best way to avoid collisions is to ensure there is nothing for the robot to collide with. This means removing anything which could obstruct the robot’s path from the workspace.

Make sure that there is a clear path between different areas of the workspace. If the robot will pick up objects from one location and assemble them in another, remove everything from the workspace between these two locations.

This may seem obvious, but it is easy to forget to do it when you are using offline programming. For example, you might see a pillar in the robot workspace and say “It’s okay. I’ll just avoid it in the robot program.” But then, because you are programming in a simulated environment where the pillar doesn’t exist, you forget about it and program the robot to move right through it.

3. Match the Real World to the Simulation

The real world and the simulation within RoboDK should be as closely matched as possible. You can achieve this in 2 ways:

  1. Make an accurate model of the physical workspace within the simulation — This involves measuring the precise location of every object and modeling it in the software. It can be extremely time consuming and the more you rely on the accuracy of the simulation, the less room there is for error.
  2. Remove objects from the real world that are not in the simulation — This involves simplifying the real workspace by removing objects.

In practice, the best option is a combination of these. You remove all unnecessary objects from the physical workspace and add all necessary objects into the simulation.

4. Tweak Programming Targets Manually

Before you start using complex collision avoidance algorithms, try tweaking the robot’s movements yourself. For most applications, manually moving the targets within RoboDK is a quick, effective, and robust solution.

For example, if the robot collides with an object during a Joint Move command, simply add an extra couple of waypoints to avoid the object. Or — even better — ask if the object really needs to be in the workspace in the first place.

One practice which can significantly reduce collisions is to decide if each movement is a “traveling” move or an “operational” move. Only perform traveling moves in free space where there are no obstructions. Then, stop a small distance away from the operation (aka the “approach distance”) and carefully move into the task before carrying out the operational move.

5. Use the Machining Wizard’s New Feature

Robot machining is one task where you will probably need automated trajectory planning. RoboDK makes it easy to generate machining paths using its in-built machining wizard.

Most of the time, you will not have any collisions if you have followed the advice above. However, there is an option to automatically avoid collisions during the machining operation, which we added in the latest version of RoboDK. Read Albert’s response in the forum which explains how to use this new feature.

This feature avoids collisions by automatically rotating the robot around the z-axis of the tool. As a result, it won’t avoid all collisions but it does improve the robustness of the machining wizard.

Last Resort: Use an Advanced Motion Planner

If you’ve gone through all of the steps above and you have decided that you still need autonomous collision avoidance, it’s time to break out the “big guns.” This means using a third-party motion planning algorithms to generate your robot trajectory.

There are tons of trajectory planners out there which automatically detect and avoid collisions. However, most are very early stage research programs and, as a result, are not very reliable. Also, most are designed for mobile robots which only move in 2-dimensions.

There are, however, a few decent trajectory planners which work for industrial robotic manipulators. Be warned, to use them you will have to do some serious programming.

  1. MoveIt! — MoveIt! is one of the most developed graphical motion planners for robotic manipulation. It uses the OMPL framework and provides an easy(ish) graphical interface. It is integrated into ROS. If you’re familiar with ROS already, this could be a good option. If not, you may have quite a learning curve.
  2. Open Motion Planning Library (OMPL) — It is possible to use OMPL alone, without MoveIt! It provides libraries in C++ and also has Python bindings. There is a reasonable amount of documentation, but it will still involve a learning curve as the library has a lot of functionality.
  3. Bubbles — This is a small library which RoboDK’s CEO Albert Nubiola recommends. It is a stand-alone motion planner for manipulators which uses the probabilistic roadmap algorithm (PRM). It’s written in C++ and has very little documentation. But, if you’re a programming wizard and you’re up for a challenge, it could provide a much less bloated solution to using MoveIt.

In general, it’s better to avoid collisions by using one of the easier methods. But, if you need to use the advanced algorithms, collision avoidance is a fascinating topic.

Which collisions have caused problems for your robot applications? Tell us in the comments below or join the discussion on LinkedIn, Twitter, Facebook, Instagram or in the RoboDK Forum.

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 CreateClarifyArticulate.com, 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 *