Robot programming is a complicated tax. Even novice programmers are often hot in demand, and very often they will work for integrators who operate on the basis of one-off or serial integrations with different manufacturers. These are surprisingly small businesses that are often unable to address new customers after a very short period of time, as their queue of clients (relative to the work they can provide) can fill up quickly.
At the same time, there are a variety of advanced manufacturing systems, industrial automation techniques and more possible process improvements that engineers can be working on to create productivity and growth for manufacturers. Ultimately, the opportunity cost of trying and failing repeatedly to integrate robots is very high compared to the other benefits that a manufacturer can get from new systems. While robot programming is complicated and tedious, the actual capabilities found within existing programming languages are highly limiting. Systems that try to make robot programming easier often don’t do enough, and AI can instead allow engineers to focus on bigger problems.
At its base, programming a robot is fundamentally more complex than programming a computer or generating the usual piece of software. For instance, a six-axis robot can have six degrees of freedom, an indefinite number of positions in space, as well as have positions and joint constraints that cannot be exceeded without risking the integrity and performance of the robot.
In this circumstance, you can imagine that to achieve a single output, you must do six or seven times the work of a traditional programmer just to ensure that your work achieves a reasonably consistent output. At the same time, the costs of organizing and testing these programs is difficult to manage because industrial settings are scarce and expensive to put together on short notice, meaning that they are typically reserved for actual production. When a new program is tested and deployed, that means production must be shut down.
At the same time, testing in a production environment doesn’t come with any guarantees. You can be limited in your ability to actually ensure that your production goals are met, and if there are any quality or fixturing issues, you may see your process go back to the drawing board entirely.
Robot programming originated as a discipline to describe simple tasks for industrial robot arms. Robot programming was only ever meant to describe points, motions, speed, geometries and other control mechanisms – it is not designed to intuitively understand human reasoning and adopt the same strategies humans do.
This is in part because robots are such a leap forward that they could only ever originate in a lab. The first manufacturing robots simply execute a pre-recorded series of positions, and were not even based on computers, transistors or servos because at the time they were too expensive.
No decision or response to their environment was required here, and what this implies is that ultimately robots are simply a mechanical system, not even an intelligent machine in themselves. This makes robot programming more mundane (in some ways) than traditional computer programming, and while hand guiding, teach pendants and other methods have made things easier, there are ultimately far fewer resources for engineers to call on in generating their motion programs. Building those resources is almost further out of the question, since they’re not really necessary if robot programming can be automated on the whole.
Another environment to understand is the virtual world. Robot programming has primarily moved to offline systems in an effort to save material, manpower and factory space. While there are a variety of tips that can make robot programming easier, the real question is if you want to endeavour to program a robot at all.
Why is this the case? When you have an industrial robot accessible to you in a production-type environment, the cost may be high, but it is far easier to anticipate and structure the needs of the robot within the environment, making it easier to design and model the process you want to execute and provide clarity to your programming task.
An offline programming solution may take some time out of the actual preparation required in this environment, but if it duplicates work by not serving as a perfect proxy for all the unexpected imperfections that a real production environment offers, then you can expect offline programming to perhaps limit some costs but actually involve more work than traditional programming.
Usually work is the largest cost center of programming tasks, while any wasted material or damaged equipment renders the concept of “payback” on OLP to be totally irrelevant. The Romans might have said “caveat emptor” – we can put it more simply as: buyer beware.
Age of autonomous manufacturing is upon us, and the real benefit is labor-saving and entirely new skills paradigms that no longer require tedious robot programming as a core competency.
This is fundamentally an enabler for the productivity of thousands of engineers who are managing a variety of industrial operations without the benefit of real automation technologies. In fact, high-mix manufacturing very often uses no manufacturing automation whatsoever despite the critical role these firms play in producing so many of the essential and critical goods we use in our daily lives.
With autonomous robots, these engineers will be able to go from “knowing they can do better” to actually doing it, because despite the fact that they can know they can do better, very few systems that allow them to do so exist today. With tools like Omnirobotic’s Shape-to-Motion™ Technology at their disposal, this can finally change for the better.
Omnirobotic provides Autonomous Robotics Technology for Spray Processes, allowing industrial robots to see parts, plan their own motion program and execute critical industrial coating and finishing processes. See what kind of payback you can get from it here.