End of Arm Tooling (EoAT)

The subject of robotic arm tooling is important because even the most sophisticated robotic control system is pointless without the ability to grab or manipulate the object for which it was designed.

What Does EoAT Stand For?

It’s usually pretty simple in the robotic world to refer to anything that picks up the object to be called a ‘gripper’ and indeed, there is an entire industry focused on designing robot grippers. However, not every application involved gripping, so a more broadly accepted term for the device attached to the end of the robot arm is called the End of Arm Tool, hereafter called the EoAT.

The robot manufacturers themselves do not usually create the EoAT because of the unique nature of all applications, their business is mass production of a robot. It’s up to the end user to determine how their robot is to be used, and how it should interface with their unique products: aluminum blocks, bags of rice, car parts, you name it.

The design of an end tool involves far more than just a method of grabbing an object. The shape and size of the EoAT will ultimately determine the kinematics of the robot and its ease of teachability.

Common EoAT Design Types

The amount of customization on robot tools is simply mind boggling, and is just as creative as it is diverse. There are a few main categories that most tools fall into, with those categories (divided by simply to my own subjective experience) consisting of external tools simply bolted to the robot, standardized tools with a specific application, and general product pickers, or ‘grippers’ with various power sources.

External Tools: Welder, Spray Painter, etc

Some arm tooling doesn’t need to be designed by the end user, but rather simply bolted onto the end plate of the robot. Think of this as the robot simply hold a normal tool, just like a human worker might. These tools might include a welder or spray painter.

A particular bolt pattern must be supplied, unique to the robot, but aside from that, it’s just a normal welder or painter. The only unique design work is simply a clamp between the tool and the robot end plate, and is usually fairly simple (although robust).

While the assembly of these tools might not be a major challenge, it will be very important to locate the actual point of material application. For a welder, the exact tip may not be the point of application of the weld, but rather a few mm in front of the tip. This geometry will be discussed further in the discussion of teachability and navigation.

Standardized Tools: Screwdriver, Glue Dispenser, etc

A second category is used to attach a standardized tool, like a sanding disk, a screwdriver, or an adhesive/sealant application tip. The tool might have an off-the-shelf design, but the mechanism of attachment must be highly modified to both attach to the robot end plate, but also to avoid collisions with the part while navigating. Perhaps this means attaching the tool at a right angle to the end of the robot, or designing an extension linkage to allow a small tooltip to work a few inches away from the large end face.

This category differs from the welder in the sense that the robot is not simply holding a cordless screwdriver, the screwdriver itself must be configured to accept power and transfer feedback to the robot. In a sense, rather than the human worker’s hand holding a tool, the hand itself is the tool.

In these cases, a mechanical engineer will design a majority of the part, carefully designing around the tool, usually powered by electricity, in order to allow it to work for the individual application. A majority of the project is design work, with the standard component being the basis around which the rest of the project is designed.

Robot Gripper: Jaws, Vacuum, Servo, etc

Finally, and perhaps most common of all, another main category of tools is those used for grabbing an object, much like you would with your fingers or with both hands, often simply called ‘grippers’. These are usually a form of jaws, but for soft or fragile applications, the mechanism might lift the object from underneath. For large, flat objects, like a big piece of cardboard or glass, the robot might reply on suction from vacuum components arranged in the same large, flat array.

These EoATs are almost entirely designed by an engineer (in-house or at an integration firm), and as such, are the most unique for each application. They might incorporate off-the-shelf components such as vacuum pads, valves, and cylinders, but these are all arranged to fit individual tasks.

Some companies have been able to identify common gripper needs, like a block for CNC machining or a standard cardboard box size, and have designed lines of electric and pneumatic grippers that can be purchased pre-assembled. So not every robot used for gripping will have a unique tool, but the process of engineering and creating those grippers was still completed without designing around a standardized tool like a welder or screwdriver.

Incorporating EoAT into Robot Kinematics

Robot kinematics is the term for the motion of the robot, since kinetic energy involves motion, coming from the Greek word kinema: motion. As the robot moves, the physical forces at work around it will affect the inertia, although often simultaneously creating undesired effects in the settling time and precision, and causing torque sensors to read problematic motion and fault the motors.

Previous sections of this chapter have addressed the concept of ‘payload schedules’. This is critically important, and it doesn’t just include the box or bag to be lifted. The manufacturer of the robot knows every detail of the weight, velocity, and inertia generated by the metal and plastic components of the arm at any time, all the way up to the end plate where the attachment is fastened. At that point, the OEM no longer has the ability to program any algorithms.

The EoAT will always have some weight, even if it is small. When the arm swings quickly, the motors must deliver more torque (and current) to accelerate to the given velocity and keep it constant. If too much current is required, that will be registered as a collision, and the robot will shut off power to the motor.

The designer of the EoAT must provide the weight and the center of mass details to the robot in order for it to calculate how much current ‘should’ be required to move the joints. This can usually be done in one of two ways.

Direct Entry: Incorporating EoAT CAD Data

Computer-aided design (CAD) models of the tooling would be available for most modern designs from a well-documented prototyping process. Unfortunately, many times, the end tooling is designed iteratively, replacing one part after another when design challenges are met, and the end result is nothing like the original design on the computer.

If there could be any single major encouragement from this textbook, it would simply be this: documenting your process, whenever and wherever possible, will always yield benefits to your final implementation and troubleshooting.

If you have access to an accurate representation of the EoAT model, including the proper materials and dimensions, there will almost certainly be a way to gain the weight and the coordinates of the center of mass (CoM) with a single click (I’ve never used a CAD software that lacked this function).

Using the direct entry method, the weight of the tool, and the x-y-z coordinates of the center of mass can be entered directly into the program, and from that point forward, the robot understands what sort of torque to truly expect from the motors, lowering the chance of a false fault trigger.

One note on digital EoAT design, gained from experience.

Always design the CAD model with the origin of the part (or assembly) located right at the center of the bolt circle where the tool attaches to the robot arm. Additionally, consider aligning the z-direction as coming straight out, normal to that face. This matches the +z-direction of the tool coordinate system designed into all robots.

The center of mass coordinates will be mapped to that attachment point from the robot’s perspective, so if the CAD model does not align similarly, the entire part or assembly data will give a false CoM calculation and the kinematics will be incorrect. Alternatively, the engineer will need to rebuild the part of assembly on a different plane at a different point, and this can be far more frustrating in some software than simply designing it properly at first.

As always with CAD modeling, consider the goal and context of the project before choosing the starting plane and origin point.

Teach Method: Experimentally Determine CoM

Considering the reality of the previous method, we don’t always have access to a CAD data. Perhaps the model was designed in-house without access to software. Perhaps the data must be entered right away to decrease downtime, and you simply don’t have time to reach out to the manufacturer. Perhaps the original EoAT was modified or some part was replaced in the past, and the data isn’t valid any longer.

Whatever the reason might be, there is a way to help the robot understand the proper payload dynamics even without the direct entry method. Not every robot has this option, but as long as the torque to the motors can be monitored, this process is available to the programming team.

The automatic payload teaching routine usually involves a 2-step process. First, the robot is unloaded (end tool removed) and a pre-set range of movements calculates the current force and inertia of the arm under its factory default conditions. Then, each payload is added, the movements are repeated, and each calculated center of mass and inertia is recorded as a payload. The empty tool will be one payload, and each various sized product should be considered as a new payload.

When the final motion program is run, each payload is activated at the appropriate time depending on which product is held by the tool.

Difference Between TCP and Center of Mass

These two concepts each relate to a tiny point that has something to do with both the end tool and the product to be picked. However, they are very different concepts.

The tool center point (TCP) is the point around which all motion of the tool rotates. Linear moves happen at axes passing through the TCP, but they can be difficult to recognize as a single point of origin. Rotational moves, on the other hand, when two or more axis rotations are combined into a single move, the point of rotation becomes clearly obvious. In a software environment, the TCP is identified as a coordinate system with red, green, and blue arrows located at the end of the arm or tool.

Most tools must be moved very precisely along their entire path, like a welder or spray painter. As the arc of the welder is engaged, the very end of the tip must maintain an extremely consistent distance and angle from the workpiece at all times. Even the slightest deviation would cause failure. Likewise, a spray paint gun must follow the contours of the entire part while maintaining a consistent distance and speed.

For these tools, all rotation of the tool must be performed right at the point of application, which may even be removed from the tool by a few mm or more. That point does not consider the weight or shape of the tool at all. The tool itself is not the important factor; it’s the objective of the tool, If a welder, the weld is the important part, not the welder itself. The motion of the robot is focused around this tool center point, focusing all calculations on the point or purpose of application.

However, the center of mass (CoM) cannot be ignored, since the robot must understand all physical focus at work in order to properly navigate that TCP to the proper point. The CoM data allows the robot to factor in weight, inertia, and the presence of a loaded or unloaded tool to predict each next small step that will land the tool right at the correct spot at the right time.

TCP data controls where the robot is going and the path it takes to get there. CoM data controls the power delivered to the motors in order to move the TCP along the right path. They are related, but very different.

As a specific example, consider a welding tool attachment. The TCP will be located a few mm from the end of the weld tip. The center of mass, in stark contrast, will be located somewhere within the main body of the welding tool.

Payload Schedules

When we think of schedules, we often think of a planner or calendar with times locked in for appointments, trips, or meetings. Based on the time of day, we have certain objectives to meet which might change the way we perform certain activities.

Running a robot is no different, especially when we hope to capitalize on the flexibility of automation. If a robot can hold 4 or 5 different items, why not allow it to pick and sort many different kinds (or sizes) of products all at once? That would be far more cost-effective than buying one new robot for each product type coming down the belt.

Changing the end tool itself can influence the payload just as much as picking up differently-sized objects. Some robot grippers are equipped with tool-change systems (like the one shown below) which allow instant reconfiguration of the tool based on the task required. Some of these systems can auto-detect which tool is currently installed, allowing for a very easy input of parameters into the payload selection menu.

Imagine a box-sorting robotic application at a distribution facility. Based on the size of the box, or identified by a scanned barcode, the robot must place different boxes on different outfeed conveyors. The problem is, each type of box will alter the center of mass and the weight of the payload. If we were only able to enter one strict payload entry, we would hope that the weight of the boxes is all so small that all boxes would appear relatively identical to the torque sensors.

Fortunately, this is not the case, and we are not thusly restricted to one single entry for all payloads.

Most robot operating systems will have a selection of many payloads, each numbered consecutively. For each of these payloads, a weight and CoM coordinate will be required. If the tool weight and coordinates are known, each box can be added to the equation by means of a weighted average for each coordinate.

For example, assume a gripper with a mass of 3 kg at a distance of x=45 mm from the end face of the robot. The product to be picked has a mass of 6 kg located at a distance of x=180 mm from the end face of the robot. In this case, the product will be the largest factor on the CoM calculation, as follows:

$$x_{CoM}={m_1 \cdot x_1 + m_2 \cdot x_2 \over m_1 + m_2}$$

$$x_{CoM}={3~kg \cdot 45~mm + 6~kg \cdot 180~mm \over 3~kg + 6~kg}$$

$$x_{CoM}={135~kg \cdot mm + 1080~kg \cdot mm \over 9~kg}$$

$$x_{CoM}={1215~kg \cdot mm \over 9~kg}$$

$$x_{CoM}={135~mm}$$

Then we would repeat for the other two coordinates, and end up with a combined mass, and a known center of gravity.

Physical gripper design can have a huge effect on the complexity of the payload calculations. If the gripper is designed with a center of mass located directly normal to the mounting face of the robot, and it grips the product also with a CoM located normal to the robot, the final CoM location will also be normal to the robot. This means it will only have a z-axis coordinate, the x- and y- coordinates will be zero (0), which makes the calculations much faster.

As the program progresses, the data from each box or barcode scan can be used to implement one of the payloads, allowing the robot to better calculate its own trajectory and power. Not only will this cut down on false fault triggering, but it will also aid in settling time to land right on the spot, optimizing the cycle time.