Creating a robot for bowling

While the action of throwing a bowling ball may appear very straightforward, developing a high level of control is very nuanced and can require years of practice.

By Peter Welander, Content Manager November 1, 2011

ARM Automation does a lot of robotic design and is used to getting some peculiar application challenges, but this one was more interesting than most. The United States Bowling Congress (USBC) wanted to create a new robot capable of throwing a bowling ball with all the strength and control of the best human bowlers, and then some. While it may sound like something pretty unique, it is not without precedent. There had been an earlier model called “Harry” that had achieved a level of success, but the next generation would have to make some major advances.

The purpose of this project was to create a means to test various elements of the bowling process, so as to separate the human elements from hardware. “We aren’t testing just one thing, we’re testing the whole system of bowling,” said Neil Stremmel, USBC managing director. “That can be the lane oil, the ball, the pins, and the ball motion, which involves coefficient of friction, rates of gyration, and interaction with the pins. There are so many things going on, it’s hard to say ‘this is what we need to change’ to make bowling much more skill oriented than technology oriented.”

Stremmel points out that a human bowler is simply not consistent enough, and is always fighting the desire to go for a strike. He added, “In order to study ball motion reliably and repeatably, you need something that is consistent and without bias. That’s where the robot comes in. Most bowlers have preconceived notions as to what they see in front of them. We’re not concerned with rolling strikes. We want consistency.”

Playing with inertia

If you have ever tried to develop any skill as a bowler or even just rolled a few lines now and then, you know it is tricky. The way the ball rolls and spins suggests it has a mind of its own. This is not entirely your imagination. The way the internal weight is distributed in a bowling ball is not completely symmetrical. While it is balanced, the inertia is not the same on every axis. If you take a dumbbell, its weight is evenly distributed around the center, but its inertial characteristics are different if you stand it on its end and spin it, compared to spinning it on its side. That’s the way it is with a bowling ball. It spins differently on one axis than another, which is a characteristic a skilled bowler is able to use to his or her advantage.

Now, how do you describe and quantify that kind of action so it can be built into a robot? How does a designer begin to sort through the axes of motion required to duplicate a world-class human bowler? Moreover, it has to be capable of any motion, from the slow, straight roll of a child to the powerful throw and aggressive spin of a professional with virtually perfect repeatability. Conceptualizing it is hard enough, but you have to build it too. ARM Automation took on the challenge.

“It was a challenge, because, as with many customers, they speak a language in their own domain,” said Derek Black, VP of business development for ARM Automation. “Every industry has its own language, coordinates, and terms. Part of the art of doing good design and system integration work in many different industries is being able to translate user specifications and user language into meaningful design requirements. If you frame it in the right light and you ask the right questions, you set yourself up for success and you also often frame the architecture of your solution without even realizing it.”

ARM’s designers were able to meet with Stremmel and the USBC team and see video of Harry, but had no opportunity to work with or dissect the earlier robot. Eventually, they were able to specify ranges for the four main parameters: ball throwing speed, spin revolution rate, axis of tilt, and axis of rotation.

“We had video from Harry,” Stremmel said. “We were able to say, ‘Here’s the speed and here’s the rotation.’ Those were the easier things. As far as axis rotation, that’s really just the axis point, whether it’s pointing straight back at the bowler, or 90° from there, or somewhere in between. But then the tilt, which is taking that axis and tilting it up towards the ceiling, will be the rotation that the ball initially revolves around. It’s the initial axis point. It took some describing and explaining, but it didn’t take all that long.”

Starting from scratch

ARM had to turn that into a buildable configuration, beginning by analyzing the necessary axes of motion. Greg Wiese, engineering project manager for ARM, helped sort it out: “There’s the linear axis to position the robot’s shoulder across the width of the lane, a five-axis robot hanging off that linear axis, plus an axis to spin the ball on the gripper or end effector. So that’s seven, and then a mechanism to release the ball. We had tried initially to use an off-the-shelf robot to save some cost and development time, but with the tip speed necessary to throw the ball 24 mph, we couldn’t find a robot that had a strong enough shoulder to generate that hard a throwing motion. That drove us to do our own robot design.”

Over time, ARM was able to create the movement geometry that would determine the robot’s dimensions. As Black described it, “Most robots are planar mechanisms. Once you locate the shoulder joint in a throwing mechanism, you then look at the first two joints as the x translation side to side and the base rotation. That defines the plane of throw. So once you define the plane of throw, the arm is essentially three joints in series: a shoulder joint, an elbow joint, and a two-axis wrist. So by defining the first joint, the translation joint, and the second rotary joint, you’ve set the shoulder x position and the rotation around the vertical. Once you’ve done that, you have your throw plane, and you have to calculate your wrist orientation at the point of release. What we did ultimately was make a geometrically reconfigurable pendulum with the ability to articulate the gripper.”

While all that is true, it all gets more complicated due to the ball’s weight and inertial characteristics mentioned earlier. The gripper cannot grab the ball at random, but has to hold it such that it will spin on the correct axis and then release it in the correct position. “What we did to accomplish that was to set up a standard base frame so the ball was placed in the holder in a consistent location and orientation,” Black explained. “The finger holes are the reference point, and once you’ve defined that, the robot picks up the ball in a very particular orientation as selected by the thrower. Once it’s picked up the ball, from a design perspective, you stop thinking about where the ball frame is in the gripper. Now you’re focusing on the point of release, because that’s one of the most critical features of the whole system. At the point of release, there is a specific orientation of the spin axis at that point in time and space. You’re defining where in space the instantaneous trajectory of the ball is relative to x, y, and z; its velocity; and the orientation of the spin axis relative to the frame of the lane.”

Letting go

While the way the robot holds the ball is critical, releasing is just as important. The mechanism clamps on the ball between two grippers, like the head- and tail-stock of a lathe. The head-stock side has the motor that spins the ball. Both sides come together using a scissor lever action driven by a double-acting pneumatic cylinder. Given that bowling balls are not all the same diameter, the gripper has to adjust itself to compensate. Once the pneumatic cylinder squeezes the gripper on the ball, a mechanical lock latches it in that position. Once locked, the cylinder pressure is reversed. When the arm reaches the release point, a solenoid trips the latch and the cylinder opens the gripper in an action that Wiese described as “explosive.” This approach has latency of about 30 ms, but proved to be the most repeatable. Both sides withdraw from the ball so the release is as clean as possible. Wiese added, “When the ball is moving 20 mph or faster, a dither of even a millisecond turns into half-an-inch of travel. We’re looking at control speeds on the order of microseconds so we don’t throw the ball into the rafters.”

Since this project required a custom robot, much of the rest of the work had to be custom as well, but Wiese said most of the major motor and drive components came from Yaskawa. “Since we had to design our own robot, we had to design our own robot controller. It ended up being quite an engineering effort to pull it all off. Yaskawa provided the digital output from their drive to tell us when the robot was going to be in position. They’re down in the 100 to 125 µs range, and that response time is one of the enablers for achieving the repeatability.”

A human operator controls all the parameters via a touchscreen HMI, setting all the angles and speeds through menus. A position measuring system follows the ball’s speed and trajectory down the lane so the effects of any adjustments can be recorded, quantified, and analyzed.

Does it work?

The next-generation robot, dubbed “Earl” (enhanced automated robotic launcher), made his debut late last year at the USBC test facility in Arlington, TX. The obvious approach to prove his capabilities was to pit him against one of the best human bowlers, USBC spokesperson and Professional Bowlers Association star Chris Barnes. The human prevailed in this contest, as Barnes beat Earl 259 to 209. Stremmel attributed Earl’s loss to wearing a rut in the lane because of his own extreme consistency. “Robots hit the same spot on the lane every time. Earl is consistent to a third-of-a-board, 15 ft down the lane, so he’s taken the oil off where he’s already bowled.”

Earl’s designers at ARM were pleased with the result, and chalk it up as another successful project. Black summed up the experience: “We do a lot of the custom automation engineering that others don’t necessarily go after, and for which there is no standard solution. We do a lot of development- and design-intensive engineering related to industrial automation. We can go into applications for which there is not a lot of precedent, or for which there is not a lot of process understanding or definition. We can help customers define what they’re looking for.”


Peter Welander is content manager for Control Engineering.


Also, see Earl in action in a USBC video: https://bit.ly/9fjLKm