Pro­gram­ming indus­trial robots

In robotics, there are two fun­da­men­tally dif­fer­ent approaches to pro­gram­ming indus­trial robots for its indi­vid­ual task: either via the respec­tive native pro­gram­ming lan­guage as defined by the ven­dor or through the imple­men­ta­tion of an exter­nal pro­pri­etary con­troller which con­trols the robot fine-gran­u­larly. These con­trollers are typ­i­cally imple­mented with the help of the Robot Oper­at­ing Sys­tem (ROS). Both approaches have their respec­tive advan­tages – and disadvantages.
In indus­trial con­text, the pre­vail­ing prac­tice is to work with the ven­dor-spe­cific pro­gram­ming lan­guages in order to set up sys­tems “from a sin­gle mold”. In ser­vice robotics as well as in acad­e­mia, flex­i­bly des­ignable, use-case spe­cific con­trollers are used, result­ing in the respec­tive robots to mainly act as actu­a­tors with low-level con­trol sys­tems but with­out indi­vid­ual intelligence.
There are a num­ber of robotics com­pa­nies which are cur­rently dri­ving this sec­ond approach in indus­trial context..

We would, thus, like to take the time to dis­cuss the dif­fer­ences from a neu­tral per­spec­tive in the fol­low­ing blog post:
.

Indi­vid­ual con­trollers are sub­ject to only a small num­ber of con­straints, which offers flex­i­bil­ity in the design of sys­tem archi­tec­ture. Hard­ware and soft­ware (incl. oper­at­ing sys­tem and pro­gram­ming lan­guage) can be selected freely in order to ben­e­fit from their indi­vid­ual advan­tages or in order to feed-in pre­vi­ous work with­out the need for port­ing. This in par­tic­u­lar enables the use of arbi­trary sen­sors nor­mally not com­pat­i­ble with the spe­cific robot ven­dors tech­nol­ogy. Con­straints in the con­trol sys­tem solely result from lim­i­ta­tions in the dynam­ics of the actu­a­tors and the inter­faces of the robot. Thus, also multi-over­laid con­trol mod­els are fea­si­ble (such as null-space con­trol or the obey­ing of hard and soft con­straints dur­ing runtime).

In the indus­try, the ben­e­fits of native pro­gram­ming pre­dom­i­nate: com­pre­hen­sive war­ranty and sup­port options offered by the robot ven­dors. This is pos­si­ble because the pro­gram­ming and exe­cu­tion takes place on the orig­i­nal robot con­troller. Pro­gram­ming is con­ducted with the tools and lan­guages devel­oped by the ven­dor. Addi­tional hard­ware is cer­ti­fied or only avail­able through thor­oughly tested pro­to­cols. Thus, deter­min­is­tic behav­iour is guar­an­teed at any point in time, assur­ing the pre­dictabil­ity of the robot’s dynam­ics and with that its cycle time. Hard­ware and soft­ware com­po­nents are har­mo­nized with one another in order to yield opti­mal per­for­mance whilst pre­defin­ing lim­its of secure use. Fur­ther­more, the clearly defined set of thor­oughly tested com­mands allows the cre­ation of com­pre­hen­sive doc­u­men­ta­tion and eases sup­port in case of error cases.

Using an envi­ron­ment spec­i­fied by the robot man­u­fac­turer requires exper­tise in pro­gram­ming as well as deal­ing with its poten­tial short­com­ings and lim­i­ta­tions. The over­all sys­tem can only achieve what the robot man­u­fac­turer pro­vides and allows. This usu­ally also means that dur­ing run­time the robot can only achieve what was envi­sioned at pro­gram­ming time.

An indi­vid­ual con­troller on the other hand offers high poten­tial for mal­func­tion, since a multi-lay­ered sys­tem with sev­eral com­po­nents is involved – an indi­vid­ual sys­tem for which the respon­si­bil­ity for com­pat­i­bil­ity is with the user. Thus, a very deep under­stand­ing of the hard­ware and its dynam­ics is an absolute pre­req­ui­site. With­out it, there is the pos­si­bil­ity of over­load­ing the hard­ware through faulty con­trol, for exam­ple if dynam­ics are demanded of it, which it can­not serve. This gen­er­ally makes it much more dif­fi­cult to receiv­ing cer­ti­fi­ca­tion of safety for such a system.