Skip to content

Recurring Problems When Programming Robots and How to Move Past Them

With the increasing abundance of robots, you need a relative increase in engineers to set them up for each company. So how complicated of a process is programming a robot? 

The truth is that it’s pretty difficult! There are many factors to consider, including the robot’s capabilities, the space surrounding the robot, how the robot will move, and of course, the programming language necessary to program the robot. 

Robots are essentially motion recording devices that allow you to generate a procedure. The procedure in question – varying from company to company – will likely only be relevant to a single function in which the part processes or other variables remain constant at all times. While this method could still be useful for a number of processes and companies, sometimes it can be done in a smoother fashion.

Let’s go over which problems are the most common and how, exactly, they affect development.

Programming Languages

Like with any verbal language, programming languages exist in abundance. Each language is used for a specific purpose, but it isn’t feasible for a programmer to learn a plethora of different languages. 

Manufacturers and the robots they develop use different languages. What ABB uses isn’t quite what FANUC uses, and what FANUC uses isn’t what Universal Robots uses. Germán Villalobos, an AI and robotics engineer explained in a LinkedIn article that each manufacturer will “have more than [three] different brands installed in their cells and production lines, which further complicates their robot programming training.

Automation engineers and programmers would essentially have to learn each robot manufacturer’s programming language if they want to work efficiently on their assigned robot. However, learning an entire language, let alone a programming language is an arduous task that will take hours to learn and even more to master.

The Top 8 Languages Tested Together
While new programming languages emerge every few years, the main ones still reign with JavaScript dominating. Chart via Devskiller.com

High Costs, Low Time

Based on various reports, including the aforementioned LinkedIn article, it can take over 70 hours to properly learn just how to develop a simple application in any given programming language. Multiply that by the number of robots you have with their own individual languages and add the time it’ll take to complete an automation system, and suddenly you have weeks of training that needs to get done.

The cost of investing in training for every employee who needs to learn an additional language could be astronomical depending on the sheer number of employees. As well, you have to factor in equipment like cameras, computers, and well the robots themselves if you’re buying new technology.

Villalobos estimated that for each person trained, it could cost up to $15,000 per person. That number only gets higher with each new brand of robot a company acquires. To avoid spending all this money on training, it’s important to find alternatives such as hiring employees who are familiar with programming specific types of robots, or simply moving away from programming altogether and opting for a behavior-based robot instead.

The Complexity of Programming Robots

Teacher Giving Computer Science Lecture to Diverse Multiethnic Group of Female and Male Students in Dark College Room. Projecting Slideshow with Programming Code. Explaining Information Technology.
While learning isn't inherently a bad thing, it can be a burden for companies trying to keep their employees up to date on new programming languages only suited to a specific robot brand.

The myriad of programming languages and the high cost might lead you into thinking programming robots is complex. It most certainly is, but those factors are merely small factors in the complexity scale.

Robotics companies don’t even hide how complicated it can be to program a robot. In fact, DIY Robotics has a page dedicated to some recurring problems a programmer will encounter when working on robotics projects. In brief, they describe problems during the programming process that include misunderstandings of the physical limitations and capabilities of the robot. However, to ease the burden, they suggest using tools that each robot manufacturer offers to lessen the burden.

Villalobos continued in his article that robot programming is too difficult to do properly and efficiently work on robots. He argues that robot programming “has the same bases of computer science plus the difficulty of handling the different mechanics of robot arms, electronics controllers with software that differ between manufacturers; and that are also highly customizable for different processes and different industrial quality and safety standards.”

With so many variables to consider along with the rigidness that programming brings, it can be overly complicated to properly program a robot within a reasonable amount of time to perform specific tasks.

Academics and Programming Robots

The complexity of programming robots is not only known to manufacturers but academics have also noted this. In a study conducted by Eleonora Bilotta and Pietro Pantano for the University of Calabria back in 2000, they analyzed a variety of problems including the “difficulties in programming the robot control [and] the organization of the program in relation to hardware, software, behaviors, and performance design in robotics.”  Specifically, they focus on robotics in relation to teaching control to children. While this isn’t exactly manufacturing, their discoveries and criticisms of programming are pretty similar to those encountered in that field.

Across the study, Bilotta and Pantano argue that the current method of programming robots could be better and lean toward modern proceedings including bottom-up robotics and behavior-based robotics. And though 22 years have passed since the study’s publication, some of their criticisms still remain relevant.

They describe some of the pains they encountered with programming, including the lengthiness of the process as well as every external factor that could come into play when trying to execute a specific action. Instead, they prefer to try and work through behaviors.

“From the programming point of view, the behavior space of the robot is defined by the locations the robot can reach (or by the set of actions it has to exhibit in the physical space) and by the transition between those locations. Even if the robot can attain a nearly infinite number of states, it is better to design a useful behavior space in which the programmer limits him/herself to a small number of states,” they state. 

They imply freeing up time thanks to behaviors better understanding the capabilities of robots while not taking up as much time to get them running. Even more than 20 years ago, behavior-based robotics was seen as the future. 

Behaviors for All!

Robot programming is an intricate skill, craft, or trade – call it what you want – but it needs to evolve. In software programming, new languages emerge every decade, or even every few years, either rendering older languages obsolete or confusing older engineers by adding to the amount of knowledge they need to amass to do their job.

Open-source solutions include Swift, Rust, and Kubernetes which only gained popularity over the last few years. They’re far from being the most dominant, but their emergence isn’t negligible.

Machine builders and integrators are not programmers by trade – they’re designers. Designers need simple solutions. They need to be able to do more with fewer (or even) lines of code.

Behavior-based robotics is on the way to becoming the best way for robotics to move forward without the crutch of having to adapt to new languages every time they come out. Instead of relying on preset calculations that can handle a fixed process, behavior-based robotics adapts to its environment to perform a series of heterogeneous tasks. 

They can adapt using sensors essentially telling the robot what the piece is, its dimensions, and how it can best perform the task it was set up to do. All this is done through an interface that is more user-friendly and that takes away the need to parse through hundreds of lines of code.

Setting up an autonomous robot for the first time seems like the dawn of a new era, but it can also be misleading. To the untrained ear, the word “autonomous” sounds like it can do anything based on the power of AI alone, or something along the lines of Wall-E from the Disney movie. While performing any task might be a tall order right now, an autonomous robot can perform a specific task given it’s been programmed to do so. The real question remains: do you still want to be programming robots well into the future?

Arbitrator
An example of how behavior-based robotics could work for an open-source project on Github.

With AutonomyOS™ and AutonomyStudio™, your flexible automation cell will be as powerful as ever. With the ability to set up behaviors to execute tasks such as paint spraying, sanding, welding, and more, you’ll find all the flexibility you want for your manufacturing needs. Contact us to learn more