COMMUNICATION, CONFIGURATION, APPLICATION: The three layer concept for Plug-and-Produce Uwe E. Zimmermann, Rainer Bischoff KUKA Roboter Gmbh, Zugspitzstraße 140 86165 Augsburg, Germany [email protected], [email protected] Gerhard Grunwald, Georg Plank, Detlef Reintsema German Aerospace Center (DLR), Institute of Robotics and Mechatronics, Oberpfaffenhofen, 88234 Wessling Germany [email protected], [email protected], [email protected] Keywords: Plug&Play, robotics, reduced set-up time, determinism, real-time communication, device description Abstract: The Plug-And-Play is a synonym for the simple use of computer systems in office applications. This appealing idea also emerges in the branches of robotics and automation. But due to their specific technical and application driven requirements i.e. real-time, determinism, safety… a simple taking over of the technology is not sufficient. Plug-and-Produce extends the “easy to use” for applications in robotics and automation. This will lead to a dramatically reduction of set-up times of work-cells. In order to fulfil the various requirements a three layered Plug-and-Produce architecture is presented. The communication layer addresses all topics regarding the bus-system level; the configuration layer is responsible for the control and operation system level; and the application layer addresses the needs of the user and system programmer. A prototypical implementation is also presented. But due to their specific technical and application driven requirements (details see in section 2) a simple taking over of PnP is not possible. Hence the 1. INTRODUCTION EU funded project SMErobot™ (SMErobot, 2005) created the term „Plug and Produce“(PnProduce) to Technically, the integration of components i.e. a express these peculiarities and to delimit from the memory stick, a camera, or a disk drive into a office applications. computer system is a very complex task. Different The potential of PnProduce is very obviously: kind of knowledge is required. This includes The set-up time of robot cells is time-consuming and hardware, communication systems, operating thus an important cost factor. It take days or even systems, programming and application interfaces. weeks just to get all peripheral systems Practically, the user wishes the simple addition of communicating and working with each other, even his new device without requiring reconfiguration or though the system was planed and designed very manual installation of device drivers. “Plug-And- detailed in advance. Costs could be dramatically Play“(PnP) is the synonym for this wish. In the early reduced, if it is possible to reduce the installation 1980s the NuBus (NuBus, 1983) which was time. Especially future robotics systems will require originally developed by MIT and used by Apple much more flexibility due to frequent task and Macintosh and Texas Instruments was one of the equipment changes. It should be possible to connect earliest PnP-busses. Today the Universal Serial Bus a new, even a priori unknown device to the robot (USB) is the widest spread and probably best known controller and to use it immediately without the need PnP-bus (Axelson, 2005). of a long and error prone manual configuration. The Plug-And-Play technology was developed Besides the reduction of costs a further important for the simple use of computer systems in office factor is the “easy to use” feature. In future, more applications. Recently this appealing idea also and more robots will find their way into small and emerged in the branches of robotics and automation. medium enterprises, into the public and the health sector. Also service robots or assistants for via real-time bus systems i.e. EtherCAT, Sercos …. entertainment and at home are emerging. These Also the single components inside a robot should be systems will be in common, that non-robotic experts connected via PnProduce. will have to deal with such complex systems. Adding of new tools, exchanging of faulty devices 2.1.1 Device exchange or upgrading the system has to be manageable without the need of an expert. A robot component i.e. a drive unit has to be By means of scenarios and use cases section 2 exchanged or upgraded. The servicing staff powers motivates the details of PnProduce and specifies the off the robot, exchanges the devices. In case of inherent technical requirements. In section 3 we PnProduce the robot has only to be switched on introduce the three layer concept of PnProduce and. being operational again. The central control unit Some first implementation results are presented in automatically identifies the new device, reads the section 4. actual device status information, configures it and integrates its functionality into the application. 2. PLUG AND PRODUCE 2.1.2 (Automatic) tool change REQUIREMENTS Especially for versatile robot assistants frequent tool changes are a common requirement. A device PnProduce concepts for industrial applications driven approach is just a subversion of the previous especially robotics can adapt existing PnP concepts use case, where a new tool (e.g. driller) is plugged to from IT. But there are some special issues that have the robot and the associated tool service (e.g. “drill”) to be covered and which are not solved by available is available for the user. solutions. By means of use cases some features of In a service driven approach the user first selects PnProduce are discussed and also the specific the service (e.g. “drill”) and then the tool that could technical requirements. perform the task is automatically selected by the robot system itself. This means that an automatic tool changer system has to be set up. 2.1.3 Start up of a new system/application In general an application can be characterized by the potential functionality of the connected components and devices. When powering on the functionalities of the devices are communicated with the central controller or a programmer. Bus, devices and robot controller are already configured for the immediate use. The application itself can be described by the detailed device configurations needed for running the task. This could be done manually or (semi-)automatic. 2.1.4 Start up of an existing system/application An application as described above may be stored Figure 1: Scenarios for PnProduce in a file. When switching on the system the controller gets all status information from the devices which are connected via the real-time bus. These data can be compared with the stored 2.1 Use Cases description of the planned application. The controller can verify whether all devices are Figure 1 shows a generic setup of a work cell connected and properly configured. If not with multiple, different robots, tools, grippers, appropriate feedback to the user can be given. hands, sensors, and controllers. They are connected 2.2 Deterministic and Real-time by the user. Examples are “gripper open” or “sensor Communication on”. They are typically for actuators and tools that are connected to the robot controller. The philosophy of commands is very similar to the The communication in robotics and automation Service Oriented Architecture (SOA) approaches. must guarantee some features to facilitate a proper Most existing robot languages are command based and safe operation of the system. One of the most and therefore PnProduce concepts could be important features are real-time and determinism. As integrated seamlessly. there are multiple specifications on the term real- Events are used for the asynchronous transfer of time, we will use in the context of PnProduce: “The small data sets to inform the control system or the timing constraints of the system must be guaranteed devices on their actual status. They may also be used to be met. Guaranteeing timing behaviour requires for setting parameters of the attached devices and/or that the communication is predictable”. The term software. deterministic tightens the requirement in real-time The parameters may be classified in static and communication. It is not sufficient to guarantee the dynamic parameters. The latter may be set during data within a time frame. The data have to be system start-up or in case of configuration purposes. delivered at a precise time. But they cannot or should not be changed during run-time. Thus there is no need to include these 2.3 Static and dynamic parameters parameters in the process data sets. In general, static parameters are device specific. Dynamic parameters In the past, the application programmer dynamically lead to more flexible systems. For differentiates cyclic and acyclic communication. example, if a gripper with an adjustable gripping Cyclic data are i.e. the sensor values from a force force is used, the force parameter can be set once torque sensor or the nominal and real value of the (configuration data) before the application starts or robot joints. These data types are also called can be changed depending on what kind of object “process images” (CAN, 2007), that are a complete has to be gripped (process data). or partial local data base. The application or the Commands and events are still called acyclic devices operate only on this local data, whereas the even it is communicated in a cyclic manner on the bus system is responsible to keep the distributed data bus level. The process images as well as the data consistent. The advantage is that communication and exchange between the local data bases has to be application are highly decoupled. Another important configured, which is a complex task and leads to factor is the deterministic exchange of data as the high demands for a PnProduce system. This is bus load is constant and could be analyzed a priori. especially true if the data exchange should be dynamically changed. robot controller (master) Application 2.4 Plug-And-Play Variants (acyclic) read/write There are different grades in the performance of process image Plug-And-Play systems.