Robot Simulation and Monitoring on Real Controllers (RoboSiM)

Transcription

1 Robot Simulation and Monitoring on Real Controllers (RoboSiM) A. Speck Wilhelm-Schickard-Institut für Informatik Universität Tübingen D Tübingen, Germany KEYWORDS Industrial Control, Real-Time Simulation, Object- Oriented. ABSTRACT The rapid evolution of standard hardware such as workstations and PCs made it possible to develop workstation or PC based robot controls. RoboSiM, a robot simulation and monitoring system, is based on such a robot control. RoboSiM runs on the real robot controller which may be either a SPARC workstation or a PC. Traditional systems simulate both, the robot arm and the robot control. The basic idea of this new concept is that only the devices (robot arm or peripheral devices) are simulated. These virtual devices are controlled by the real control system. Hence the simulation is very realistic. The new system visualizes real devices as well as simulated devices in a Java applet. Therefore a scenario blending real and virtual devices can be displayed at the same time. The Java applet as Graphical User Interface (GUI) can be exported to other hosts via Intranet or Internet. 1 INTRODUCTION An emerging trend in robot control design is to use powerful standard hardware such as PCs or workstations instead of proprietary solutions. These PCs or workstations have enough computing power not only to control a robot but also to simulate robot arms. RoboSiM is a simulation and monitoring tool based on the HIGHROBOT control (Küchlin et al. 1997b). RoboSiM allows to simulate a robot as well as to monitor a real existing robot arm at the same time on the same piece of control hardware. In contrast to other robot simulation systems, RoboSiM runs on the real control using the real control software. This new simulation concept runs Simulation Tasks under most realistic conditions. Robot programs controlling a virtual robot have the same temporal behavior as robot programs controlling a real device because these tasks are processed on the real control. The behavior of the real robot arm is known and modelled in a simulation task. The focus of this paper is the integration of a simulation and a monitoring system into a robot control. The main characteristics of this new approach are: First, real devices can be monitored while a robot is simulated at the same time. Secondly the simulation components are integrated in the control system without changing the architecture of the control or affecting the temporal behavior of the control. Finally the Graphical User Interface visualizes the robot and enables the user to interactively manipulate the real device or simulation. 1.1 Usage of RoboSiM RoboSim can be used for different purposes: 1. Education and research: The simulation realistically substitutes a robot. Demonstrations can be done with the virtual robot within lectures. Virtual robots can be used in combination with real robots. It is possible to build and test virtual production lines with one real robot which is monitored and other collaborating robots which are simulated. Real and virtual devices can be blended. The virtual robot can be examined in extreme situations without damaging an expensive real robot arm.

2 2. Development of robot programs: The simulation improves off-line robot programming (development of robot programs without teaching). The motions of the robot are simulated and the model of the robot is displayed on the screen. The robot model is either moved manually (by keyboard or mouse commands of the programmer) or according to position data from a CAD database (McKerrow 1995). 3. Remote Access to the monitoring and simulation system: The Java Graphical User Interface can be exported via Intranet or Internet to any computer with a Java browser (Speck 1998). Moreover this new concept for the simulation and monitoring of devices can be extended to all automation controls such as PLCs (Programmable Logic Controllers) or NCs (Numeric Controls). 1.2 Other Simulation Systems Most robot simulation systems are used for training and off-line programming. Some simulation systems like Robotic HyperBook (RHB) (Maglica and Martenson 1995) are optimized for computer based training. Other simulations especially support off-line programming. Examples are ROPES (Arjanne and Suutarinen 1994) or MOSES (Bickendorf 1994). Few systems like RobCAD can be used for both purposes. These systems usually run on a special computer such as an SGI workstation and not on the real robot control. Some of these systems like RobCAD already include parts of the original control code, but this is just an approximation of the behavior of the real control. traditional Robot Control e.g. Bosch rho 3 Robot Cell with industrial Robot e.g. Bosch SR 60 off-line Simulation e.g. RobCAD on SGI Workstation Simulation System contains Parts of Robot Control Software Figure 1. Traditional Control and Simulation Systems In comparison with these simulation systems RoboSiM has the advantage, that there is no gap between the simulation and the control system, because both run on the same piece of hardware. and the behavior of the simulation model. Therefore the behavior of the robot control is part of the robot simulation model. A detailed model of the robot kinematics behavior is currently not part of RoboSiM. Conversion of the simulation coordinates to the real robot values is not necessary. The behavior of the simulated robot model can be directly compared to a real robot arm. 2 PROPERTIES OF RoboSiM 2.1 Hardware As control hardware the simulation and monitoring system uses either a SPARC workstation (operating system Solaris 2.x) or a PC under Windows NT 4.0 (cf. section 5). The RoboSiM robot control components control an entire industrial production cell including a robot and peripheral devices. remote Host exported GUI RoboSiM SPARCstation or Windos NT PC Field-Bus Transfer System Drive Controllers for Robot Drives SCARA Robot Arm Industrial Robot Cell Figure 2. Hardware Configuration I/O Units Currently a Bosch SR 60 SCARA (Selective Compliance Assembly Robot Arm) can be simulated and monitored by the system. Other industrial peripheral devices, such as digital I/O units, can be simulated, but the result of the simulation is only displayed on a non graphical ASCII terminal. The visualization of these devices in a Graphical User Interface is intended to be also supported. The devices of the robot cell (robot arm and I/O devices) are connected via a CAN field-bus

3 (Controller Area Network) to the control computer (Küchlin et al. 1997c, CiA 1995a). 2.2 Graphical User Interface The Graphical User Interface (GUI) is implemented in Java which supports the development of graphical interfaces. In contrast to other user interfaces like X Window System or OSF Motif Java has the advantage to be portable to many platforms. Furthermore the Java applet can be displayed on remote hosts. In (Küchlin et al. 1997a) the idea of an abstract client / server approach for a Java remote connection is emphasized whereas RoboSiM realizes a stable and reliable Internet connection via sockets. The GUI (Speck 1998) is used for simulation as well as for monitoring which makes it possible to compare the virtual model with the reality. The user interface is kept simple, so that it costs only little computing power. coordinates of the tool center point (coordinates of the robot's end effector) displayed at the bottom of the robot. In the command field the user can interactively move the robot and start or terminate a robot program. He can also change the perspective and the direction from which he looks at the robot arm. 3 SYSTEM DESIGN The robot simulation and monitoring system has an object-oriented design (Hill 1996). It is based on the HIGHROBOT control (Küchlin et al. 1997b), an open object-oriented robot control running on a SPARC multiprocessor workstation. Therefore RoboSiM reuses some components of HIGHROBOT, but the central components of the simulation and monitoring are additionally developed. RoboSiM Robot Simulation & Monitoring System JAVA Applet as GUI Grapical User Interface Layer Stream Socket Interconnection Layer Interconnection Task User Library Classes Robot Application Task User Library Classes Peripheral Device Task User Library Classes Application Task Layer User Class Library Layer Communication Subsystem Communication Layer Can-Bus Shared Memory SWITCH real Robot real peripheral Devices Simulation Subsystem Device and Simulation Layer Figure 4. Design of the Simulation and Monitoring System Figure 3. GUI of RoboSiM The RoboSiM GUI (cf. figure 3) consists of the robot arm and a command field with buttons and scroll bars. Like in other simulation systems (Laloni and Wahl 1995) the robot is presented as a solid or wire frame model with the actual The system has a layered architecture (cf. figure 4) which is a common approach in the development of object-oriented real-time systems (Selic et al. 1994, Morris et al. 1995). All layers except the Java GUI layer are implemented in C Device and Simulation Layer This is the lowest layer. It consists of real devices and simulated devices. Both real and virtual

4 devices can be part of the same RoboSiM system, which means that real as well as simulated robots can be monitored with RoboSiM at the same time. The real devices are connected to the Communication Layer via the field-bus CAN (Controller Area Network). The Simulation Subsystem consisting of different simulation tasks runs on the control hardware. Each simulation task represents a simulated device. Instead of a field-bus, shared memory is used to connect the simulation tasks with the Communication Layer. 3.2 Communication Layer (Communication Subsystem) This layer manages the communication with the real and simulated devices. The Communication Subsystem cyclically receives and transmits the messages from and to the device. It reads the received messages from the real or virtual devices and stores the CANopen message received from the devices in a receive buffer (a shared memory region which can be accessed by the Application Tasks and Interconnection Task). After the reception of messages the Communication Subsystem sends the messages of the transmit buffer (also a shared memory region which can be accessed by the Application Tasks and Interconnection Task) to the devices. Besides the exchange of data with the devices the cyclic Communication Subsystem synchronizes the Application Tasks and the Simulation Subsystem. 3.3 User Class Library Layer The User Class Library provides classes which are necessary to control the robot and the peripheral devices. These classes are used by the Application Tasks and the Interconnection Task. For each device a specific set of classes exists. An Application Task can use more than one set of classes in order to control more than one device. For example an Application Task which controls a robot arm and an I/O module uses both the robot class set and the I/O device class set. A more detailed description of the User Class Library can be found in (Küchlin et al. 1997b). The User Class Library can be used to control both real and simulated devices. 3.4 Application Task Layer and Interconnection Layer The Interconnection Layer and Application Task Layer are two components on the same level. However they have different functionality. The Application Task Layer consists of Application Tasks which use the User Class Library to control devices. The Interconnection Layer is a special type of application. It connects the Graphical User Interface with the Communication Layer. The Interconnection Layer receives commands from the Graphical User Interface and interprets them The commands are either requests for manipulating a special device (e.g. move the robot arm) or requests to start or terminate Application Tasks. Bidirectional stream sockets are used as connection between the Interconnection Layer and the Graphical User Interface. 3.5 Graphical User Interface Layer In contrast to the other components of the simulation and monitoring system the Graphical User Interface is programmed in Java. Therefore this user interface can run on other (remote) system platforms. The user manipulates the system via the GUI. The Graphical User Interface shows the current position of the robot arm on the screen. The user moves the robot interactively or starts and stops Application Tasks. The user can start different Graphical User Interface Systems in order to see different devices working. For example one user interface window shows the position of a real robot while other windows visualize simulated devices. 4 CONCEPT OF THE SIMULATION SUBSYSTEM RoboSiM communicates via CAN with CANopen devices (robot and peripheral devices) (CiA 1995a, CiA 1995b, CiA 1997). Hence the Simulation Subsystem (cf. section 3.1) models devices with a CANopen communication interface. In contrast to the real devices which are connected via the CANbus the virtual robot communicates via shared memory with the control system (Communication Subsystem). The Simulation Subsystem is activated

5 by the Communication Subsystem in each communication period. The Simulation Tasks model the behavior of real devices and generate the same messages (according to the CANopen protocol). These CANopen compliant messages contain the actual data from the simulated devices (e.g. actual position of the virtual robot). These data are delivered at exactly the same time as real devices would transmit their CANopen messages. Therefore it makes no difference for the communication layer whether it communicates with a real or a simulated device. 4.1 Robot Arms and CANopen Servo Drives The real Bosch SR 60 SCARA consists of four CANopen servo drives. In order to move the robot arm, the control only communicates with these drives. Consequently the servo drives represent the interface of the robot. The Simulation Task of the virtual SCARA has four drives like the real robot. Speed (rpm) ideal Trajectory cyclic Synchronization Signals (SYNCs) Sample Points Drive reports the current Positon to the Control System. Figure 5. Behavior of Field-Bus Servo Drives time (ms) Currently the Moog CANopen drives of the Bosch SR 60 robot are simulated. The simulated Moog drives perform ideal trajectories without delays or deviation (cf. figure 5). Due to the fact that the real robot arm is very light weight the real drives almost behave like ideal drives. Therefore it is not intended to simulate drives under heavy load at the moment. When a new target position is transmitted to the virtual drives, they compute nearly the same trajectory the real drive would perform. According to the field-bus communication protocol once per communication cycle the virtual as well as the real servo drives send their current position to the Application Tasks of the control system. The position values are discrete sampled and represent no current flow. If there are any deviations they are just not captured by the sampling mechanism. These position values (from real or virtual drives) are the feedback for the control task and are visualized by the GUI. 4.2 CANopen I/O Modules At the moment only CANopen digital I/O modules are simulated as peripheral devices. In contrast to drives these devices have no specific dynamic behavior. When the request to set an output line is received by an I/O unit, the output line is immediately set without delay. The device cyclically reports the current state of the input lines after receiving the synchronization signal. The input state of I/O modules which is sent to the Communication Subsystem depends on the production environment they are connected to. Therefore it is important to find a way to describe this environment. Due to the fact that the environment of a production process controlled by digital I/O modules behaves digitally (e.g. motor off or sensor on) a proper method to define the environment is the PLC language. The PLC language consists of boolean operations using the values of the input lines. As result of the operations the output lines of digital I/O units are set or reset. Since the PLC language is used to develop Application Tasks controlling a digital production process, the PLC language is also useful to describe the reactions of this production process. Contactor 01 Motor (digital) Sensor 01 Input Lines In 01 Output Lines Out 01 digital I/O Unit Figure 6. Environment Example Field-Bus Connection to Control System We would like to illustrate our approach with a very simple example (cf. figure 6). The application consists of an electric motor which is controlled via a digital I/O device. The I/O unit output line Out 01 is connected to the Contactor 01 which switches the motor power on or off. (If Out 01 is high the power should be on, else the power is off). A digital sensor is installed at the shaft of the

6 motor. When the shaft rotates the sensor indicates high the input line In 01 of the I/O module otherwise low. L1 L2 L3 N PE Fuses Contactor 01 M 3~ Motor is running if Relais 01 closed digital I/O Unit Output Lines Out 01 Contactor 01 0 V 0 V or 24 V Figure 7. Wiring Diagram Relais 01 closed if Out 01 high (+24 V) 24 V Sensor 01 0 V In 01 digital I/O Unit Output Lines Sensor 01 closed if Motor is running Figure 7 shows the wiring diagram of the devices. According to this plan the devices would perform the above described behavior. If the motor is not damaged the output line Out 01 is just directly connected to the input line In 01. When the motor is broken In 01 will be always low. In PLC language the behavior of the system can be described very simple. If the system is correct: In 01 = Out 01; In all other cases: In 01 = 0; Other more complex systems can be simulated with this approach as well. All operations of the PLC language can be used to describe the behavior of virtual digital systems. The simulation software for these virtual devices uses the same methods of the User Class Library as the Application Tasks controlling real digital I/O units. 5 EXPERIENCES RoboSiM has been tested on different platforms. The experiences with the system are: An Application Task (e.g. robot program) controlling a virtual device has exactly the same temporal behavior as a task communicating with a real device. On both Solaris workstations and Windows NT PCs there is no difference between applications controlling real or virtual devices. On a SPARCstation clone with two 50 MHz SuperSPARC processors and 64 MByte memory (operating system Solaris 2.4) the Simulation Subsystem causes a system load of less than 10 % while the robot control system causes not more than 25 % load (measured with the Performance Meter tool of Solaris 2.4). This means that the Simulation Tasks have no temporal influence on the robot control system and the Application Tasks. A similar behavior can be detected on the PC with Windows NT 4.0 as operating system. The Simulation Subsystem on a PC with an AMD K5 100 MHz processor and 40 MByte memory takes up to 25 % load while the robot control causes less than 35 % system load. The tool used for the measurements is the Windows NT task manager. RoboSiM is portable. It has been tested on different SPARC workstations, e.g. SPARCstation 4, SPARCstation 10, SPARCstation 20 and UltraSPARC with the operating systems Solaris 2.4, Solaris 2.5 and Solaris 2.6. The Windows NT version of the simulation and monitoring system has been tested on PCs with AMD K5, AMD K6 and Intel Pentium processors (Windows NT 4.0 as operating system). The GUI of RoboSiM can be exported to remote hosts via Intranet or Internet. The Java applet is used as Graphical User Interface which indicates the actual position of the real or simulated robot. The average response time in an Intranet (within one 10 MBit/s Ethernet segment) is less than 2 s while the response time of an Internet connection Reutlingen to Tübingen with a 2 MBit/s connection, distance 10 miles) is between 1 s and 10 s. This delay is not caused by the net communication time. The most time is lost by the processing of the TCP/IP protocol stack. In contrast to traditional simulation systems the advantage of RoboSiM is that virtual and real robots can be blended. This opens a new application domain for simulation systems. Three concrete applications are:

7 1. In education and training real and virtual devices can be controlled by the same control system. Therefore the number of expensive real robots can be reduced. Trainees are beginning to work on virtual robots. At the end of the course they test their experience on a real system without changing the used control system. Therefore they already get a very realistic impression while training with the simulation. It is even possible to compare real and virtual devices while they are controlled by RoboSiM at the same time. 2. From remote hosts users can have access to simulated as well as real systems. The Java visualization is highly portable and runs on all platforms with a Java virtual machine. On every monitoring device the same GUI is displayed. Additionally many users from different locations can watch virtual or concrete robot arms. 3. RoboSiM supports the off-line programming better than traditional simulation systems. In contrast to these simulations RoboSiM uses the real control system. Only the devices are virtual and the behavior of these simulated devices can be arbitrarily approximated to the reality. If the concrete deviation of a specific robot arm is known (e.g. these data can be collected by the robot control) a very realistic virtual device can be modelled. Such a simulation is much more concrete than a conventional off-line programming system. The sophisticated calibration of the robot arm in order to compensate the tolerance can be omitted. Robot programs developed by a traditional off-line system need such a calibration due to the divergence of the ideal world coordinates in the simulation and the real world. 6 CONCLUSION We have developed a powerful robot simulation and monitoring tool based on an open robot control. This new system runs on a real robot controller (SPARC workstations with Solaris 2.x or Windows NT PCs). Instead of simulating all (robot control system and real devices) RoboSiM uses a robot control which controls simulated devices as well as real devices. Therefore the simulation is very realistic. The user can manipulate both virtual and real robot arms with the Java Graphical User Interface of RoboSiM which also displays these devices. This Java user interface allows to gain profit from all possibilities given by the Intranet or Internet, e.g. remote control or remote maintenance. BIOGRAPHY Andreas Speck studied automation engineering at the Fachhochschule Reutlingen and computer science at the Universität Tübingen. Currently he is scientific assistent at the Department Programming Languages and Compilers of the University of Tübingen. REFERENCES Arjanne, P. and Suutarinen, J.J "Fully automatic offline programmable robotized press brake controlled with two transputer based multi axis controllers." In Proceedings of 25th, Int'l Symposium on Industrial Robots (Hanover). Bickendorf, J "Full-Automatic Off-Line programming of Complex Cutting Paths - A Contribution to the Economic Production of "Lotsize 1"." In Proceedings of 25th, Int'l Symposium on Industrial Robots (Hanover). CAN in Automation e.v. (CiA) CAL based Communication Profile for Industrial Systems, CiA Draft Standard Proposal DS-301. CAN in Automation e.v. (CiA) CAL based Device Profile for I/O Modules, CiA Draft Standard Proposal DS CAN in Automation e.v. (CiA) CAL based Device Profile for Drives and Motion Control, CiA Draft Standard Proposal DS-402. Hill, D.R.C Object-Oriented Analysis and Simulation. Addison-Wesley, Harlow, England Küchlin, W.; Gruhler, G.; Lumpp, T.; Speck, A. and Rupp, A "HIGHROBOT: Telerobotics in the Internet." In Proceedings of ETFA'97, Int'l IEEE Conference on Emerging Technologies and Factory Automation (Los Angeles) IEEE Küchlin, W.; Gruhler, G.; Speck, A. and Lumpp, T "HIGHROBOT: A High-performance Universal Robot Control on Parallel Workstations." In Proceedings of ECBS'97, Int'l IEEE Symposium amd Workshop on Engineering of Computer Based Systems (Monterey) IEEE Küchlin, W.; Gruhler, G.; Speck, A. and Lumpp, T "HIGHROBOT: Distributed Object-Oriented Real-Time

8 Systems." In Proceedings of ARCS'97, 14th international ITG/GI-Conference Architecture of Computer Systems (Rostock) VDI, Laloni, C. and Wahl, E "Principles of Robot Simulation and their Application in a PC-based Robot Simulation System", In Graphics and Robotics, Straßer,W. and Wahl, E., Springer, Berlin, Heidelberg, New York, 1-30 Maglica, R. and Martenson, N "Teaching Robot Programming Using CAL" In Proceedings of 26th, Int'l Symposium on Industrial Robots (Hanover) McKerrow, P.J Introduction to Robotics., Addison- Wesley, Sydney, Wokingham, Reading MA Morris, D.; Evans, G.; Green, P. and Theaker,C Object Oriented Computer Systems Engineering., Springer, London Selic, B.; Gullekson, G. and Ward, P.T Real-Time Object-Oriented Modeling., Wiley, New York Speck, A RoboSiM, Wilhelm-Schickard- Institut für Informatik, Universität Tübingen

9