Sensor-Based Virtual Fences for Industrial Robot Safety Sensorbaserade virtuella staket för industrirobotsäkerhet Implementing Software-Defined Boundaries for an Industrial Robot Bachelor’s thesis in Electrical Engineering Nour Abo Saleh, Johan Grahn, Knut Grunewald, Hanna Petersén, Filip Segerberg DEPARTMENT OF ELECTRICAL ENGINEERING CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2025 www.chalmers.se www.chalmers.se Bachelor’s thesis 2025 Sensor-Based Virtual Fences for Industrial Robot Safety Implementing Software-Defined Boundaries for an Industrial Robot Nour Abo Saleh Johan Grahn Knut Grunewald Hanna Petersén Filip Segerberg Department of Electrical Engineering Chalmers University of Technology Gothenburg, Sweden 2025 Sensor-Based Virtual Fences for Industrial Robot Safety Implementing Software-Defined Boundaries for an Industrial Robot © Nour Abo Saleh, Johan Grahn, Knut Grunewald, Hanna Petersén, Filip Segerberg, 2025. Supervisors: Karinne Ramires-Amaro, Department of Electrical Engineering Maximilian Diehl, Department of Electrical Engineering Examiner: Emmanuel Dean, Department of Electrical Engineering Bachelor’s thesis 2025 Department of Electrical Engineering Chalmers University of Technology SE-412 96 Gothenburg Sweden Telephone +46 31 772 1000 Cover: Visualization of robot and sensor setup constructed in the project. (Gener- ated with ChatGPT, 2025) Typeset in LATEXGothenburg, Sweden 2025 iv Sensor-Based Virtual Fences for Industrial Robot Safety Implementing Software-Defined Boundaries for an Industrial Robot Nour Abo Saleh, Johan Grahn, Knut Grunewald, Hanna Petersén, Filip Segerberg Department of Electrical Engineering Chalmers University of Technology Abstract In industrial environments, safety has traditionally been ensured using physical bar- riers such as fences or enclosures to separate humans from robotic systems. While effective, these static solutions limit flexibility and make it difficult to adapt the layout to changing production needs. As factories become more dynamic and col- laborative, there is a growing need for smarter, more adaptable safety systems. In this project, a virtual safety system for an industrial robot was developed using LiDAR sensors and real-time data processing. The system was designed to replace traditional physical barriers by creating three safety zones around the robot a safe zone, a warning zone and a restricted zone, depending on the distance of approach- ing objects. The sensors and control electronics were built and tested in real life, while the behavior and reactions of the robot were evaluated through simulation. The system continuously monitored the area at a height of 15 to 20 cm above the floor and successfully detected objects and classified them into the correct zones.The tests showed that the system detected all intrusions correctly in both warning and stop zones. The average response time was around 10 ms, which is fast enough for real-time feedback. However, the system experienced false intrusions in some cases, especially when using larger zones and more active components—up to 601 false triggers during 20 minutes recorded in one test. The results demonstrate that the system was able to trigger appropriate responses based on risk level, and show that virtual safety zones could be a viable and flexible alternative to traditional physical fences in industrial robot applications. Keywords: Virtual fence, Industrial robot, LiDAR, SSM, Speed and Separation Monitoring, ROS 2, Safety System, Object Detection. v Acknowledgements We would like to express our gratitude to our supervisor, Karinne Ramirez-Amaro, for her contributions throughout the project. Her feedback, suggestions and guid- ance has been valuable in helping us in making progress through the whole project. In addition, we would like to thank Maximilan Diehl who helped us in the second half of the project. He made it possible for us to continue making progress in the project during the time that Karinne was unavailable. Without him we would not have been able to finish the project in time, so thank you. Furthermore, we would also like to thank Emmanuel Dean for his guidance and knowledge concerning ROS 2. If not for his crash course in the software we would not have been able to make as much progress as we did. AI usage In this study AI has been used for multiple different purposes. No text has been entirely written by AI, but both ChatGPT and Copilot has been used for spellcheck- ing and for improving grammar. Both ChatGPT and Copilot has also been used to refine and debug code. vii List of Acronyms Below is the list of acronyms that have been used throughout this thesis, listed in alphabetical order: CSV Comma-seperated values DToF Direct Time-of-Flight FTP File Transfer Protocol HRC Human-robot collaboration LED Light Emitting Diode LiDAR Light Detection and Ranging LTS Long Term Support OMPL Open Motion Planning Library PCB Printed Circuit Board PLC Programmable Logic Controller ROS 2 Robot Operating System 2 RX Receive RXD Receive Data SDF Simulation Description Format SFTP Secure File Transfer Protocol SRDF Semantic Robot Description Format SSH Secure Shell SSM Speed and Separation Monitoring TX Transmit TXD Transmit Data UART Universal Asynchronous Receiver/Transmitter URDF Unified Robot Description Format QoS Quality of Service ix Contents List of Acronyms ix List of Figures xv List of Tables xvii List of Algorithms xix 1 Introduction 1 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Limitations / Demarcations . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Related Works 5 3 Theory 9 3.1 Industrial Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Raspberry Pi 4B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 LiDAR Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 KiCad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5 Robot Operating System 2 . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.1 ROS Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.2 Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.3 Nodes and communication . . . . . . . . . . . . . . . . . . . . 12 3.5.4 Launch files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.5 Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.6 Joint Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.7 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6 Simulation and Visualization . . . . . . . . . . . . . . . . . . . . . . . 14 3.7 Motion Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7.1 MoveIt2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7.2 OMPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7.3 Kinematics Configuration . . . . . . . . . . . . . . . . . . . . 15 3.7.4 Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 xi Contents 3.7.5 Abstract Time ROS 2 . . . . . . . . . . . . . . . . . . . . . . 16 3.7.6 Unified Robot Description Format . . . . . . . . . . . . . . . . 16 3.7.7 Semantic Robot Description Format . . . . . . . . . . . . . . . 16 3.8 Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.8.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.8.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 Methods 19 4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1 Sensors - LD06 LiDAR . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2 Microcomputer (MC) - Raspberry Pi 4B . . . . . . . . . . . . 21 4.1.3 Communication Between Sensors and MC - CP2102 UART Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4 LEDs and circuitry . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5 3D-printed Sensor Stands . . . . . . . . . . . . . . . . . . . . 23 4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.1 Reading Data from One Sensor . . . . . . . . . . . . . . . . . 24 4.2.2 Reading Data from Multiple Sensors . . . . . . . . . . . . . . 25 4.2.3 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.4 Testing the Calibration Program . . . . . . . . . . . . . . . . 28 4.2.5 Object Detection in Relation to Sensors . . . . . . . . . . . . 29 4.2.6 Converting Calibrated Sensor Data to the Robot Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.7 Object Detection in Relation to Robot . . . . . . . . . . . . . 33 4.2.8 Testing Object Detection in Relation to Robot . . . . . . . . . 38 4.2.9 Determining the Size of the Safety Zones . . . . . . . . . . . . 38 4.2.10 Creating a ROS 2 Workspace on the Raspberry Pi . . . . . . . 40 4.2.11 Publishing Sensor Data . . . . . . . . . . . . . . . . . . . . . . 40 4.2.12 Publishing Robot Control Messages . . . . . . . . . . . . . . . 41 4.2.13 Visually Displaying Zone Breaches using LEDs . . . . . . . . . 42 4.2.14 Testing the Safety System . . . . . . . . . . . . . . . . . . . . 44 4.3 Simulation and Visualization of the ABB Robot . . . . . . . . . . . . 46 4.3.1 Versions and Compatibility . . . . . . . . . . . . . . . . . . . 46 4.3.2 Simulation and Visualization Project Structure . . . . . . . . 47 4.3.3 Launch Configurations . . . . . . . . . . . . . . . . . . . . . . 47 4.3.4 Transforms and Placement of Objects . . . . . . . . . . . . . . 47 4.3.5 Visualization of Sensor Data . . . . . . . . . . . . . . . . . . . 48 4.3.6 Motion Planning and Adapters . . . . . . . . . . . . . . . . . 48 4.3.7 Kinematics Solver for Simulation . . . . . . . . . . . . . . . . 50 4.3.8 Computing Motion Commands using Controller . . . . . . . . 50 4.3.9 Sending Goal States . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.10 Stopping the Robot . . . . . . . . . . . . . . . . . . . . . . . . 51 4.3.11 Time Implementation . . . . . . . . . . . . . . . . . . . . . . . 51 4.3.12 Sensor Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5 Results 53 5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 xii Contents 5.1.1 3D Printed Sensor Stands . . . . . . . . . . . . . . . . . . . . 53 5.1.2 LED Circuit Functionality . . . . . . . . . . . . . . . . . . . . 55 5.1.3 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 ROS 2 Workspace on the Raspberry Pi . . . . . . . . . . . . . . . . . 55 5.3 Start Up Sequence of the Safety System . . . . . . . . . . . . . . . . 56 5.3.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3.2 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.3 Calibration test . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.4 Starting the Safety System . . . . . . . . . . . . . . . . . . . . 58 5.4 Safety System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.4.1 Testing Object Detection in Relation to Robot . . . . . . . . . 59 5.4.2 Response Time Tests . . . . . . . . . . . . . . . . . . . . . . . 60 5.4.3 Data Filtering Tests . . . . . . . . . . . . . . . . . . . . . . . 60 5.5 Simulation and Visualization . . . . . . . . . . . . . . . . . . . . . . . 61 5.5.1 Launching Environments . . . . . . . . . . . . . . . . . . . . . 61 5.5.2 Planning and Execution in RViz2 . . . . . . . . . . . . . . . . 62 5.5.3 Visualization of Laserscan Data . . . . . . . . . . . . . . . . . 63 5.5.4 Visualizing the Sensor Model . . . . . . . . . . . . . . . . . . 63 5.5.5 Sending Goal States to the Robot . . . . . . . . . . . . . . . . 64 5.5.6 Stopping the Robot Execution During Zone Breach . . . . . . 64 6 Discussion 65 6.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.1.1 2D LiDAR Sensors . . . . . . . . . . . . . . . . . . . . . . . . 65 6.1.2 Sensor Stands and Interference . . . . . . . . . . . . . . . . . 66 6.1.3 LED Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1.4 Housing for components . . . . . . . . . . . . . . . . . . . . . 67 6.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2.1 Object Detection Logic . . . . . . . . . . . . . . . . . . . . . . 68 6.2.2 Modularity of the Safety System . . . . . . . . . . . . . . . . . 68 6.2.3 Sensor Data Confidence and Filtering . . . . . . . . . . . . . . 69 6.2.4 System Performance and Instability . . . . . . . . . . . . . . . 69 6.2.5 System Reaction Time . . . . . . . . . . . . . . . . . . . . . . 70 6.2.6 Resolution of Sensor Data . . . . . . . . . . . . . . . . . . . . 70 6.2.7 Connecting the Raspberry Pi to the Robot Simulation . . . . 71 6.2.8 Connection Monitoring . . . . . . . . . . . . . . . . . . . . . . 71 6.2.9 The Robot Fails to Iterate Over the Same Four Movements . . 71 6.2.10 Different Speeds Depending on Zones . . . . . . . . . . . . . . 71 6.2.11 Visualization of Sensor Models . . . . . . . . . . . . . . . . . . 72 7 Conclusion 73 8 References 75 A Appendix A I xiii Contents xiv List of Figures 2.1 Hardware setup of another safety system . . . . . . . . . . . . . . . . 6 2.2 Visualization of dynamic zones . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Representation of stop zone in another system . . . . . . . . . . . . . 8 3.1 ABB IRB 1200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Raspberry Pi 4B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 LD06 LiDAR sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 CP2102 UART USB bridge. . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 LED Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3 3D model of sensor stand . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4 Sensor Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5 Program Structure 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.6 Robot Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . 27 4.7 Sensor Intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.8 Sensor Angle Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.9 Vector Addition Parameters . . . . . . . . . . . . . . . . . . . . . . . 34 4.10 Adjusted Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.11 Robot Safety Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.12 Program Structure 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.13 Program Structure 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.14 Program Structure 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.15 LED Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.16 Program Structure 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.17 Folder structure for the IRB1200 . . . . . . . . . . . . . . . . . . . . 47 4.19 Implementation of the Laserscan visualization. . . . . . . . . . . . . . 48 4.18 TF Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.20 Folder structure for the action nodes . . . . . . . . . . . . . . . . . . 51 4.21 Folder structure for the sensor model. . . . . . . . . . . . . . . . . . . 52 5.1 Image of system setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2 3D printed stand with a sensor. . . . . . . . . . . . . . . . . . . . . . 54 5.3 LED circuit used for zone indication. . . . . . . . . . . . . . . . . . . 55 5.4 The final hardware setup schematic. . . . . . . . . . . . . . . . . . . . 56 5.5 Terminal of Identification Program . . . . . . . . . . . . . . . . . . . 57 5.6 Terminal of Calibration Program . . . . . . . . . . . . . . . . . . . . 58 xv List of Figures 5.7 Terminal of Safety System . . . . . . . . . . . . . . . . . . . . . . . . 59 5.8 Simulated robot model in Gazebo . . . . . . . . . . . . . . . . . . . 62 5.9 Visualized robot model in Rviz . . . . . . . . . . . . . . . . . . . . . 62 5.10 Motion planner interface in RViz2. . . . . . . . . . . . . . . . . . . . 62 5.11 Robot display before execution in RViz2 . . . . . . . . . . . . . . . . 62 5.12 Visulized robot position in RViz2 after execution. . . . . . . . . . . . 62 5.13 Simulated robot position in Gazebo after execution . . . . . . . . . . 62 5.14 LiDAR sensor data visulized in RViz2 . . . . . . . . . . . . . . . . . . 63 5.15 Sensor model visualized in Rviz2. . . . . . . . . . . . . . . . . . . . . 63 5.16 Action client output in terminal. . . . . . . . . . . . . . . . . . . . . . 64 5.17 Robot Position 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.18 Robot Position 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.19 Robot Position 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.20 Robot Position 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 xvi List of Tables 4.1 Sensor data packet structure. . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Structure of one sensor distance measurement. . . . . . . . . . . . . . 20 5.1 Results of calibration test . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2 Test for object detection within safety zones . . . . . . . . . . . . . . 60 5.3 Summary of response time tests. . . . . . . . . . . . . . . . . . . . . . 60 5.4 Results of false intrusion test . . . . . . . . . . . . . . . . . . . . . . . 61 A.1 Full results of calibration test . . . . . . . . . . . . . . . . . . . . . . I A.2 Full results of response time test . . . . . . . . . . . . . . . . . . . . . II xvii List of Tables xviii List of Algorithms 1 Generalized sensor data parsing loop . . . . . . . . . . . . . . . . . . . 25 2 Calibration loop for LiDAR sensors . . . . . . . . . . . . . . . . . . . . 29 3 Intrusion detection based on LiDAR measurements and calibration . . 31 4 Transform 3,600 sensor measurements to robot’s coordinate system . . 33 5 Intrusion detection in relation to robot . . . . . . . . . . . . . . . . . . 37 xix List of Algorithms xx 1 Introduction The rapid development of automation and robotics has significantly changed the way modern industries operate. By integrating intelligent systems into production environments, manufacturers have achieved considerable improvements in speed, accuracy, and productivity [1]. Automation has become a key factor in meeting global demand, reducing costs, and increasing the overall quality of manufactur- ing processes. As these technologies evolve, industrial systems are shifting from rigid and fixed setups to more flexible and adaptive solutions that allow for faster reconfiguration and closer collaboration between machines and human operators. This increasing integration of automation has also introduced new challenges, par- ticularly in environments where humans and robots work closely. Collaborative sys- tems must ensure that strict safety standards are upheld while supporting dynamic and efficient workflows. Traditionally, safety has been maintained using physical barriers, such as fences or enclosures, that separate people from hazardous areas [2]. Although effective, these static solutions often limit flexibility and require time- consuming changes whenever the production layout is adjusted. To overcome these limitations, many industries are now moving toward sensor-based systems that can make robots react more flexibly and safely [2]. These systems detect when a human or another object comes too close and can slow down or stop the robot to avoid accidents. This makes it possible to work without fixed safety fences, which also saves space and makes the layout easier to change. Instead of relying only on physical barriers, modern safety solutions are more focused on smart, responsive systems that can adjust to the situation in real time. This report presents a project that builds on this concept by exploring how a vir- tual safety system can be developed using cost-effective LiDAR sensors and real-time data processing. The system monitors the area around a robot, detects intrusions, and classifies them into safety zones. Based on this, suitable actions can be trig- gered to improve safety while maintaining operational flexibility. The system is developed and tested in a simulation environment, to evaluate its potential for use in collaborative industrial applications. 1 1. Introduction 1.1 Purpose Creating safer and more flexible environments for industrial-robot interaction re- quires new approaches that go beyond traditional physical barriers. This work presents a system that replaces static fencing with a virtual alternative, using Li- DAR sensors to monitor the robot’s surroundings and detect nearby movement. The system defines distance-based safety zones and reacts when an object or person enters them, for example by triggering a slow-down or stop command for the robot. Through this approach, safety becomes part of the robot’s environment, managed by sensor logic instead of fixed structures, allowing for a more open, efficient, and adaptable workspace. To evaluate the performance of the system, it is developed and tested in a simulation environment that replicates realistic robot behavior and sensor feedback. 1.2 Goals The project’s main goal was to develop a virtual safety fence that can monitor the area around a non-collaborative robot and detect when a person or object comes too close. The system should be able to define different levels of safety and respond by sending signals that simulate how the robot would behave, such as slowing down or stopping. Another important part of the work was to test the system in a simulation envi- ronment to observe how it performs in different situations. The system was also designed to be modular and relatively inexpensive, so it can be reused or adapted to different robot layouts with minimal changes. 1.3 Limitations / Demarcations To achieve the project goals, a few limitations were established to keep the work focused and the development process structured. The system was created for one specific robot setup, and all sensor placement and zone logic were adapted to that layout. Although the idea could be applied to other environments, this version was only tested in that setup. The system was designed to detect objects near ground level, with sensors placed at a fixed height approximately 20 to 30 cm above the floor. This configuration limits the system’s ability to detect objects approaching from above. All testing was performed in a simulated environment. This allowed for controlled evaluations during development, but no physical testing was performed due to safety considerations, so real-world behavior is not confirmed in this version. The robot used in the study is placed in a room with a smaller area than anticipated for a robot of this size. As a result it was not possible to conduct tests using the 2 1. Introduction calculated stop-zone radius. Instead, tests were done with a stop-zone radius limited to a maximum of 80 % of the calculated value. 1.4 Background This project is based on the development of a virtual safety system for the ABB IRB 1200, a compact six-axis industrial robot commonly used in tasks such as machine maintenance, assembly, and material handling [3]. Its small footprint and flexible mounting options make it suitable for production environments where space is limited and safety is a priority. In this study, the robot is already mounted on a platform developed as part of a bachelor’s thesis completed in 2024 [4]. Since the IRB 1200 is not equipped with built-in safety functions such as presence detection or automatic stopping when a person enters its working area, external safety systems such as physical fences are required to ensure safe operation around humans. All sensor placements and safety logic in this work were adapted to the geometry and working range of this specific robot model. A Raspberry Pi 4B was used as the central microcontroller in the system, avail- ability of multiple USB interfaces, and support for general-purpose input/output (GPIO) communication [5]. It handled the coordination between sensor input, data processing, and system output, and served as the platform for executing custom control software developed during the project. To provide visual feedback when ob- jects entered the defined safety zones, a circuit with Light Emitting Diodes (LEDs) was implemented and connected to the GPIO ports of the Raspberry Pi 4B. This setup enabled real-time indication of detections from various directions around the robot during operation and testing. To support development and testing, the system was built entirely in a simulation environment. Robot Operating System 2 (ROS 2) was used as the main software framework to manage communication between system components. Gazebo, a 3D simulation tool, was used to model the robot and its environment, while RViz2, a visualization tool in the ROS 2 ecosystem, was used to display sensor data, defined zones, and system behavior. These tools are referred to throughout the report and made it possible to evaluate the system during development, even without access to physical hardware. These tools are described in more detail in the theory section. To ensure that the safety system followed established industry practices, several ISO standards were used as guidance. Although full compliance was beyond the project scope, these standards helped define key requirements for the system architecture and behavior. ISO 12100:2010 provides a general framework for risk assessment and reduction when designing machinery [6]. It emphasizes that the most effective way to reduce risk is to integrate safety directly into the design, which supports the idea of creating a virtual safety fence. According to the standard, human risk is highest when near the machine, for example, during programming, cleaning, or maintenance scenarios, 3 1. Introduction which the system is designed to detect and respond to. ISO 61508 focuses on functional safety in electronic and software-based systems [7]. It introduces principles such as hardware redundancy and continuous monitoring to prevent faults and failures. These ideas influenced the system structure, especially the use of multiple sensors and real-time processing to increase reliability. For safety specifically related to industrial robots, ISO 10218-1:2011 outlines how robots must behave when people enter their work area [8]. One of these behaviors is defined as Speed and Separation Monitoring (SSM) in which the robot shall keep a predefined minimum distance to the operator att all times. If the operator gets to close to the robot then the robot should slow down or stop completely. It also states that a single failure must not be enough to disable the safety function, and that a protective stop must fully halt the robot and safely manage its power. The project will use these standards to develop a robust safety system that integrates redundancy and reliable stop functions, ensuring compliance with industry best practices while improving operational safety around the robots. These standards are further explained in Section 4.2.9 of the Method section, where their role in sensor placement and distance calculation is described. 4 2 Related Works The goal of this project is to build a virtual fence around an industrial robot, which has been done before in other research projects. The goal is also for the system to be relatively inexpensive, modular and usable for non-collaborative robots. Other systems often lack one or more of these properties. Below, some general solutions to similar problems will be described and four selected studies will be explained in a more detailed manner. Most of these studies have been done using collaborative robots [9]–[11], which are robots that are designed to work together with humans to some extent [12]. Therefore, these robots often have built in systems to avoid collisions with humans, they are designed for lighter loads and less force, and a safety barrier is not always required. The ABB robot does not react to external forces, e.g. if it were to hit a person, and therefore it must have some type of added safety mechanism to not cause injury to humans. Some studies have used some type of camera systems [11], [13], [14] to identify moving people and objects around industrial robots. In some cases this allows for three dimensional visualization of the room. Studies often used laser scanners in combination with other safety measures (such as a 3D scanner) to detect approaching people [9], [15]. In one study, a system for a human-robot collaboration environment is described [9]. The system is developed for the KUKA LBR iiwa which is a collaborative robot, meaning that the robot will automatically reduce speed and power when it comes into contact with something in its environment [16]. This functionality distinguishes the LBR iiwa from the ABB IRB 1200 used in this project, as the latter does not include built in contact detection and thus pose a greater safety risk. Despite the differences, certain methods from the KUKA system are relevant. Notably, the use of two laser scanners positioned around the robot to monitor a 360 degree plane proved effective for detecting the presence of nearby individuals, particularly by identifying legs of people approaching the robot. While the KUKA LBR iiwa is a collaborative robot designed to operate safely along- side humans, the ABB IRB 1200 is an articulated industrial robot not intended for direct human interaction. However, the use of laser scanners for monitoring the sur- rounding environment remains applicable to both systems. Also, within the KUKA system the laser scanners were only one of multiple safety mechanisms, the full 5 2. Related Works setup can be seen in Figure 2.1. When laser scanners are used as the sole input for safety monitoring, as in the system developed for the IRB 1200 within this project, a greater number of sensors is required to ensure reliable environmental awareness. Figure 2.1: Hardware setup of the full safety system around the KUKA LBR iiwa. [9]. Used with permission from Elsevier. One study compared the times for a set task to be completed in different condi- tions [17]. They tested the task with a fence around the robot, which is most common today. They tested with two different zones that are monitored by a laser scanner. When someone enter the first zone the robot slows down, and then stops in the next zone. They also tested the task with two different types of SSM where the current position of the robot is taken into account. The study found that the time it took for the robot to complete the task, with some interruptions by some- one approaching the robot, decreased both when zones and SSM were used. This indicates that using safety measures other than a physical fence around the robot makes the robot’s work more time-efficient. However, monitoring the position of the robot is a more complicated approach to this problem which could be difficult to implement as a modular and inexpensive system. The sensor used in this project costs around 80,000 SEK which is not feasible cost in this project [18]. Although the same methods cannot be used in this project, it shows that the zone-based approach remains time-efficient. 6 2. Related Works The same or similar problems have also been solved with other methods. One study used an overhead safety camera system which identifies moving objects in different zones [13]. These zones are dynamic, meaning that they follow the robot arm and therefore differ over time depending on where the robot arm is working in each moment. A visualization of these dynamic zones can be seen in Figure 2.2. The robot then receives signals to either slow down or stop completely. The dynamic zones are useful to minimize the time that the robot is still. The study found that this approach allowed for more human-robot collaboration which in turn reduced the time significantly for the tested task, a rear axle assembly. The system increases the time effectiveness but some of the components used are more expensive than reasonable in this project and therefore this is not a good approach to the problem for this project. Figure 2.2: Visualization of dynamic zones corresponding to three different posi- tions. [13], CC BY 4.0. Another study also solves a similar problem [19]. They used multiple sensors mounted around a robot arm to detect if something gets close to the arm, with the goal to be able to detect humans without contact. The stop zone is relative to the robot arm as seen in Figure 2.3 and in some cases the robot did not stop moving until an object was within 200 mm of the robot arm. This system is placed on an UR10 robot, which is a collaborative robot in contrast to the ABB IRB 1200 [10]. This entails that there is always an internal fallback safety measure if the external safety system fails. With the ABB-robot the safety is entirely dependent on the ex- ternal safety measures. The ABB robot is also able to move faster than the UR10, at some axes the difference is more than 400° per second [10], [20]. These differences may indicate that humans are able to work closer to the UR10 robot than the ABB robot. Therefore, the safety zone should be bigger around the ABB robot than the 200 mm used in this study. 7 2. Related Works Figure 2.3: Representation of the stop zone around the UR10 robot arm. [19]. Used with permission from Elsevier. 8 3 Theory This section introduces the reader to the necessary concepts and theory for this study. The chapter is divided into ten parts which offers greater insight into key concepts and components used in the project. 3.1 Industrial Robot Figure 3.1: The ABB IRB 1200 robot. The ABB IRB 1200 is a compact and versatile six-axis industrial robot that is commonly used in assembly, machine maintenance, and material handling applica- tions [3]. Its compact footprint and high precision makes it suitable for environments where space is limited and fast, repeatable motion is required. The robot offers a reach of up to 900 mm and a payload capacity of up to 7 kg, depending on the 9 3. Theory configuration. It supports multiple mounting options and can be integrated into horizontal and vertical production layouts. The robot is displayed in Figure 3.1. The IRB 1200 is typically controlled via ABB’s IRC5 or OmniCore controller, which enables advanced motion programming and supports external safety and communi- cation interfaces [3]. This allows the robot to be connected to external devices such as sensors, emergency stop circuits, and programmable logic controllers (PLCs). Safety functions can be triggered through digital inputs, and communication can be handled through industrial protocols such as Ethernet/IP or PROFINET, depend- ing on the setup. These integration options make it possible to build systems where the robot reacts to sensor input in real time. 3.2 Raspberry Pi 4B The Raspberry Pi 4B is a small microcomputer designed for embedded applications, optimized for size, power consumption, and flexibility [5] . The MC can be seen in Figure 3.2. It includes a 64-bit quad-core processor, up to 8 GB of RAM, USB 3.0 ports, Bluetooth 5.0, dual-band Wi-Fi, and gigabit Ethernet. It also features Gen- eral Purpose Input/Output (GPIO) pins for controlling external components such as LEDs or sensors. Compared to earlier models, the 4B offers higher performance while maintaining the same low power requirements and compatibility with existing Raspberry Pi software. Figure 3.2: The Raspberry Pi 4B. A Raspberry Pi can be used to handle data from sensors, apply logic for zone detection, and send signals to LEDs based on security threat level. Its combination of computing power, connectivity, and real-time GPIO control made it suitable for running the safety system without additional hardware. 10 3. Theory 3.3 LiDAR Sensors A 2D LiDAR sensor functions by sending out short laser pulses and measuring the time taken before they bounce back from nearby objects [21]. The sensor switches the laser on and off very quickly, and the reflected pulses are picked up by an optical receiver. Since the speed of light is known, the distance can be calculated based on the time between when the pulse was sent and when it was received. The sensor rotates and scans a flat surface around itself, which gives a 360-degree view close to the ground. One sensor is displayed in Figure 3.3 Figure 3.3: The LD06 LiDAR Sensor. The LiDAR sensors used in this project are the LD06 LiDAR. These sensor sends out data packets continuously while it scans [22]. Each data packet includes 12 angles and 12 distance, which tells how far away an object is and in which direction. This data can be read through a serial connection and is updated multiple times per second. The system will use this information to decide which safety zone the object is in. The sensors are the foundation of making it possible to create a virtual safety fence where the robot can react if something gets too close. 3.4 KiCad KiCad is an open-source software suite for electronic design automation (EDA), used to design and document electronic circuits. In this project, KiCad was used to develop the schematic and printed circuit board (PCB) layout for the LED circuit that provided visual feedback in the safety system. The software enabled precise placement of components, such as resistors and transistors, and ensured correct routing of signals between the Raspberry Pi and the LEDs. By using KiCad, it was possible to generate manufacturing files including Gerber files and a bill of 11 3. Theory materials, which were necessary for producing a functional and reliable PCB version of the LED driver circuit. 3.5 Robot Operating System 2 Robot operating system 2 (ROS 2) is an open source framework that helps users quickly build components for actuators, sensors and control system [23]. The com- ponents are then easily connected using built-in ROS 2 tools that enables quick testing, training and quality assurance. These built in communication tools makes sending messages to a variety of visualization tool easy, offering quick and intuitive visualization of data. ROS 2 also support working with simulated robots instead of real robots making testing easier and faster. This in combination with that ROS 2 supports hardware interfaces for a broad variety of robots components have made ROS 2 an globally used tool for robot development. 3.5.1 ROS Distribution The latest distribution for ROS is Jazzy jalisco and was released May 23, 2024 and is a group of ROS packages configured to work reliably together [24]. Once a distribution is released, changes and updates are limited in order to maintain a stable code base until the next distribution. 3.5.2 Workspaces A workspace is a directory containing ROS 2 packages, and a project consists of workspaces on different levels (called underlays and overlays) [25]. This structure makes it possible to create new packages in the overlay without interfering with the existing packages in the underlay. 3.5.3 Nodes and communication ROS 2 functions primarily using nodes, where each node works independently on a specific task [26]. Nodes can communicate with each other using topics, services, actions, or parameters which together creates a ROS 2 network. The topics act as buses for sending and receiving messages, to which different nodes can either subscribe to (read data) or publish to (send data). It should be noted that commu- nication to and from a topic can be any combination from one-to-one communication to many-to-many communication, furthermore displaying the power of sending and receiving messages from topics. Unlike topics, the services do not work with open data streams, but rather on a call-and-response basis [26]. A service client located in a node sends a request to which the service server (also located in a node) returns a response. This server can be configured to run in a single or multi-threaded environment, allowing for parallel request handling if necessary. Typical usages of services include triggering actions or fetching current statuses. 12 3. Theory Actions build on topics and services for node to node communication [26]. They are typically intended for long-running tasks, and consist of goal, feedback, and result stages. The action client node sends the goal request to the action server and the action server sends a goal response and starts executing the goal. During the time the action server works on the request from the action client it publishes feedback on a topic that action client subscribes to. When the action server completes the goal, the action client sends a result request to the action server. The action server then sends a response and the process is complete. 3.5.4 Launch files A launch file in ROS 2 is a Python script that automates the launching process of nodes and their parameters, configurations and other runtime settings [27]. 3.5.5 Transforms In ROS 2, tf2 (also called transforms) is a library responsible for keeping track of co- ordinate frames [28]. The coordinate frames are then used for tracking the positions and orientation of modules within a virtual environment. All coordinate frames are defined with relation to a parent coordinate frame, with the world coordinate frame being the center referees to all other frames. This creates a tree structure that ensures that all frames are consistently related and positioned in visualization or simulation. 3.5.6 Joint Limits The Joint Limits configuration file specifies physical constraints for each joint of the robot, such as maximum velocity, maximum acceleration, and range of motion [29]. For the ABB IRB 1200, this includes all six rotational joints of the articulated arm. These limits are essential for ensuring that planned motion stays within the robot’s mechanical capabilities. 3.5.7 Controllers A controller is a software component that implements control theory to automat- ically adjust a system’s input to achieve a desired output [30]. Open-loop control operates on fixed input and therefore does not require sensors or feedback mecha- nisms, but is also less accurate when dealing with disturbances [31]. Closed-loop control implements feedback to adjust control signals based on the error, which is the difference between actual and desired output. PD (Proportional-Derivative) and PID (Proportional-Integral-Derivative) controllers are common in closed-loop systems and are responsible for driving the error towards zero [32]. PD improves response and reduces overshoot by adjusting the control signal based on the current error and its rate of change. PID adds an integral term to eliminate steady-state error (difference between the desired output and the actual output of a control sys- tem once it has stabilized over time) making it more robust for systems needing long-term accuracy. For example, PD control can be used for altitude stabilization 13 3. Theory (pitch, roll, yaw) in drones as it provides fast and smooth responses without too much overshoot. PID control could be used for balancing systems (e.g. Segways or inverted pendulum) due to its fast response and minimal steady-state error. PID controllers are typically the most widely used type of controllers in industry. In ROS 2, controllers are designed to separate control logic from the hardware, making the system more modular [33]. Our system uses a ”JointTrajectoryCon- troller” from the ros2_controllers package, which is meant to execute a trajectory for one or more joints. This controller is defined in irb1200_controllers.yaml from the irb1200_ros2_gazebo package and is named ”irb1200_controller”. It receives a tra- jectory generated by MoveIt2 through the "FollowJointTrajectory" action interface as a control_msgs/action/FollowJointTrajectory message (a list of joint position- s/velocities/accelerations/timestamps). Each joint state in this trajectory is used as the next reference point (input), and the difference between the current state (feedback from /joint_state_broadcaster that continuously publishes the current joint state) and the current reference point is the error. The controller aims to minimize this error, or in other words, it aims to bring the current state as close as possible to the desired state. If the ”AddTimeParametrization” response adapter is used in the motion planning pipeline, then time-based vectors such as velocity and acceleration will be included in the states. In this case, the controller will generally run a closed loop with PD or PID control to achieve the desired profile. Without the response adapter, only position data is considered and the controller can simply run an open-loop with feedforward control, where input is anticipated. The controller manager node is responsible for the connection between the controllers and the hardware-abstractions in the ros2_control framework [33]. It manages the controller’s interface requirements and has access to the hardware components pro- vided interfaces. The control manager uses this to connect the controllers needs with the hardware capabilities. It also reports errors if multiple controllers want access to the same hardware, avoiding access conflicts. It is executed in a control loop managed by the an update method that reads data from hardware components and outputs it to all active controllers. 3.6 Simulation and Visualization RViz2 is a 3D visualization tool for the ROS 2 framework which, among other things, allows users to visualize sensor data and robot models. While RViz2 focuses on visualization, Gazebo Harmonic complements it by offering a dynamic simulation environment [34] [35]. Gazebo incorporates physics, lighting, and sensor feedback. This allows developers to validate robot behavior without physical hardware. It also integrates easily with the ROS 2 framework, providing synchronized testing between simulated environments (robot) and real-time systems (sensor data). 14 3. Theory 3.7 Motion Planning Motion planners are a fundamental component in robotics to enable robotic move- ment from start positions to goal positions while taking consideration to physical restraint and kinematics. This section introduces the tools and frameworks used for motion planning and their integration with MoveIt2. 3.7.1 MoveIt2 Moveit2 is a framework that is well supported for ROS 2 [36]. It provides motion planning, manipulation, 3D perception and kinematics for both simulated and real world systems. The interface is through a ROS 2 action or service that can be configured through the move_group node. To plan a trajectory, MoveIt2 uses one of the defined motion planning libraries such as Open Motion Planning Library (3.7.2), passing the current and goal joint states as well as any constraints such as joint limits or obstacles as input. OMPL will then generate random samples in joint space and connect them using a motion planning algorithm, such as RRTConnect (Rapidly- exploring Random Tree Connect) [37]. MoveIt2 uses a ”planning scene” to check whether a state is valid. The planning scene is a snapshot of the current state of the simulated environment and is updated through the planning_scene_monitor node. This node subscribes to /joint_states for the robot state, /tf for transforms and /planning_scene or /collision_object for world updates. The planner will stop when a valid path is found or if it runs out of time. The output, a discrete sequence of joint states (of the ROS 2 format trajectory_msgs/msg/JointTrajectory), can be sent to a controller to move the robot. It is also important to note that motion plans used by MoveIt2 are typically pre- and/or post-processed using modular plugins called adapters. 3.7.2 OMPL An OMPL planner is a set of motion planning algorithms provided by the MoveIt2 integrated Open Motion Planning Library [38]. The OMPL Planner itself is not a single motion planning algorithm, but rather a plugin containing a collection of many different motion planning algorithms. In this project, the IRB 1200 library provides a selection of configurations for some of these algorithms. 3.7.3 Kinematics Configuration To enable the robot to move with MoveIt2, a kinematics file is used [39]. These files configures how MoveIt2 calculates the robots joints movements to reaching the desired positions or orientation. • kinematics_solver: Defines which plugin MoveIt2 should use to calculate joint angles. • kinematics_solver_search_resolution: Sets how precisely the solver searches 15 3. Theory for solutions. Lower values result in more accurate results but increase com- putation time. • kinematics_solver_timeout: Specifies the maximum time the solver is allowed to spend finding a valid solution. 3.7.4 Adapters There are two types of adapters- request adapters which apply pre-processing techniques- and response adapters that apply post-processing techniques to a motion plan [40]. Request adapters can modify or validate a plan before it reaches the planner. Some common examples include ”FixWorkSpaceBounds”, which ensures that the goal pose is within the workspace bounds defined by the planner configuration (this prevents invalid goals that are physically unreachable), and ”FixStartStateBounds” for correcting small violations on the robot’s joint limits in its start state. For the response adapters, ”AddTimeParametrization” is typically used for enabling velocity and acceleration to the trajectory, allowing it to be interpreted by controllers and real-world robots. 3.7.5 Abstract Time ROS 2 Running logged data against a simulated robot requires the use of abstract time to ensure accurate synchronization between components, as the simulation itself becomes a limiting factor in timing [41]. To address this a Gazebo clock bridge can be implemented. The clock bridge publishes the system time allowing the entire system to operate based on the simulation time. 3.7.6 Unified Robot Description Format URDF or Unified Robot Description Format is a commonly used XML file format in ROS 2 for both the description of the robot model and the collision boundaries [42]. A URDF file consists of joints and links, where joints represent physical parts of the robot and links connect two joints. Some common types of joints are revolute (rotates around an axis), prismatic (slides along an axis), fixed (no motion) or con- tinuous (rotates without limit). The file can also contain so called ”transmissions”, used in combination with controllers, that map actuator effort to joint movements for simulation/control. Colors and textures can also be defined as ”materials”. 3.7.7 Semantic Robot Description Format SRDF or Semantic Robot Description Format is also an XML file format that com- plements URDF by specifying joint groups, additional collision information, default robot configurations, and additional transforms needed for defining a robot’s posi- tion [42]. The URDF file only defines the physical joints on the robot, whereas the SRDF adds virtual joints to the visualization and simulation world’s coordinate sys- tem. The SRDF also contains the joint groups used by MoveIt2’s motion planning, such as the ”arm” group or ”gripper” group. 16 3. Theory 3.8 Programming Languages Programming languages are used to instruct computers to perform specific tasks [43]. They serve as the primary medium through which humans communicate with machines, translating algorithms and tasks into executable actions. At their core, programming languages are governed by syntax, structure, and semantics, mean- ing, enabling precise manipulation of data and execution of logic. These languages vary in abstraction, from low-level machine-oriented languages to high-level, human- readable ones like Python or Java. In the context of safety-critical systems, such as industrial automation or robotics, the choice of programming language influences not only the system’s functionality and efficiency but also its reliability, maintainability, and safety compliance. 3.8.1 Python Python is a high-level programming language with a simple and easy-to-learn syn- tax, making it well suited for rapid prototyping [44]. Its straightforward structure also helps reduce the difficulty and cost of maintaining programs. Unlike compiled languages, Python is interpreted and runs code line by line. When the interpreter encounters an error, it raises an exception. If the program does not handle the exception, the interpreter prints a stack trace and then exits the program. Python is commonly used to build websites, handle data, and develop software ef- ficiently [45]. It integrates well with databases, supports complex mathematical operations, and simplifies the automation of repetitive tasks. Thanks to its ease of testing and modification, developers can quickly experiment with ideas and itera- tively improve their programs. This adaptability is a major reason why Python is applied in a wide range of fields. 3.8.2 C++ C++ is a powerful, general-purpose programming language that was developed as an extension of the C programming language [46]. It combines the performance and efficiency of low-level programming with the flexibility and structure of high-level, object-oriented programming. C++ builds on the foundations of C but introduces features such as classes, objects, inheritance, and polymorphism - key concepts within object oriented programming [47]. These features allow developers to create complex programs that are modular, maintainable, and easier to extend. At the same time, C++ retains close control over hardware through manual memory management, which are critical for applications that demand high efficiency and precise resource handling. One of the key advantages of C++ is its execution speed [46]. Unlike interpreted languages, C++ code is compiled directly into machine code, allowing it to run extremely fast and with minimal overhead. This makes it especially suitable for developing real-time applications, operating systems, robotics and safety systems 17 3. Theory where performance is non-negotiable. 18 4 Methods This chapter presents the methodology used to develop the safety monitoring system. The project was divided into four key areas: Hardware, Software, Visualization, and Simulation. Hardware covers the physical setup, including LiDAR sensors and the Raspberry Pi. Software describes how data was collected and processed in real time. Visualization involves tools for displaying sensor data, and Simulation was used to test the system in virtual scenarios. Each section outlines the key steps and decisions made during development. 4.1 Hardware This section outlines the hardware components used to implement the safety moni- toring system. The core of the setup consisted of four LiDAR sensors. These sensors were mounted at custom made stands and placed around the industrial robot to ensure full 360-degree coverage of the surrounding area. Each LiDAR unit was con- nected to a central processing unit via an USB-bridge to a Raspberry Pi 4B, which served as the main processing unit for the system. The Raspberry Pi was chosen due to its multiple USB ports, GPIO capabilities, and support for Python and native ROS 2. Additional hardware included LED indicators for visual feedback, a physical emergency stop switch, and custom mounts to securely position each sensor at the correct angle. The design emphasized both robustness and modularity to facilitate easy testing, repositioning, and maintenance during the development process. 4.1.1 Sensors - LD06 LiDAR A core requirement of the project was the reliable detection of a person in close proximity to the industrial robot, making sensor quality, consistency, and redun- dancy critical for ensuring system safety. To achieve complete 360-degree coverage around the robot, it was necessary to deploy multiple strategically positioned Li- DAR sensors to eliminate blind spots and provide continuous monitoring from all directions. The sensors chosen for the project were four of the LD06 LiDAR sensor primarily due to its high reliability of 12 meters measuring distance and 360.00 degrees of coverage [22]. The LD06 uses Direct Time-of-Flight (DTOF) technology, enabling 19 4. Methods it to perform up to 4,500 distance measurements per second, ensuring accurate and real-time spatial awareness necessary for defining responsive virtual boundaries around industrial robots. It emits infrared laser pulses that travel toward nearby objects, reflect off their surfaces, and are then received back by the sensor. The sensor then calculates the distance to obstacles based on the time delay between emission and reception. The LD06 is powered using a 5 V DC supply. For data communication, the sensor transmits measurement to a Raspberry Pi via UART, a serial communication interface, at a 230,400 baud rate [22]. Each measure- ment package starts with a 0x54 header byte, followed by metadata, such as package length, start angle, and stop angle, which then is followed by 12 measurement points, each encoded in three bytes: two bytes for distance: LSB - Least Significant Byte, and MSB - Most Significant Byte [48]. One byte for confidence was also included. A representation of the packet structure can be found in Table 4.1 and the structure for one measurement point can be found in Table 4.2. Table 4.1: Sensor data packet structure. Field Content Start character 54H Data length 2CH Radar speed LSB, MSB Start angle LSB, MSB Data (12 measurement points) Table 4.2 End angle LSB, MSB Timestamp LSB, MSB CRC Check 1 Byte Table 4.2: Structure of one sensor distance measurement. Component Description Distance (LSB) Lower byte of distance value Distance (MSB) Upper byte of distance value Confidence 1 Byte (0–255) confidence value To interpret the distance, the two bytes are combined: LSB and MSB must be shifted and added accordingly to reconstruct the full 16-bit distance value in millimeters. This bit-wise handling is critical for accurate distance computation and often needs to be done manually when parsing the raw serial data. Additionally, each data frame includes a CRC-8 checksum to ensure communication integrity [22]. The angular resolution is achieved by linearly interpolating between the start and end angles provided in each frame, enabling precise 360.00 degree environmental mapping. 20 4. Methods Each distance measurement from the sensor is accompanied by a confidence value that indicates the reliability or quality of the reading [22]. This value reflects the intensity of the reflected infrared signal - how strong the sensor’s return signal is after the laser pulse bounces off an object. A higher confidence value means that the reflection is strong and the measured distance is likely accurate, while a lower confidence suggests a weak signal, which could be due to factors like long distance, dark or absorbent surfaces, or oblique angles. For example, white objects within 6 meters typically yield a confidence value of around 200, which is considered strong. These confidence data would be used to filter out unreliable readings and improve the robustness of obstacle detection in the virtual safety fence system. 4.1.2 Microcomputer (MC) - Raspberry Pi 4B The Raspberry Pi 4B served as the central processing unit in the project, offering a compact and powerful platform capable of running a full operating system and handling external connections, such as buttons, sensors and LEDs [5]. In this project, the Raspberry Pi was configured to run Ubuntu 24.04 LTS, a lightweight Linux distribution that supports native ROS 2 [49]. The system was operated remotely via SSH (Secure Shell) using PuTTY, a Windows- based terminal emulator [50]. This allowed for full command-line access to the Raspberry Pi from a separate development computer, enabling headless operation (i.e., without a monitor or keyboard connected to the Pi). File management and code deployment were handled using FileZilla, a FTP-client (File Transfer Protocol), also running via SSH, providing a graphical interface to navigate the Raspberry Pi’s file system, upload and download files, and manage project directories [51]. This setup allowed for a smooth development workflow and efficient remote debugging and updating of the system throughout the project. 4.1.3 Communication Between Sensors and MC - CP2102 UART Bridge To power and communicate with the four LD06 sensors, each sensor was connected to a CP2102 USB to UART bridge module. This bridge provides a simple and reliable way to establish serial communication with the Raspberry Pi while also providing the necessary power to the sensors. Each CP2102 module includes a 5 V output pin and a GND pin, which were used to power the sensors directly. For data transmission, the RX (receive) pin on the CP2102 was connected to the sensor’s TX (transmit) pin, allowing the Raspberry Pi to receive measurement data from each LiDAR unit. 21 4. Methods Figure 4.1: CP2102 UART USB bridge. 4.1.4 LEDs and circuitry In the system, Light Emitting Diodes (LEDs) were implemented as visual warning indicators to signal when an object entered one of the defined safety zones. Each LiDAR sensor was connected to an individual LED, allowing the system to show detection events from different directions around the robot during operation and testing. The LEDs were controlled by the Raspberry Pi’s GPIO pins connected to a transistor-based circuit. In each LED circuit, two NPN transistors (a Negative- Positive-Negative layer structure) were used. The first transistor amplified the signal from the Raspberry Pi to provide enough control current, while the second transistor handled the switching of the LED. The LEDs were powered using the 3.3 V supply from the Raspberry Pi’s power pin, while the GPIO pins acted only as control inputs to the transistors. This setup reduced the electrical load on the GPIO pins and ensured stable and safe operation. Current-limiting resistors were also a part of the circuit to prevent overcurrent and protect the components and the Raspberry Pi. The circuit was first tested on a breadboard to verify correct functionality. After successful testing, the circuit was transferred to a PCB designed in KiCad. The schematic and layout were created based on the breadboard version, and the final design was exported as Gerber files for manufacturing. The schematic of the LED circuit can be seen in Figure 4.2 22 4. Methods Figure 4.2: Schematic of the LED circuit used for visual zone indication. 4.1.5 3D-printed Sensor Stands Due to the modular nature of the safety system, the sensors were intentionally not permanently mounted to the base of the robot. Instead, they were placed on custom-designed 3D printed stands, allowing flexible placement around the robot for optimal coverage. The stands were designed to elevate the sensors off the ground and had a can-like structure with outward-extending legs for stability. The hollow interior of each stand was filled with added weight to make them resistant to tipping if accidentally bumped. To further enhance visibility and reduce the risk of some- one unintentionally knocking them over, the stands were printed in bright yellow, ensuring they would be easily noticeable in a typical industrial setting. Because the sensors each scan a single plane, placing them at the same height could result in them detecting each other’s laser pulses, which would interfere with accurate distance measurements. To avoid this, the sensor stands were designed with height differences of 1 cm, ensuring that each sensor scans a separate, non-overlapping plane. A 3D model of the sensor stand can be seen in Figure 4.3. 23 4. Methods Figure 4.3: 3D model of one of the sensor stands. All sensor stands differ slightly in height. 4.2 Software This section will describe the processes and methods of developing the software for the project. The software developed was a safety system based on interpreting data from LiDAR sensors in real time. Development was carried out using Python, chosen for the ability to rapidly develop systems, and support for many necessary features of the safety system. The software was implemented in stages, starting with communication with a single sensor, then scaling up to handle multiple sensors simultaneously, and then iteratively adding more features. 4.2.1 Reading Data from One Sensor To collect and interpret distance data from the LD06 LiDAR sensors, a Python program was developed. The goal was to establish communication with the sensors via USB and extract useful measurement data, angles and distances, that could be used to monitor the area around the robot. The script was designed to handle the sensor’s communication protocol, which in- volves continuously receiving small data packets containing angle and distance val- ues. To ensure that the data were read correctly, a step-by-step process was used in which the program first searched for the specific header byte 54H, and then saw if the correct header was followed by the correct data length 2C, both values specified in the sensor data [48]. If this was satisfied, then the program would continuously read the sensor data. A pseudo algorithm can be seen in Algorithm 1. A representation of how a sensor sees its environment can be seen in Figure 4.4. Once the program was working reliably, it was used as a core part of further development of the system to continuously gather measurement data from the LiDAR sensors. 24 4. Methods Data: Continuous byte stream from sensor Result: Parsed sensor data packets 1 Initialize: 2 Set state to READ_FIRST_BY TE 3 while system is active do 4 if data stream is misaligned for extended time then 5 Raise warning 6 end 7 if state is READ_FIRST_BY TE then 8 Wait for start of packet byte 9 When correct header received, set state to READ_SECOND_BY TE 10 else if state is READ_SECOND_BY TE then 11 Confirm second header byte 12 Set state to READ_REST_OF_PACKET 13 else if state is READ_REST_OF_PACKET then 14 Read remaining bytes and validate complete packet 15 Set state to STREAMING 16 else if state is STREAMING then 17 Continuously read and process full packets 18 else 19 Corrupt reading 20 Set state to READ_FIRST_BY TE 21 end 22 end Algorithm 1: Generalized sensor data parsing loop 4.2.2 Reading Data from Multiple Sensors The project is as stated about creating a safety system around one industrial robot, and one sensor alone could not cover the entire surrounding area. To effectively monitor the entire environment and create a 360-degree safety perimeter, a total of four LD06 sensors was used, positioned around the robot. To handle this setup in software, the original data reading program - initially designed to work with a single sensor - was restructured into a function, making it easier to reuse and scale. To allow the system to read data from all four sensors at the same time, the Python multiprocessing library was implemented. Multiprocessing in Python allows multiple functions to run in parallel within a single program [52]. Each process can run independently, which is particularly useful when performing I/O-bound operations like reading serial data from sensors. The four sensors were connected to the Raspberry Pi using the CP2102 UART USB bridge, and each sensor’s respective port was referenced in the software. For each sensor, a process was created, allowing the data reading function, Algorithm 1, to run for each sensor. This approach allowed the program to simultaneously collect 25 4. Methods Figure 4.4: Representation of the sensor measuring its environment. data from all sensors. An overview of the program architecture can be seen in Figure 4.5 As a result, the system could process inputs from all directions around the robot in real-time. Figure 4.5: Representation of the program architecture and the parallel multi processes for handling incoming data from the different sensors. 26 4. Methods 4.2.3 Calibration The sensors in this system were designed to be modular and easily repositioned, rather than fixed in predetermined locations. As a result, it was crucial to develop a calibration program. This program needed to determine the position of each sensor in relation to the robot and map the static environment, such as walls and obstacles, around the robot. The safety detection mechanism would be based on monitoring boundary crossings relative to the robot, not the sensors themselves. Therefore, it was necessary to know the precise x- and y-coordinates of each sensor in relation to the robot’s position, so that a distance conversion for measurements made by the sensors could be translated into robot perspective later on. The robot was defined as the origin point (0,0) in a cartesian coordinate system. Each sensor’s x- and y-coordinates were treated as positional offsets relative to this origin. The global coordinate system with the robot as the origin is visualized in Figure 4.6. Figure 4.6: Representation of the robot coordinate system and different sensors x- and y- values in relation to robot. With the sensors capable of making 4,500 measurements per second and scanning with a 0.01 degree angular resolution over a 360 degree range, it was important to strike a balance between spatial accuracy and computational efficiency. It was determined that a 0.1 degree resolution was sufficient for environmental mapping. At the sensor’s maximum range of 12 meters, a 0.1 degree step corresponds to a spatial resolution of approximately 21 mm, which is well within the sensor’s stated distance accuracy of ± 45 mm. This validated the decision to use 0.1 degree steps for calibration. To set up the system, each sensor had to be manually placed and its distance to the robot measured along both the x- and y-axes. It was then constructed so at the start of the calibration process, the user was prompted to input the x- and y-coordinates of the sensor (in millimeters) relative to the robot’s base. These coordinates were 27 4. Methods essential for later calculating the boundaries in robot-centric space. If the sensors were moved then the system had to be calibrated again. The calibration program was structured around creating an array with 3,600 ele- ments for each sensor, where each element represented one 0.1 degree increment around the sensor. Initially, all array values were set to zero. During calibration, the sensor would continuously scan the room, and for each reading, it would insert the measured distance into the corresponding array index based on the angle of the reading. If the element at that index was still zero, the new reading was directly stored. If a value was already present, the program would take the average of the new and existing values, allowing it to smooth out noise or minor fluctuations in the sensor data over multiple scans. To properly average the distance for a given angle, a second ’instances’ array was introduced, also with 3,600 elements, corresponding to the 0.1 degree resolution, for each sensor. This array kept track of how many times each angle had been scanned. When a new reading was received, the program would now calculate a weighted average, multiplying the existing value by the number of times that angle had already been scanned, adding the new reading, and dividing the sum by the updated scan count. This greatly improved the stability and accuracy of the calibration, ensuring that outlier readings had a minimal impact over time as more data accumulated. To further enhance the reliability of the data, the program also used the confidence value provided by the LD06 sensor for each distance reading. Readings with low confidence, indicative of weak reflections or potential errors, were discarded entirely, preventing poor-quality data from influencing the calibration. The calibration process would run in 30 second increments until a distance had been read for all 3,600 angles for each sensor. After the calibration was completed, the finalized 360-degree distance profile was saved to a .csv file, along with each sensors position. This file could then be loaded and referenced in subsequent programs, enabling the system to interpret live sensor data in the context of the robot’s sur- roundings. If an object is placed in the stop-zone, which should not be classified as an intrusion, then the system must be calibrated again to take the new object into account. The entire pseudo algorithm for calibrating the sensors can be seen in Algorithm 2. 4.2.4 Testing the Calibration Program To evaluate the calibration program, a test script was written to extract the distance measurements for each sensor at selected angles in the calibration .csv file. In the test the angles 0°, 90°, 180° and 270° were chosen for each sensor. At the same angles, the actual distances was then measured manually using a measuring tape, from the sensor to the nearest obstruction. These measured distances were compared against the corresponding calibrated values. The average difference, the absolute average difference and the maximum absolute difference were then found and evaluated. 28 4. Methods Data: Incoming data from four sensors Result: A CSV file with calibrated distances at 3,600 angles per sensor 1 Initialization: 2 Initialize arrays calibrated_values and instances with 3,600 zeros 3 Set minimum confidence threshold 4 Ask user for (x, y) positions of each sensor 5 while not all 3,600 angles are calibrated do 6 Read incoming distances and angles from sensor 7 Round angles to nearest 0.1 degree 8 for i← 1 to 12 do 9 angle_index ← rounded angle at index i 10 if calibrated_values[angle_index] is 0 then 11 calibrated_values[angle_index] ← current distance 12 instances[angle_index] ← 1 13 end 14 else 15 old ← calibrated_values[angle_index] 16 new ← current distance 17 count ← instances[angle_index] 18 average ← old · count + new count + 1 19 calibrated_values[angle_index] ← average 20 instances[angle_index] ← count + 1 21 end 22 end 23 end 24 Save calibrated_values and (x, y) positions to a CSV file Algorithm 2: Calibration loop for LiDAR sensors 4.2.5 Object Detection in Relation to Sensors In order to begin constructing the actual virtual safety system, a program was required to detect intrusions, specifically whether an object or person crossed a de- fined boundary relative to one of the sensors, which would later be translated to a robot-relative coordinate system. The goal of this program was to issue a warning whenever a measured distance was both within a defined proximity of the sensor (e.g. 300 mm) and had a high confidence level. Importantly, it also needed to account for stationary obstacles like walls that were already present in the calibrated envi- ronment - meaning the system should not trigger false positives simply because an object was close, but only when it was unexpectedly closer than during calibration. To implement this, the first step was to load the calibration data from a .csv file, which contained the average distances around each sensor collected during the initial scanning phase. These values represented the expected distances to surrounding surfaces at 0.1 degree angular resolution, 3,600 entries total. The values were loaded from the file into an array. 29 4. Methods The program for handling potential intrusions were built on top of the data reading program for one sensor, Algorithm 1, which processes incoming measurement data packets in batches of 12 readings. Each data batch included 12 angles, 12 distances, and 12 confidence values. The angles were rounded to 0.1 degree resolutions, and these angles were used to reference the measured distances at those angles in the calibration array. The core logic for intrusion detection was included within a function, where the 12 readings for angles, distances and confidences are looped. For each packet, low- confidence values readings are filtered out by checking if the confidence is above a user-defined threshold. For high-confidence readings, the measured distance at a measured angle gets checked for intrusion in an if statement: • If the calibrated value is already below the threshold (e.g. due to a wall), it only triggers if the new reading is even closer than the calibration by a set accuracy margin (e.g. 60 mm). • If the calibrated value is above the threshold, the system will alert if the new distance drops below the threshold, indicating something has entered a previously clear area. Each valid reading that satisfies either of these alert conditions increments an alert index. If more than three such readings are found in a single packet, the program prints an intrusion message to signal that a person or object may have entered the threshold defined around the sensor. Although the sensor values were filtered by confidence, some nonsense data slipped through. The alert index filtering limited the amount of false alerts tolerable, reducing the number of false intrusions. The pseudo algorithm for finding intrusions can be seen in Algorithm 3. This structure proved successful, as it provided a robust and flexible foundation for real-time intrusion detection in relation to reach sensor. It filtered out irrelevant or noisy readings, and was comparing incoming data against a known environment. This is demonstrated in Figure 4.7 While this program did not yet calculate the object’s position in relation to the robot itself, it was still a valuable tool during development. It helped verify that each individual sensor was functioning correctly and provided immediate feedback when something entered its detection zone. This became especially useful when restarting the Raspberry Pi, as the order in which the sensors were connected affected how they were indexed by the system. The sensors were labeled from 0 to 3. As an example, if Sensor 0 was plugged in first, it would be referenced as Sensor 0 in the system. But if Sensor 1 was connected first, it would be referenced as Sensor 0 in the system. As a result, the same physical sensor could be assigned a different ID after a restart or reconnection. By using this program and observing which sensor triggered intrusion alerts in response to entering within a 10 cm threshold, it was possible to quickly identify and label each sensor correctly before running calibration. 30 4. Methods Data: Angles, distances, and confidence values from one LiDAR sensor. Result: Intrusions found within a set distance threshold. 1 Filter measurements: 2 Remove all measurements with confidence below a defined threshold 3 Start intrusion counter 4 foreach remaining measurement do 5 Compare measured distance to reference value from calibration 6 if calibrated values are closer than threshold and incoming measurements are closer than calibrated values then 7 Add +1 to intrusion counter 8 else if calibrated values are not closer than threshold and incoming measurements are closer than threshold then 9 Add +1 to intrusion counter 10 end 11 Evaluate intrusion level: 12 Count number of intrusions 13 Determine current state: 14 if Intrusions violations > 3 then 15 Prompt INTRUSION message 16 end Algorithm 3: Intrusion detection based on LiDAR measurements and cali- bration 4.2.6 Converting Calibrated Sensor Data to the Robot Co- ordinate System Following the calibration procedure, the recorded distances were still relative to each sensor’s local coordinate system rather than the robot’s global coordinate system. To enable spatial interpretation of the sensor data from the robot’s perspective, each reading needed to be transformed using vector addition. As described earlier, the user is prompted at the beginning of the calibration rou- tine to input the x- and y-coordinates of each sensor’s position relative to the robot. These coordinates are then stored in the calibration file. To facilitate the transfor- mation, these cartesian coordinates are first converted to polar coordinates using the following relationships: r = √ x2 + y2 (4.1) ϕ = arctan ( y x ) (4.2) Where r is the distance from the origin, x and y are the x- and y-coordinates and ϕ is the counter-clockwise angle in the polar coordinate system. 31 4. Methods Figure 4.7: Representation of the detection zone around a sensor, with a person breaking the set threshold. It is important to note that the sensors report angles in a clockwise direction, whereas the standard trigonometric convention assumes angles to be positive in the counter- clockwise direction. Therefore, all angle values obtained from the sensors were adjusted by subtracting them from 360 degrees, e.g. a sensor reading of 90 degrees (clockwise) was interpreted as 270 degrees in the robot’s coordinate system. This is demonstrated in Figure 4.8. Figure 4.8: How sensor angles were recalculated from an counter clockwise direc- tion to a clockwise direction. These r and ϕ values represent the radial distance and angle from the robot’s center to the respective sensor. Using this offset, each calibrated distance measurement can be recalculated into the robot’s coordinate system. This is done using the following formulas shown below [53]: r = √ r2 1 + r2 2 + 2r1r2 cos(ϕ2 − ϕ1) (4.3) 32 4. Methods ϕ = ϕ1 + arctan 2 (r2 sin(ϕ2 − ϕ1), r1 + r2 cos(ϕ2 − ϕ1)) (4.4) Here, r1 is the distance from the robot to the sensor, and ϕ1 is the angular offset of the sensor in the robot’s coordinate system. r2 is the measured (calibrated) distance at angle ϕ2 relative to the sensor’s local orientation. r is the distance from the robot to the detected object and ϕ is the angle from the robot to the object. The parameters for the calculation is visualized in Figure 4.9. The procedure for how the calculation is made can be seen in Algorithm 4. Data: csv file with 3,600 calibrated measurements per sensor: (r2, ϕ2) Sensor position (x, y) and orientation ϕ1 (relative to robot) Result: Transformed object positions (r, ϕ) in robot’s coordinate system 1 Convert sensor position to polar coordinates: 2 r1 ← √ x2 + y2 3 ϕ1 ← atan2(y, x) 4 Load 3,600 measurements from csv file into array measurements 5 foreach (r2, ϕ2) in measurements do 6 Adjust angle from sensor: 7 ϕ2 ← 360◦ − ϕ2 8 Compute angle difference: 9 ∆ϕ← ϕ2 − ϕ1 10 Apply vector addition to compute global object position: 11 r ← √ r2 1 + r2 2 + 2r1r2 cos(∆ϕ) 12 ϕ← ϕ1 + atan2(r2 sin(∆ϕ), r1 + r2 cos(∆ϕ)) 13 Store (r, ϕ) in array; 14 end Algorithm 4: Transform 3,600 sensor measurements to robot’s coordinate system Applying these transformations for all four sensors provided a unified and accurate representation of the robot’s surroundings, allowing the system to detect obstacles and assess proximity from a common spatial reference as seen in Figure 4.10 4.2.7 Object Detection in Relation to Robot To enable a functional safety system, the incoming sensor data stream needed to be continuously converted into the robot’s coordinate system. This would allow for a unified spatial understanding of the environment, enabling decisions about robot behavior based on object proximity regardless of which sensor detected it. As with the angle conversion during the calibration process, all real-time sensor angles, measured clockwise, were adjusted to fit the counter-clockwise convention of the robot’s coordinate system. For instance, a sensor reading of 90 degrees was interpreted as 270 degrees, 45 degrees became 315 degrees, etc (see Figure 4.8). This conversion ensured consistency in spatial interpretation. 33 4. Methods Figure 4.9: The different parameters for calculating the distance and angle from a sensor perspective to a robot perspective. All sensor data was then continuously transformed using the same vector addition method applied during calibration. Each sensor’s angle of perspective was converted into the robot’s frame of reference using Equation 4.2. The measured distance was also recalculated relative to the robot using Equation 4.1. This transformation used the x- and y-values for each sensor put in during the calibration process. Two critical distance thresholds, seen in Figure 4.11, were implemented to govern the robot’s response to detected objects: • Slow-zone threshold: If an object was detected within this range, the robot would continue operating but at reduced speed. This boundary was set 500 mm beyond the stop-zone for added safety margin, during testing. • Stop-zone threshold: If an object was detected within this range, the robot would halt immediately. The logic used to trigger alerts was an extension of the method developed for sensor- based detection. Each sensor sends data in packets of 12 readings. For each reading, after converting the measured angle and recalculating the position relative to the robot, the program evaluated whether the detected point fell within either threshold. Two alert counters were used: • One alert counter for Slow-zone intrusions • One alert counter for Stop-zone intrusions If more than three in a single data packet triggered the same type of alert, or if 34 4. Methods Figure 4.10: How the robot sees the environment after vector addition done to the sensors calibrated values. the combined number of slow- and stop-alert counters in that packet was more than three, a system-wide ”SLOW” or ”STOP” warning was issued. The alert also included information about which sensor triggered it. The entire pseudo algorithm for handling intrusions can be seen in Algorithm 5. The safety system architecture can be seen in Figure 4.12. 35 4. Methods Figure 4.11: Representation of safety zones. 36 4. Methods Data: Angles, distances, and confidence values from one LiDAR sensor. Result: Intrusions found within a set distance threshold. 1 Filter measurements: 2 Remove all measurements with confidence below a defined threshold 3 Recalculate incoming sensor measurements and angles to robot perspective 4 Start intrusion zone counters: 5 stop_violation_counter 6 slow_violation_counter 7 foreach remaining measurement do 8 Compare measured distance to reference value from calibration 9 if calibrated values are closer than stop-threshold and incoming measurements are closer than calibrated values then 10 Add +1 to stop_violation_counter 11 else if calibrated values are not closer than stop-threshold and incoming measurements are closer than stop-threshold then 12 Add +1 to stop_violation_counter 13 else if calibrated values are closer than slow-threshold and incoming measurements are closer than calibrated values then 14 Add +1 to slow_violation_counter 15 else if calibrated values are not closer than slow-threshold and incoming measurements are closer than slow-threshold then 16 Add +1 to slow_violation_counter 17 end 18 Evaluate intrusion level: 19 if stop_violation_counter > 3 then 20 Prompt STOP message and Sensor ID 21 else if slow_violation_counter > 3 then 22 Prompt SLOW message and Sensor ID 23 else if slow_violation_counter + stop_violation_counter > 3 then 24 Prompt STOP message and Sensor ID Algorithm 5: Intrusion detection in relation to robot 37 4. Methods Figure 4.12: Representation of program architecture at this stage 4.2.8 Testing Object Detection in Relation to Robot To evaluate the object detection system in relation to the robot’s safety zones, two types of test cases were conducted: one for slow-zone intrusions and one for stop- zone intrusions. The stop-zone was defined as a radius of 1,000 mm from the robot, while the slow-zone extended to 1,500 mm. These distances were clearly marked on the ground to ensure consistent positioning during testing. Each test involved a person starting from a position well outside the defined safety zones and then walking into the area, exceeding the respective threshold by more than 100 mm. The system was expected to issue a ”SLOW” alert when entering the slow-zone and a ”STOP” alert upon entering the stop-zone. In each case, the system also displayed the angle and distance of the detected object relative to the robot, along with the corresponding safety message. The outcome of each test was recorded using a binary scoring method: a score of 1 for a successful alert and 0 for an unsuccessful one. A total of 10 tests were performed for each safety zone, and the results were documented in a test protocol. 4.2.9 Determining the Size of the Safety Zones According to ISO 13855 [54], the minimum distance to a hazardous point can be determined using the following formula: S = K · (t1 + t2) + C + Zt (4.5) This formula in turn creates a defined critical safety zone around a machine, in this 38 4. Methods case an industrial robot. The value of K, representing the human approach speed in mm/s, is often set according to recommended values in ISO 13855. For full- body movement, the standard specifies K = 1600 mm/s which corresponds to a fast walking speed. t1 is the response time of the system [s], t2 is the machine stopping time [s], Zt is a general safety allowance and C is an additional distance depending on the height of the scanning plane and the scanner resolution: C = 1200 − 0.4H, where H is the height of the scanning plane. One key parameter in this equation is the variable K, which represents the intruding object’s approach speed. Although it was theoretically possible to calculate this speed dynamically within the system, the associated complexity of the calculations led to the decision to use a fixed value. While the ISO standard assumes a typical human walking speed of 1,600 mm/s, this value was deemed insufficient for the intended safety requirements. The system is designed not only for normal operations but also to account for unexpected or accidental intrusions. Therefore, a more conservative speed of 4,000 mm/s was selected to reflect the velocity of a person unintentionally entering the safety zone, for example by stumbling or tripping. To determine the system’s reaction time, several tests were conducted. These mea- sured the interval between the detection of an object and the transmission of a stop signal to the robot. The results showed an average reaction time of 10 ms, which was used as the t1 value in the equation. The robot’s actual stopping time (t2) could not be measured directly during testing. Instead, it was estimated based on the robot’s datasheet specifications. The robot has a maximum speed of 3 m/s and a peak deceleration of 36 m/s2, yielding a theoretical stopping time of approximately 83 ms [20]. To ensure a conservative safety margin, this value was rounded up to 100 ms. The approach distance C was calculated using a detection height H of 150 mm, resulting in a C value of 1140 mm. Additionally, a general safety allowance Zt of 900 mm was included. This value corresponds to the robot’s maximum operational reach. Combining these values, the minimum safe stopping distance was calculated as follows: S = K · (t1 + t2) + C + Zt = 4000 · (0.01 + 0.1) + 1140 + 900 = 2480 mm (4.6) For simplicity and safety, this value was rounded up to 2,500 mm. Due to spatial constraints in the development environment, testing with the full 2,500 mm stop- zone was not feasible. Instead, tests were conducted using only reduced stop zones of 1,000 mm and 2,000 mm. The slow-zone was also implemented, extending always 500 mm beyond the boundary of the stop-zone. 39 4. Methods 4.2.10 Creating a ROS 2 Workspace on the Raspberry Pi To effectively stop the robot’s movement and enable real-time communication of sensor data and safety alerts, the system needed to broadcast information such as proximity readings and stop- or slow-zone warnings. This logic is implemented in the Raspberry Pi using a ROS 2 package named virtual_fences, containing three Python scripts, each serving a distinct role in the safety system. 1. Identification – This script was used to determine which physical sensor corresponds to which ID in the system. By waving a hand within 10 cm of one sensor, the ID of that sensor would be displayed, which then could be used when entering x- and y-position for that sensor in the calibration program. 2. Calibration – This script guided the user through entering the physical x- and y-positions of each sensor. It then performed a 360.0 degree scan of the environment and saved the average measured distances at each angle into a .csv file. These calibration files were later loaded into the safety system to define expected environmental boundaries. 3. Safety System – This was the main script responsible for evaluating the environment in real time. It continuously processed sensor readings and de- termined whether any object or person had entered the robot’s predefined safety zones (slow or stop). Each of these scripts could be executed using the command: ros2 run virtual_fences Where would be replaced with either identify, calibrate, or activate, depending on which functionality was required. With the ROS 2 project in place, development towards a working simulation could take place. 4.2.11 Publishing Sensor Data The safety system script uses Python’s multiprocessing library so that each sensor can be handled by a separate process. When a sensor process receives a data packet from the LiDAR, it places the data in a queue, which serves as a shared memory between the processes. A ROS 2 node then periodically publishes messages from the shared queue at a rate of 100 ms as LaserScan messages on the /laser_scan topic. This makes the data available to all other nodes in the network, including visualization tools such as RViz2. This approach allowed all sensor data to be published on a single topic, while also ensuring that each sensor process could operate independently. Furthermore, com- putational overhead was reduced as sensor processes were not burdened with pub- lishing tasks and could instead focus solely on reading data. The architecture with the sensor data publisher can be seen in Figure 4.13 40 4. Methods As the purpose of publishing sensor data was solely for visualization, and not part of the real-time safety mechanism, a 100 ms interval was deemed sufficient. Figure 4.13: Program architecture with data queue and timed data publishing 4.2.12 Publishing Robot Control Messages To indicate a safety zone breach, an independent timer node publishes control mes- sages on the /robot_control_topic at a high frequency (every ten milliseconds). To prevent the system from being overwhelmed with simultaneous messages from mul- tiple sensors, this timer node also uses a dedicated queue to read control messages from each sensor process, indicating whether an object entered either the slow-zone or stop-zone. If a sensor process detects an object in the slow-zone, a slow message is placed in the queue. Similarly, if an object enters the stop-zone, a stop message is inserted. When one or more stop messages are detected, the node publishes a single STOP-signal to the robot. Once a slow message is detected, a SLOW-signal is sent. These control signals were represented by integer values, with 2 indicating a slow-zone breach and 1 indicating a stop-zone breach. Only one message is sent during each zone breach. This architecture can be seen in Figure 4.14. The architecture offered several advantages: • Only one control message was published per event, avoiding message conges- tion or potential conflicts caused by multiple sensors triggering simultaneously. • The high-frequency timer ensured fast response times to safety zone violations. • Communication with the robot was simplified, as only a single ROS 2 topic was needed to convey control messages. 41 4. Methods Figure 4.14: Program architecture with control messages queue and timed mes- sages publishing 4.2.13 Visually Displaying Zone Breaches using LEDs To effectively communicate proximity breaches to a user, visual indicators were implemented using LEDs connected to the Raspberry Pi’s GPIO pins. Four LEDs were used in total, with each one assigned to a specific sensor. In the software, each sensor was linked to a corresponding GPIO pin, and its LED behavior was controlled based on the type of safety zone breach detected: • If an object entered the slow-zone, the assigned LED began blinking slowly to signal caution. • If the object continued into the stop-zone, the LED switched to a rapid blink- ing, indicating that the object had reached the critical area closest to the robot. 42 4. Methods Figure 4.15: Demonstration of LEDs lighting up when a person breaches a security zone. The safety zones are here smaller than allowed due to demonstration purposes. Since the LEDs served solely as a visual indicator to show when an intrusion had occurred, the real-time control of the LEDs was assigned a lower priority. During testing, the LEDs accurately reflected intrusion events, but with a slight delay that did not affect the speed and performance of the overall safety system. A demon- stration of the LEDs can be seen in Figure 4.15. This progressive LED signaling provided an intuitive and immediate way to assess the system’s status during testing and its architecture can be sen in Figure 4.16. It would allow for users to quickly understand both the presence of intrusions and their severity, contributing to a more transparent and user-friendly interface. 43 4. Methods Figure 4.16: Program architecture with added LED functionality 4.2.14 Testing the Safety System The following tests were carried out to test the safety system: • Response Times – Incoming data → “STOP” signal sent to robot, without sensor data publishing, LED control, or emergency stop button – Incoming data → “STOP” signal sent to robot, without sensor data publishing – Incoming data → “STOP” signal sent to robot, with sensor data pub- lishing – Emergency button pressed → “STOP” signal sent to robot, without 44 4. Methods sensor data publishing – Emergency button pressed → “STOP” signal sent to robot, with sensor data publishing • Data Filtering – Number of false STOP intrusions, 1 m stop-zone, without sensor data publishing – Number of false STOP intrusions, 1 m stop-zone, with sensor data pub- lishing – Number of false STOP intrusions, 2 m stop-zone, without sensor data publishing – Number of false STOP intrusions, 2 m stop-zone, with sensor data pub- lishing – Number of false STOP intrusions, 1 m stop-zone, without sensor data publishing, LED control, or emergency stop button – Number of false STOP intrusions, 2 m stop-zone, without sensor data publishing, LED control, or emergency stop button The response time was measured in the software by time stamping key events in the system. When a data packet was received from the LiDAR sensors, the current system time was recorded. If the packet indicated an object within the defined stop-zone (set to 1,000 mm), this timestamp was sent along with the STOP message to the Robot Control Timer node. A second timestamp was taken in the Robot Control Timer node immediately after the STOP signal was published to the robot. The time difference between these two timestamps was calcul