On January 8, 2019, Robotiq put online version 1.8.1 of its Force Copilot URCap (UCS-1.8.1). Please browse to the product page of the FT 300 Force Torque Sensor or that of Force Copilot for download. The bug fix implemented is as follows:
- Bug fix for Zero Sensor popup displaying twice when starting ActiveDrive while sensor is not still.
Also, on January 14, 2019, Robotiq uploaded version 1.5.1 of its Adaptive Grippers URCap (UCG-1.5.1). Please browse to the product page of Hand-E or that of the 2F-85/2F-140 Grippers to download the compressed file. The improvements and bug fixes are listed below:
Please contact [email protected] should you have questions or comments.
What makes a good automation? A quick search on the internet will provide dozens of articles listing questions you should consider but will not provide strategies you can implement. Those articles all flout astounding tactics that will result in beautiful solutions that will astound the mind and impress your superiors. If you can decipher them.
That sounds great if it’s part of a pitch deck, but if you are the one who actually has to decide what to automate and how to do it all this advice exacerbates the problem you started with: the complexity of automation. Complexity is the death of every well-conceived—but misguided—attempt to make our lives easier through automation. We have all experienced that great new idea that gets thrust on us via powerpoint but never delivers on its promises. Well, don’t despair about your frustrations, I have a solution that is so simple your ego won’t want to use it: think like a child.
A child’s way of viewing the world is one of the greatest gifts to the engineering community because of their unencumbered view of the way things are, not the way we think things should be. It’s this unique way of viewing the world that makes them natural litmus tests for if an automation is well conceived. The best way to illustrate this is the Elephant/Giraffe/Refrigerator IQ test. The test goes something like this:
Q: How do you put a giraffe into a refrigerator?
A: You open the door, put the giraffe in, and close the door.
Q: How do you put an Elephant into a refrigerator?
A: You open the door, take out the giraffe, put in the elephant, and close the door.
An engineer might calculate the weight of the giraffe, adjust for volume of water lost if we dehydrate the meat, create a packaging formula for optimum space...and you get the picture. A child would say simply, “put it in the fridge” because either they don’t understand a giraffe won’t fit in the fridge or they assume you are talking about a stuffed animal because - who would be dumb enough to try to put a real giraffe in a fridge.
Ok that’s cute, but at this point I haven’t actually done any better than those articles I berated earlier for complicating the situation instead of helping. Let’s change that by taking a child’s frame of mind away from the theoretical plane and apply this tactic to two common situations you have dealt with in real life.
First a physical product: You work at a manufacturing firm making a thingamabob. Some hotshot salesman (in an effort to close a deal with a major client) just promised a 10% reduction in price over the next 3 years and now you have to deliver on that promise. Since it’s not my purview to illustrate the wrong way to approach it, I’ll assume you’ve already banged your head against your desk for two days because all your solutions either need too much money for new equipment or worse require inventing equipment that will be unreliable for the first two years. Instead, I’ll jump right into thinking like a child, specifically how they play with one thing at a time. When you watch a child play they start with one toy: a truck rolling across the floor is really driving through complex city scapes and busy streets. The child doesn’t worry about who was driving the truck or what city it was in - they just drove the truck. Similarly, the best automations I’ve built do one thing very well and that’s it. Yes, they may be part of a bigger structure that has multiple tasks, but automation “A” doesn’t fail if automation “B” has an issue. The solutions coordinate but do not correlate. We have this tendency when looking at a problem to think that we have to solve all the issues with one perfect solution that accounts for all the variables. The reality is if we just focus on one simple and achievable solution, solve it, and then focus on the next simple and achievable solution, by the time we run out of simple things to fix we have created that beautiful solution we strove for in the beginning.
Now, lets look at a process situation: You just got that promotion you’ve been vying for over the last two years. Everything is great but your new boss wants to capitalize on your desire to show you deserve the raise and responsibility they just gave you. The company is growing and the sales procedures for the company aren’t cutting it any more, you have have been given the prestigious task of overhauling the process and automating as much as possible to cut down on paperwork and get the field sales people selling again. So how does thinking like a child help us this time? In this case it boils down to instruction length and assumptions. When we are entrenched in a problem our minds naturally skip over simple steps because we have performed them so many times they have been relegated to the unconscious mind. The same way when you tie your shoes in the morning you don’t think about grabbing the laces first - we forget the routine steps of the task. To be successful in automating the daily procedures of our work-life we must approach it as if we are teaching a child. No, I’m not calling your sales people children, I’m just illustrating the point that the best automations assume the user has no knowledge of how to complete a task. The best automations break down steps into one line instructions that make no assumptions of previous knowledge.How do we distill the practical examples above into a rule that passes the litmus test, or more precisely, what exactly is the litmus test we are applying? All automation should start from the question, “would a child understand this logic?” The instructions must be boiled down to the base components enough so the reader doesn’t need to assume anything, individual steps must be built on single principles that coordinate, not correlate, with each other. The logic of good automation can be understood by any child. I will admit that the final version of your automation can grow beyond this test and still be effective, I’ve created advanced solutions that even grownups eyes glaze over at. The child litmus test is not meant as dogma but as a reference point that we can all start from as we begin to evaluate where we might take automation in our own organizations. May your inner child serve you well.
I appreciate this question. I too have a similar need. Instead of a drawer with a plane associated with it (and movements), I will have a slot that I need to insert a device that will be calibrated. I will have many calibrators with the same slot feature that I will need to switch in/out of the variable Matthew (above) described.
Also, you will need to keep track of which feature you are using and reset it if the program is restarted as the feature will reset back to what is stored in the installation file.
We do this when we have rotary tables and such. The only difference is we calculate all of the waypoints and so we store the current active feature into a generic variable and then just make the assignment based on sensors so that at startup the system assigns the correct plane to the working variable. We then use that working variable in our pose_trans calculations.
When upgrading you need to install at least one version from each minor release of the software, so to go from 3.4 to 3.6, you will need to install one of the 3.5 versions.