In service robotics as well as in academia, flexibly designable, use-case specific controllers are used, resulting in the respective robots to mainly act as actuators with low-level control systems but without individual intelligence.
Robot Control: Using Native Programming Language or an External Controller?
Dr.-Ing. Andreas Hermann, Senior Team Leader Advanced Robotics | ArtiMinds Robotics
Both approaches have their respective advantages – and disadvantages.
In industrial context, the prevailing practice is to work with the vendor-specific programming languages in order to set up systems “from a single mold”. In service robotics as well as in academia, flexibly designable, use-case specific controllers are used, resulting in the respective robots to mainly act as actuators with low-level control systems but without individual intelligence.
There are a number of robotics companies which are currently driving this second approach in industrial context..
We would, thus, like to take the time to discuss the differences from a neutral perspective in the following blog post:
THE REQUIREMENTS
In automation engineering – thanks to relatively static structure and high predictability – there generally is a top-down methodology within programming and execution. This methodology requires a small number of degrees of freedom for the robot since its tasks are clearly defined: generally speaking, in each sequence the robot can plan and calculate motion paths as well as executing these without interruption or adaptation. For discrete points in time, camera based object detection for example can transmit the object’s position to the robot program. The latter then calculates the motion path to the object and only in the last sequence overlays the movement with force control.
In service robotics, in contrast, there mostly is the need for a control-loop based approach to movements since the robot’s surroundings are less well-defined which in turn results in higher uncertainties. Thus, in academia layered models with bidirectional vertical flow of information are used, granting the robots higher degrees of autonomy and adaptability on all levels. Examples for this are behavior-based decision models or real-time control engineering for visual servoing (tracking of dynamic targets).
THE ADVANTAGES
Individual controllers are subject to only a small number of constraints, which offers flexibility in the design of system architecture. Hardware and software (incl. operating system and programming language) can be selected freely in order to benefit from their individual advantages or in order to feed-in previous work without the need for porting. This in particular enables the use of arbitrary sensors normally not compatible with the specific robot vendors technology. Constraints in the control system solely result from limitations in the dynamics of the actuators and the interfaces of the robot. Thus, also multi-overlaid control models are feasible (such as null-space control or the obeying of hard and soft constraints during runtime).
In the industry, the benefits of native programming predominate: comprehensive warranty and support options offered by the robot vendors. This is possible because the programming and execution takes place on the original robot controller. Programming is conducted with the tools and languages developed by the vendor. Additional hardware is certified or only available through thoroughly tested protocols. Thus, deterministic behaviour is guaranteed at any point in time, assuring the predictability of the robot’s dynamics and with that its cycle time. Hardware and software components are harmonized with one another in order to yield optimal performance whilst predefining limits of secure use. Furthermore, the clearly defined set of thoroughly tested commands allows the creation of comprehensive documentation and eases support in case of error cases.
LIMITATIONS AND RISKS
Using an environment specified by the robot manufacturer requires expertise in programming as well as dealing with its potential shortcomings and limitations. The overall system can only achieve what the robot manufacturer provides and allows. This usually also means that during runtime the robot can only achieve what was envisioned at programming time.
An individual controller on the other hand offers high potential for malfunction, since a multi-layered system with several components is involved – an individual system for which the responsibility for compatibility is with the user. Thus, a very deep understanding of the hardware and its dynamics is an absolute prerequisite. Without it, there is the possibility of overloading the hardware through faulty control, for example if dynamics are demanded of it, which it cannot serve. This generally makes it much more difficult to receiving certification of safety for such a system.
CONCLUSION
Of course, many industrial robots also allow mixed operation, which makes it possible to connect individual sensors or external controllers for special scenarios. In this way, it is often possible to apply correction offsets to single, otherwise static trajectories (superposition) and also to monitor these in regards to safety-relevant thresholds. By carefully mixing, the advantages of both approaches can be utilized while disadvantages have to be borne only for small program sections.
With its Robot Programming Suite (RPS), ArtiMinds reduces the programming effort in the robot’s native language to a minimum, additionally allowing the porting of know-how between different vendors. Thus, our customers can concentrate on their processes while still benefiting from all advantages of native programming – especially for sensor-adaptive movements!
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Comments (0)
This post does not have any comments. Be the first to leave a comment below.
Featured Product
