Programming FANUC robots is easy. Giving the robots enough intelligence to run safely and reliably in just about any failure scenario is the hard part.
This is where many integrators get into trouble. They don’t plan enough programming time on the front-end so that they are forced to add polish on the production floor. If your FAT is just a day or two away and your code isn’t sprinkled with all sorts of (hopefully rarely used but thoroughly tested) error recovery routines, you’re in trouble.
One of my favorite projects I’ve programmed is this bin-picking demo for FANUC’s IMTS 2012 booth:
Anyone who’s ever worked for FANUC knows that they take their trade shows very seriously. The robots must run perfectly for the entire show. Anyone who’s ever worked with bin-picking knows that the bin is going to try its best to screw things up.
One of the issues I dealt with on this project was parts resting vertically against the sides of the bin. It would probably happen a few times a day. You might think that leaving one part once in a while would be ok. Nope, not for a FANUC tradeshow cell. We must completely empty the bin every single time.
What would you do if you couldn’t pick up a part in its current orientation? You’d move the part into an orientation you could deal with. That’s what we did with the robot.
The 3D Area Sensor has a “Peak Tool” that allows you to locate the highest point in your 3D point cloud. If the bin itself is properly masked out, this should be the top of that stubborn part. The robot would move towards that point and swipe towards the center of the bin. We’d then scan the bin again and hopefully find a nice part right in the center of the bin.
Here’s another problem: how many times do you let the robot attempt to knock a part over before trying something else? If the robot gets stuck trying to be smart, that’s probably worse than just leaving the part there. I’d have the robot try to swipe that darn part from different angles, at different depths, and as a last-case scenario just wipe around the inside of the box or shake the box itself.
There was another possible failure scenario that could crash the robot. As we ran the same parts all day, they’d inevitably get a little wet despite the machine tool’s blowoff. If two parts were right on top of eachother and laying at just the right angle, they might just stick together and both end up on the regrip stand. An attempt to pick a part that is exactly one part-height too high would crash the robot. (This was even more treacherous because the hacked together end-of-arm tool wasn’t keyed or doweled. Who wants to provide a live “Reteaching Points” tutorial session to all IMTS attendees and FANUC executives?)
After the GPM tool identified the part, I’d run a histogram to ensure we’re seeing the black regrip stand background behind the part and not a shiny tag-along part. If things didn’t look right, the robot would throw the top part into the bin and keep throwing the bottom parts into the bin until we’re left with a clean regrip stand.
These little routines didn’t run very often. I put a couple of counters on them just to see if I’d wasted my time. The stubborn parts in the bin got knocked down several times a day, but the tag-along parts on the regrip stand probably only happened once or twice the entire week.
Back to my original point, this stuff should be solved and tested sooner rather than later. I was certinaly glad of this when the robot got a stack of two parts out of the bin during our final internal executive runoff. I saw the vice president notice and point at the robot when it happened, probably anticipating the imminent crash. When the clever robot quickly put both parts one-by-one back into the bin, we both smiled. Cell approved; ship it.