datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

The Top 10 Robotics Application Mistakes

George E. Martin

5/2/2005 12:44 PM EDT

As robot technologies continue to improve and evolve, the choices facing today's robotics buyers continue to expand as well. How do you know what type of robot to choose? And more importantly, how can you avoid mistakes that you may not be aware of, even if you've successfully applied robotics technologies in the past. With investments ranging from tens of thousands to potentially millions of dollars, it's critical to make the right choice the first time, and to avoid common mistakes that could add substantial unnecessary cost or result in project delays. To help engineers and manufacturing personnel avoid the worst pitfalls, I've gathered up the top ten robotics application mistakes I've seen in my twenty years in the automation business.

Mistake 1: Under Estimating Requirements

The number one application mistake made by robot users is underestimating the payload associated with a given application. The most common cause is failure to include the weight of the end-of-arm tool in the payload calculation. The second most common cause is underestimating or completely ignoring the inertia forces generated by off-center payloads. Inertia forces can overload a robot axis. It is very common to overload the rotational axis on a SCARA robot. Failure to correct the problem may also cause damage to the robot.

Reduction of payload and/or reduction of speed parameters could remedy the situation. Reducing the speed, however, may cause an unwanted increase in cycle time—a cycle time which may have been part of the ROI calculations in justifying the purchase of the robot in the first place. That's why it's critical to consider all load-related factors from the very beginning.

Mistake 2: Trying To Do Too Much

Sometimes the awesome capability and flexibility of a robot can cause a designer to over task the robot and make the work cell too complex. The result once again could be failure to make cycle time, or it could lead to extremely difficult programming solutions, or even to difficulties with processor speed limitations. This mistake is further magnified when users other than the system designer try to troubleshoot the work cell once in production. Unplanned down time can be very costly in a production environment.

Another common manifestation of over tasking the robot cell is known as "Project Creep"—adding work beyond the original tasks for which the robot and work cell were designed. This can be especially disappointing if the additional tasks are added after a simulation has been performed verifying the original assumption. If no new simulation is done before proceeding with the project, the intended cycle time may not be reached. Be careful not to increase the scope of work of the work cell beyond the robot's capability within a given cycle time.





Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)