Never Trust an Operator

Filed under: TP Programming Workflow

Programming robots can seem easy. You can get a robot moving around for a quick video demo in minutes. Even a tradeshow cell that needs to run perfectly for a day at a time isn’t too bad because the environment is controlled. Once you give up that control and hit the factory floor, however, the game changes. Here we have to validate everything, double-check it all and keep the robot safe when it gets misinformation.

I worked on a machine-tending application recently that had a cart full of empty trays for outgoing finished parts. This cart station is guarded by a light curtain, allowing operators to easily exchange carts when necessary. What’s good for the operators is generally bad for the robot. As soon as the light curtain breaks, we have to assume someone has messed with those carts.

  1. Do we still have the same number of carts?
  2. Are they still in the same location?
  3. How many finished parts are on the top layer?

We don’t have to verify these things immediately, but we do have to know the answers before using the carts again.

For the internal runoff (semi-controlled environment), I simply presented an HMI for the operator to indicate if the top layer was empty. In production, however, I would never let the operator make a decision that could potentially crash the robot.

I’ve since added a routine where the robot determines the tray’s state by scanning the top layer with a sensor. If we did not have that capability I would simply assume the tray is full and transfer a fresh one over.

This scanning routine is another example of where I have to assume the worst. If I simply scan the tray without first checking to see if the sensor works, we could incorrectly identify a filled tray as empty and end up crashing on the next placement. Before scanning the tray, we have to ensure the sensor is OFF when it should be and ON at another known location where we expect it to be ON.

Another common problem is determining gripper state on startup. If there is no proximity switch or photoeye that positively identifies the part, and you’re just relying on the state of the fingers, how do you really know if there is a part there or not? Unfortunately you don’t.

In this situation I will generally require manual intervention: the operator must open the gripper and manually remove the part. Dropping a small plastic part might not be a big deal, but what if you could be holding a truck frame? It’s probably not a good idea to to drop that thing without some very reliable information.

Programming a robust system basically requires a healthy sense of skepticism: don’t trust the operators, know that your sensors will eventually fail and plan for the worst case. You know what they say about making assumptions.


Want posts like this delivered right to your inbox?

If you liked this post, please sign up for my mailing list!