Search the Community

Advanced warning, this may not be the most professional or business-centric blog post for Gibson Engineering's Support Community. I wanted to share an automation application and the associated story that may entertain some of our readers. Earlier in the year, as we went into coronavirus quarantine and our kids were sent home from school, my wife decided it was a great time to get chickens. I've shrugged off this idea for a couple of years now. However, I came home one night to three excited children making chicken noises before informing me about the "family decision" they had made that day. The family decided to get chickens. They just forgot to consult me first. At this point, I had no say in the matter. I thought I'd have a few weeks or even months to research and build a chicken coop, run, and whatever else I may need for the chickens. Meanwhile, the next day I was texted pictures of my three children holding a dozen baby chicks. After some online research and generating a BOM for my DIY chicken coop, I realizing that it was far less expensive to buy a coop than build one. I soon learned that backyard chickens were experiencing a surge in popularity because of COVID-19. Buying a chicken coop now meant a lead time of 6-9 months which was far beyond the date our chicks needed to move outdoors. Shortly after contacting a few places, I got a call back from a coop builder suggesting that if I wanted to pay in Bitcoin, he would expedite my coop! I'd never dealt with bitcoin before, but for the discount and expedited delivery he was offering, I rolled the dice. I create my Coinbase account, and after a short delay, my cash was converted to cryptocurrency, and the downpayment was funneled to a guy I'd never met in New Hampshire. He apparently has little faith in our federal reserve but he has a kind heart and a knack for building chicken coops. A portion of the sale from every coop he sells is donated to charities bringing food, water, and electricity to impoverished people worldwide and saving children from human trafficking. The coop made it to our home in MA after my son and I picked it up with a rented trailer and moved it into place on some PVC pipes. The chicken run (the outside area) still needed to be built. I then learned the recent popularity of chickens apparently created a shortage of hardware mesh which I'll describe as the Fort Knox version of chicken wire. There was no way my family would let me use standard chicken wire to protect our new family members from the fisher cats, fox, raccoon, coyotes, and hawks that may find them tasty. A combination of amazon and curbside pickup at multiple local Tractor Supply Stores got me enough hardware mesh to complete the job but it was a close call. Now for the automation part that makes this blog at least slightly relevant for Gibson's Support Community. Letting out and then safely closing in a dozen chickens every day and night proves to be painful, in particular, if you aren't home. We entrusted our teenage neighbor to open the door and let the hens out for food and water for a few mornings, that was all we needed to decide an automated door was neccesary. This is where my son Jackson and I put our heads together. After learning about the multiple hundreds of dollars, you could spend on fairly archaic automatic chicken coop doors; my 8-year old son Jackson and I decided we had a better solution. Our plan was to automate the existing door and, of course, integrate some safety to make sure we didn't decapitate a curious hen that may stick her head in or out as that door is closing with 22 pounds of force generated by an open-loop DC brush motor and lead screw. We looked for actuators first. As robust and high performance as Intelligent Actuator RoboCylinders are, these industrial actuators I am familiar with were overkill for our application. We found a compact 6-inch stroke actuator with integrated motor and limit switches for about $25 online. Then we researched wifi-enabled relays for home automation. We found a $15 multiple channel relay module with built-in interlocking capabilities to ensure we weren't trying to open and close at the same time. The wifi module was compatible with a free open source app for any smartphone and included scheduling capabilities. We really didn't want to crush our hens in the door so we added another $6 relay module and a Sick retroreflective H18 sensor to detect any chickens across the door opening that would cut power to the DC motors and stop any motion. It isn't exactly "safety-rated," but we are talking about chickens, not humans here. Once we had all our components, I spent some of a completely unscheduled COVID weekend drawing electrical circuits with my son. I explained the 12vdc power supply for the actuator versus the 5vdc supply on the wifi relay module. We talked about what interlocked meant and how wifi works. We covered series and parallel circuits, and my 8-year-old Jackson son was thrilled to cut and strip some wires, see some lights illuminate, and control electricity to the point he could make something open and close. Last, we added a couple of really cost effective WYZE cams to check in on the chickens anytime we wanted. I never thought I'd say we owned and raised chickens. It's particularly odd when I think about that statement, "We got chickens during a global pandemic, purchased the coop with cryptocurrency, and then my son and I added IIoT devices and automated it!" At Gibson Engineering, we've talked about the personal and professional silver linings through this pandemic. This COVID-driven chicken undertaking has been a silver lining for me and my family. My kid got to see baby chicks grow from fragile little peeping birds to full-grown clucking, egg-laying hens, each with their own personalities. They see where their food comes from, take responsibility for some shared chores (sort-of), and spend more time together taking care of the chickens.

I've been supporting the implementation of a Kassow KR1410 collaborative robot for a pack out application, I wanted to provide some tips on integrating a collaborative robot based on my experiences. Fully understand the system requirements I cannot emphasize how important it is to understand the system requirements, or if there is a machine that already does a similar job it is very important to study that machine and fully understand the process. After I’m confident in the requirements, I try to come up with a plan or a sequence in my mind on how I should be programming the robot, which brings me to the second step. Make a sequence of operations document Write down the sequence of operations. This is different from how the machine is going to work, this is how components of the machine are going to communicate. Take a look at the snippet below; This sequence can be tweaked when actually programming the machine. Often there are multiple programmers working on a machine so for example it is good to have a document where the PLC guy understands what the Robot guy is going to do in their program, and vice versa. As you can see in the snippet above, feel free to assign the I/O and registers on how the communications are going to work. Write pseudocode For those who don’t know what pseudocode is, it’s just a simplified program. This step cuts down the time that’s spent on the machine by a lot. I usually have most of the program already written out before I even start working with the cobot. Take a look at the code below, it’s mostly comments but now I know what exactly I need to program. Work with the cobot and machine After having the pseudocode, I go on the machine and start by setting up all my communications, Modbus, TCP/IP, check digital I/O, etc.. Next, I start teaching positions and building the sequence step by step. Test I am not going to call this the last step because you would be more successful if you have already been testing along with the rest of the above steps. Whenever I feel like a part of the program is done, I test to make sure that part works. This works well when you’ve written your code in a modular way. For example, the main program that I run on the robot will only consist of several lines. I usually have two loops, one that runs once, my initialization loop, and a loop that has my main program that always runs. In the initialization loop, I make sure all my variables are reset, I read all the sensors tied in and make sure I am aware of everything that is going on that the robot should know. This should happen only once in the program. My main loop is most often a “while (1) loop”. This is an infinite loop that never ends, unless I call a “break” from the loop. This break prevents me from getting stuck anywhere inside my program and I never leave the robot in a state that’s not great. For example, I always try to go back to a home or safe position when a task is complete. One situation where I make this loop to rely on a variable is if I have another controller, a PC or a PLC that tells the robots what to do. Going back to the testing, (it is really hard but) make sure to try to account for all cases that can happen. This could be safety related, operation related or even part related. Testing all the “what-if” scenarios can be the most time consuming but the more you test the lower your risk of unexpected problems later. I believe that everything seems very complicated until you break it down into pieces and tackle them one by one. With these 5 steps, hopefully it will be easier for you to implement a collaborative robot. If it still seems confusing or you need any help following these general steps, please reach us at https://www.gibsonengineering.com/ or leave a comment below!

There are 5 major factors that I think about when I am specifying a robot for an application; reach, payload, speed, application type/versatility and lastly, cost. Reach Reach is one of the most important factors to getting the right size robot for your application. Some applications are as easy as just a simple pick and place and you can measure from the pick position to the place position and verify what kind of a reach you need from your robot. However, sometimes you need to reach around certain objects, for example, for a machine tending application, you might need to account for the door of a CNC machine. Or the pick/place locations change dynamically. It gets tricky to measure exactly how much of a reach you need in these scenarios. In cases like these, I usually use a model of the robot and manipulate it to see if it can actually move around the cell or its workspace. If the robot has a simulator, that is something to consider because it will make it very easy to see if that particular robot is going to work for your application. Payload Payload is the second most important factor. If the robot can’t carry the parts you are handling, then it is not going to work. Payload calculations get trickier than the reach calculations sometimes. It is a common mistake to forget to include the gripper’s weight into consideration when you do these payload calculations. And that’s not even enough. Most robot manufacturers will specify their robot’s payload exactly at the end of it’s last joint. So you need to find a graph in their manual that shows the payload capacity of the robot at a distance from the end of the arm. Finding that graph is definitely harder than calculating the load.. Speed Most of the applications, the robot is servicing another machine or limited by another equipment down the manufacturing line. So the robot’s speed is dictated by the cycle time of those bottlenecks. Let’s say we are in a bottling plant and every bottle takes about 5 seconds to get filled, labeled and inspected. Every 5 seconds, we will be seeing a bottle to be picked up by the robot. Our robot needs to be able to complete its task under 5 seconds and be ready for the next one. This is where we can start being clever. 5 seconds is not too fast for industrial robots, but for cobots, it definitely stretches their “safe” speeds. Now, we should ask the question, can we handle more than one bottle at a time? If we can handle 6 bottles at a time and do the task that’s required, now our cycle time is about 30 seconds. It is definitely smart to explore the options of handling more than 1 part to reduce cycle time but we still need to be careful to be under the payload of the robot. Also, usually handling multiple parts is harder than handling only 1. After making sure of the details and understanding how many parts to handle, the best way to test is to do a real time cycle time test with the specific robot. If the robot manufacturer offers a simulator, that might also be a good way to estimate the cycle time. Speeds that are listed on spec sheets are good for getting an overall feel, but you really should test the robot if your application is speed critical. 4. Application Type and Versatility It is important to consider all types of robots in the application at first but some application types just require different robots. Doing a very delicate and precise quality inspection, you might need a robot with high precision, or if you need to orient your part, you want to go with an articulated robot rather than a SCARA. You also need to consider if the specified robot can handle other applications in the future. This is one of the reasons collaborative robots are so popular these days since they are easy to deploy and versatile. Cost Cost is obviously a very strong factor in the decision making process. The key parts to justifying the cost of the robot is to understand the cost reduction that it will introduce and the return on investment of it. Obviously that return on investment will take a shorter amount of time if the price of the robot is cheaper, however, you should get the robot that is suitable for the job and also checks out the other factors listed. These are 5 major factors I personally consider when I am picking a robot. In some scenarios, one factor might be more important than others, but everything starts with understanding the application requirements. Please reach out to Gibson Engineering if you have an application and we can choose the robot that fits your needs together!