Collaborative robots were introduced with a promise that appealed enormously to small manufacturers. No cage, no integrator, no programming expertise. Unbox it, show it the motion by hand, and let it work next to a person. The promise was not false, but it was simplified in ways that have caused a good deal of disappointment, and the simplification concerned safety and speed rather than capability.
What makes a robot collaborative
A conventional industrial robot is fast, strong and blind to its surroundings, which is why it lives behind a fence with interlocked gates. A collaborative robot is built so that contact with a person does not necessarily cause injury. It achieves this through limited power and force, torque sensing in each joint that detects unexpected contact and stops, rounded surfaces without pinch points, and conservative speed.
The critical misunderstanding is this. The robot is not inherently safe. The application is either safe or not, and that depends on what the robot is holding, how fast it moves, what it is moving toward and what a person might be doing nearby. A collaborative robot carrying a sharp tool or a hot part is not a collaborative application regardless of what the robot’s own specification says.
This is why a risk assessment of the complete application is required, and why the published safety standards address collaborative operation as a set of methods rather than as a property of a machine. The outcome of that assessment may well be that some guarding, a light curtain or an area scanner is needed after all, which surprises buyers who were told none would be.
The speed question nobody raises at the demonstration
Safety in collaborative operation is achieved largely by limiting speed and force. Those limits are real, and they mean a collaborative robot performing the same motion as a conventional one takes substantially longer.
The consequence is that cycle time estimates based on a demonstration where the robot runs at full speed with nobody near it may not survive contact with an application where a person is genuinely present. A common and sensible resolution is speed and separation monitoring, where an area scanner allows full speed while the space is clear and slows the robot when someone approaches. That restores much of the throughput and adds the sensing cost back.
Where collaborative robots genuinely excel
Machine tending is the strongest case. Loading and unloading a lathe, mill, injection moulding machine or press is repetitive, often ergonomically poor and frequently the reason a skilled machinist spends their day watching a spindle. Cycle times are governed by the machine rather than the robot, so the speed limitation costs little.
Palletising and packing at modest rates suit it well, as does assembly of small parts where force sensing is an advantage rather than a constraint, since a force controlled insertion can find a hole that a position controlled motion would jam against. Inspection and test handling, dispensing, screwdriving and laboratory sample handling all appear regularly.
The common thread is low to moderate cycle rate, modest payload, a need for flexibility across product variants and a working environment shared with people. Where throughput is the dominant requirement and the task is fixed, a conventional robot behind a fence remains faster and cheaper per part.
What the easy programming claim really means
Teaching positions by hand guiding and sequencing them in a graphical interface is genuinely much easier than text based robot programming, and the claim is fair as far as it goes. A simple pick and place can be set up in an afternoon by a production engineer with no robotics background.
What the claim understates is everything around the motion. Gripper selection and design for the specific parts, which is where a surprising share of project effort lands. Part presentation, because a robot needs to know where a part is, and the cheapest way to achieve that is a fixture rather than a vision system. Communication with the machine being tended, including door opening, chuck clamping and cycle start interlocks. Error recovery, meaning what the cell does when a part is dropped or a gripper misses, which is where a cell that works in a demonstration differs from one that runs unattended.
These are the same considerations that make part presentation such a decisive factor in any automation project, as set out in our note on how small manufacturers decide what to automate first.
Doing it well
Pick a first application where the robot tends a machine rather than working elbow to elbow with a person, because that is the configuration with the best payback and the simplest safety case. Fixture the parts. Buy the gripper deliberately rather than taking whatever came in the bundle. Expect to spend as much effort on the periphery as on the robot. Have the risk assessment done properly by someone competent, and treat any resulting guarding requirement as information rather than as a failure of the concept.
And build the financial case with the full installed cost rather than the robot price, in the manner described in our piece on the real payback period on a factory automation project. General background is summarised in the overview of collaborative robots.
Frequently asked questions
Can a collaborative robot always be used without guarding?
No. Safety depends on the whole application, including payload, tool, speed and what people nearby are doing. A risk assessment may still require guarding or area sensing.
Are collaborative robots slower?
Yes, because safety is achieved partly by limiting speed and force. Speed and separation monitoring can restore much of the throughput when nobody is nearby.
What is the best first application?
Machine tending, because the cycle is governed by the machine rather than the robot, the ergonomic benefit is clear and the safety case is straightforward.
Is programming really that easy?
The motion programming is genuinely much easier. Gripper design, part presentation, machine interlocks and error recovery are where most of the project effort actually goes.
When should a conventional robot be chosen instead?
When throughput dominates and the task is fixed. A caged conventional robot is faster and usually cheaper per part in that situation.