Page - 83 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

hardware/software). The overall system should not just act as a ROS system with add-on safety, but integrate safety inclusively. We propose a safety-enabled system architecture that solves the safe robot perception and control task through 3 levels of hardware abstraction. Basis for this architecture that is given in Figure 2 is a safety-rated robot controller (in our case the KUKA Sunrise controller for the sensitive iiwa robot). High level control is implemented in ROS running on separate (Linux-based) controllers. In between those two control layers, we introduce a safety-rated controller (e.g. a safety PLC) that connects to both, safety-rated sensors (safety LIDARS in our case) and the safety-rated input of the low-level controller. This allows us to implement dependable safety functionality that goes beyond the simple safety-logic of the low-level controller. However, it might also be implemented directly on the low level controller if thedeviceoffers to implementhigh integritysafety functions. This layered model clearly defines a priority structure where the safety-enabled control system takes control whenever a critical safety issue is detected. Thus, there is no direct connection that allows the ROS System to issue control actions for the low level controller except the authorized connection through this safety control layer. Robot-Controller (e.g. KUKA Sunrise for KUKA iiwa) Safety-enabled Control System High-level Control System (ROS System) Sensors Safety Sensors ROS Safety Socket Fig. 2. Safety-enabled Architecture Up to now, this structure resembles the classic add-on safety architecture. However, we intend to go beyond this architecture that will enable more inclusive perception and control schemes. As a consequence, we propose to provide a highly dependable ROS safety socket that connects the safety-controller to theROSenvironment.Furthermoresafety sensors could be connected to the ROS environment as well. For example our safety LIDARs provide safety-enabled outputs that define region interceptions through (safe) binary signals, whereas the more informative LIDAR scan is pro- vided through standard interfaces to the ROS system. With our safety socket, we intend to enable ROS functionality not just at different levels of priority, but also at different levels of dependability. This safety-socket is only one pre-requisite. We also have to provide dependable and in particular trust- worthy ROS nodes and communication between them and the socket. The standard ROS system does not address IT security adequately [15]. To compensate for this security flaw, our institute colleagues recently proposed a scheme for application-level security and safe communication [3], [1] for ROS that is now under consideration by the Open Source Robotics Foundation (OSRF) to be included in the SROS project for future public release. Alongside of this implementation effort that will provide the necessary building blocks for a safety-rated perception and control functionality, we evaluated possibilities for func- tionally rich and safe multi-sensory perception using the standard ROS environment as an experimental testbed. We have set up a heterogeneous perception system comprising of two safety-rated OMRON OS32C laser scanners with data fusion running on two different computers and one or two ToF cameras for acquiring 3D data from the environment (the aforementioned PMD Pico Flexx camera and the single- beam ToF sensors Terraranger). We consider the proper com- bination of different technologies of parallel and independent sensors and the resulting high redundancy as a prerequisite for fulfilling safety requirements. Additionally, to achieve robustness in case of local failures, it is necessary to mount thesensors inadistributedway.Asabasis formakingsafety- related decisions in the running system, we are going to define a distinction of three danger zones that are reported by our sensor fusion:Danger,Warning, and Safe. Their origin is in the origin of a robot, and they are surrounding the robot in a circular way. The border between danger andwarning zones is defined using safety separation distance defined in ISO/TS 15066 [12]. Using distance of a moving object from a depth sensor, it will be decided in which danger zone the movement is detected. The example setup of sensors which is shown in Figure 3 results the sensor fusion shown in Figure 4. Sensors are mounted close to each other, which leads to a higher chance for all sensors to fail together when a local hazard happens (e.g.physicaldamages).Knowing that, andalso fora specific collaborative use case, sensors are mounted as shown in Figure5.Regardingmodulararchitectureandreproducibility, it is also very easy to change the mounting for other use- cases and workspaces. However, more automatized setup of sensors for maximum coverage of the workspace and their calibration is planned for the future work. Fig. 3. Example of a prob- lematic setup where 3 different types of sensors are mounted just next to each other. This setup increases the chance of perception failure due shadow- ing effects and local hazards such as physical damages. Fig. 4. Visualization of the 3D position data in RViz obtained from Teraranger Tower (8 pink points), Pico Flexx Cam- board ToF camera (colored points), and laser scanner (white points). 83