This robot package adds to a recent trend in automation -- devices that include the intelligence inside, making it easier for users to deploy the package. We're seeing this in a wide range of automation equipment. This is the first time I've seen it with robotics. It's a great idea -- make the device or package more intelligent on the inside and less complicated on the outside.
I'm not sold on this being a great idea. There are nuances to robot programming that cannot be included into a software package. Proper selection of motion type, termination type, look-ahead, etc. are part of robot programming. Programming a robot is easy. Programming a robot well isn't.
The best examples that I have are with CNC machining. I saw a demonstration of an aluminum part being machined, and I could hear the machine was being over-driven. After the cutting cycle ended, I reached into the machine to inspect the chips to see how hard the cutter had been working. I pulled out a blob of aluminum. The software had allowed the tool to be driven so hard that it melted the aluminum instead of cutting it. I saw another application where the software allowed a 9/16 drill bit to be plunged through 1/2 thich aluminum. The proper sequence would have been: center drill, pilot drill, finishing drill. Oh, the reason that I was there was they had destroyed the bearings in the spindle because the drilling reaction load was too large.
Glenn, we've discussed this issue in a few other article comment threads. The idea is similar to the idea in machine vision or any other area of manufacturing and automation: simplify "programming" so instead of actual coding it's more like point and click, and operators can do it, instead of actual programmers.
A draftsman using CAD creates a drawing. CAD used improperly creates garbage. The same goes for spreadsheets, CNC programming and robot programming. The question becomes 'how good is good enough' ? The less you know about an application, the lower that bar becomes. This is just a dumbing-down of the application.
I don't know what the best analogy would be, maybe the difference between a painting, and paint-by-numbers. Which has more value, or commands more respect ?
ABB is leveraging its experience in writing palletizing applications with this software and robots/grippers specifically targeting these types of projects. By putting the major focus on ease of use, this approach reduce the need for custom programming but I would be surprised if they couldn't make adjustments to fit a specific customer requirement. This is a very intriguing product that has a goal of virtually eliminating the requirement to write robot application software for the user. Definitely a trend; the key is application software that can be deployed to meet a range of customer needs using the standard software product.
Yes, Apresher, it seems the goal for much of the new automation hardware is to relieve the end user of customer programming. So much of the new product introductions seemed to be designed for quick and easy deployment. Not a bad trend.
Al, when you talk about the goal of eliminating the need to write robot application software, what does that mean? Does the user just answer a few software-based questions, fill in a few parameters, and then go? Seems like the robot's motion wouldn't be very ideally-suited to the task that way.
While there are some application-specific packages being developed with the goal of limiting user programming, the bigger trend in automation software is the development of software objects. These objects are reusable, configurable functions that are supported by powerful integrated development environments but still require programming expertise. Of course, companies that build specific types of machines have their software base and expertise in specific application areas but it doesn't go as far as the ABB solution which is offering really a turnkey package for palletizing.
Al, you're right on the money. "Programming" in the use-a-software-package sense meant here depends on a graphic user interface where the "programmer"--actually an operator--does a point-and-click form of "programming." This is not coding, but takes advantage of object-oriented software methodology that a programmer has used to create this type of software. Somewhat analogous to semiconductor system-on-chip design, it automates and puts under the hood all kinds of functions that don't need to be recreated every time.
Chuck, The key is the pre-written routines specifically for palletizing which, I assume, users can configure for their specific application. The new software approach merges with the virtual programming environment of ABB RobotStudio which allows users to configure, simulate and program robots and grippers for palletizing solutions. Since users are also able to immediately download code into the robot, teach reference points in the work cell and get up and running more quickly, it is potentially a huge advancement in reducing engineering costs and lead times for palletizing projects.
Robot manufacturers have gotten lots of feedback from customers that robot programming is too complex, so providing easier to use solutions is an ongoing focus. We'll have to wait and see how widespread this type of approach becomes.
I would agree that it is a good idea to move to "drag-and-drop" 'programming', but I don't think we will get there soon.
I have spent over 30 years making automation systems work, mostly programming and debugging them. Applications come in many flavors, and if you don't properly categorize the application early in the design cycle, things can go very wrong. I think most medium to large scale automation projects that go wrong lost it somewhere in the analysis phase, and the canned programming tools I have seen don't help much with properly analyzing the required process.
For example, I was called in on a bottle packaging line several years ago. The line consisted of perhaps 8 or 9 conveyor segments, and some number of stations along the conveyor that did some operation to the bottles. The bottles were flowing in from the production line at some rate, and they had to get through the conveyors and get marked boxed, then packed out by robots. The system was "almost done". The problem was, it would not recover from process errors in a very graceful way.
Upon examining the code, it became clear that it had to be rewritten, because it was not going to be feasible to 'fix' it. The programmer had written the program as one big sequence, from bottles entering the system, to the final packout. If that sequence got interrupted (which was inevitable), the only way to recover was to completely empty all of the conveyors of product, and start over. So, if the boxer ran out of boxes, or jammed, the only solution was to completely empty the line (which was probably two hundred feet long, and might be holding thousands of bottles, boxed and unboxed) He did not recognize that each subsection of the system needed to function indepenently of the other subsections of the system.
The only way to fix this system was to properly analyze the system, break it into sub-systems, program each sub-system, and add the proper flow control logic between the sub-systems. Now the error recovery involves un-jamming the subsystem that failed, not the whole line.
I don't know if canned programming systems can ever solve this issue. (improper analysis of the problem up front). In fact, they tend to force you to do things in the way that the designer though you would need to do them, which may be quite different from what you really need. If you don't recognize this quicky and bail out, you can spend a lot of time going down a path that will never work in the end.
Canned programming systems can typically handle very simple applications. Ann mentioned vision systems. Vision systems are very good at counting large, uniformly sized black marbles that are nicely separated on a clean white tablecloth. The problem is, I haven't run into the customer that wants to do that. The demo applications only exist in the demo room, best I can tell. So, when you get to the real world situations, the canned programming many times breaks down because there just aren't that many simple applications. (If there are, I haven't had the good fortune to have seen many of them.)
Chuck, Companies might still use system integrators to implement these systems. But by using motion algorithms specific to palletizing movements, for example, already pre-programmed into a "standard" application package, the goal is to allow the user or integrator to configure movements for a specific machine rather than writing routines in the robot programming language. Another layer of software that makes it easier to implement the software, already written and defined in the language of palletizing, is the idea behind these types of packages. The caveat to a general trend in this direction is the complexity of diversity of application needs, plus in this case ABB is communicating with its own hardware solutions.
Al, thanks for the clear explanation. I think some of the confusion about drag and drop has arisen because some people are collapsing categories of programming between repetitive, well-known motions--in this case, what it takes to put things on a pallet--and the highly individualized motions that might apply to a particular installation. This reminds me a bit of some early discussions of "system-on-chip" silicon--no, we didn't put an entire computer on a chip, but we did incorporate on silicon a ton of functions that operate the same basic way across many applications. This is clearly a relatively new concept in robotics, and I suspect it's arisen because of the sheer number of installations--ABB is pretty darn big--and, as you mention, the fact that they're communicating with their own controller hardware.
Thanks, Ann. This trend is definitely here to stay but the key as you noted is the ability for vendors to leverage experience with specific applications. That enables them to move from programming an application to "configuring" the operation. It doesn't always work with every application for a variety of reasons. Configurable software objects is the more general approach that at least reduces software development time.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.