Composing Relative Spatial Location Models in Skill-based Robotic Reconfigurable Cyber-Physical Production Modules

COMPOSING RELATIVE SPATIAL LOCATION MODELS IN SKILL-BASED ROBOTIC RECONFIGURABLE CYBER-PHYSICAL PRODUCTION MODULES.∗ Aleksandr Sidorenko, Martin Ruskowski, Achim Wagner Innovative Factory System German Research Center for Artificial Intelligence (DFKI) Kaiserslautern, Germany [email protected] ABSTRACT Skill-based robotic reconfigurable cyber-physical production modules (RCPPMs) have an aggregated structure, and their functionality depends on the submodules and components that define their current topology. This application-oriented paper proposes a method for integrating the OPC UA Relative Spatial Location (RSL) Companion Specification models and the ROS2 tf2-library functionality to automatically update the SRL models of the RCPPMs when their structure changes. This enables the proper composition and sharing of the necessary information regarding the kinematic structure of each RCPPM’s submodule. On an example, we illustrate how this approach can be employed to enhance the coupling functionality of the skill-based robotic RCPPMs. Keywords skill-based robotic reconfigurable cyber-physical production modules · spatial relative locations · tf2 transform system ·OPC UA SRL companion specification 1 Introduction Skill-based robotic reconfigurable cyber-physical production modules (RCPPMs) can become the backbone of future cyber-physical production systems (CPPSs) by enabling rapid adaptation responses to changing conditions at the machine’s level [ 1 ]. One of the challenges is that such modules must be able to integrate new, unknown submodules and adapt their functionality accordingly. It is crucial for the robot-based RCPPM to properly integrate the information about the spatial relationships of all its submodules and components that define the actual module’s topology. A simple example that demonstrates this necessity is an RCPPM with a central robotic handling station and several ports for various technological modules that can be coupled to the handling station and enable new functionalities. As the structure of such RCPPM can change arbitrary, the robot’s movements cannot be preprogrammed. Consider the robot’s MovePTP skill, which enables it to generate the movement trajectory based on the target pose in the known coordinate system and optional intermediate poses. Now, consider that the robot must pick the gripper from the newly connected tool-changing module. The robot could use a camera and sophisticated calibration, as well as object localization algorithms, to try to estimate the gripper’s location and to generate the trajectory. A more simple and practical alternative, considering the stable structure of the tool-changing module, would be to deliver the information about the required trajectory, e.g., as a sequence of the poses, with the module itself. The difficulty here is that these poses are defined in the local to the tool changer coordinate system, and the port where the tool changer is connected can be chosen arbitrary. We must properly integrate all the coordinate frames and their relations of both modules during the coupling procedure to create the new spatial configuration of the RCPPM. This motivates us to investigate methods for composing this information during the (re-)configuration of RCPPMs to enable their plug-and-produce functionality. We are particularly interested in two technologies: OPC UA, which enhances interoperability in the ∗Citation :A. Sidorenko, M. Ruskowski and A. Wagner, "Composing Relative Spatial Location Models in Skill-based Robotic Reconfigurable Cyber-Physical Production Modules," 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA), Porto, Portugal, 2025, pp. 1-4, doi: 10.1109/ETFA65518.2025.11205661. industrial automation domain, and ROS2, which enables the rapid implementation of robotic applications and has a distributed architecture, which is essential for RCPPMs. 2 Related Works The authors in [ 2 ] have listed the expected benefits of using skills in manufacturing, as well as challenges that must be overcome. In the previous years, several prototypes have shown the applicability and benefits of using skill-based design for modular, plug-and-produce capable production systems [ 3 , 4 ]. In [ 1 ] the authors proposed a skills composition framework with the focus on reconfiguration at the machine’s level. One of the challenges here is sharing and composing configuration information from different components. As the topic of coordinate transformations is crucial for robotics, the robotics community has developed the powerful mathematical tools and software packages to deal with all sorts of such problems. One of them is a tf2 package 2 of the ROS2 that provides advanced coordinates transformation capabilities for the ROS-ecosystem. A detailed design of the tf library is described in [ 5 ]. The library provides a standard mechanism to track and transform all the coordinate frames that exist in the system. However, this tool is platform-specific and has limited interoperability, particularly in the field of industrial automation. On the other hand, the OPC UA technology is a modern communication and modeling framework that aims to ensure interoperability in manufacturing environments. The Relative Spatial Location UA Companion Specification (RSL UA CS) [ 6 ] defines the models to enhance objects with location information and bring them into relationship. However, the RSL provides the static model, leaving the implementation of the transformation mathematics to the developer. The integration of these technologies would be beneficial for both the industrial automation and robotics communities. 3 Integration Methodology As it will be shown in section 4, OPC UA is the primary interface used by all our production modules. This reflects our vision of ubiquitous OPC UA-based communication at the machine level. As many of our robots are powered by ROS2, a task at hand is how to better incorporate modules’ spatial locations information into the ROS2 space of our robots and visaversa. Our approach is inspired and based on the robot_state_publisher 3 ROS2 package, though we cannot use it directly as it requires the URDF description of the module as an input. Instead, our module_state_publisher (MSP) gets an input in the form of the so-called spatial dependencies tree (SDT), which is created by the OPC UA client by browsing the OPC UA RSL model as described in the RSL UA CS. For each edge of the SDT, the MSP broadcasts a tf2 transform message. If a constant bit of an object of type SpatialObject is True, meaning that the object is fixed and its pose will not change over time, then static tf2 transform is broadcasted. Otherwise, the type of transformation can be taken from the MotionProfile property of the AxisType that is defined in the OPC UA for Robotics CS [ 7 ]. If the type of motion is defined, then the dynamic tf2 transform will be published. In this case, the information from the sensors must be provided in the form of the JointState messages. A tf2 transforms listener subscribes then to the \ tf topic to update the spatial objects of the RSL model. We leave this out of scope for now, as there might be various design options here. In our setup, we have a fixed coupling between the connected modules, as will be explained in the next section. In that case, to combine the frame trees from both modules, one needs to create a static tf2 transform broadcaster with the parent frame_id as the frame of the main module and the child_frame_id as the frame of the being connected submodule. This might also work in a more complex scenario without the fixed coupling, thought one will require a dynamic tf2 transform broadcaster together with the data from the respective sensors. 4 Case Study In the SmartFactoryKL 4 a standard hardware architecture as well as an OPC UA model for a cyber-physical production module (CPPM) have been developed. This facilitates plug-and-produce functionality at the mechanical, electrical, and software levels. One of the concepts supporting this functionality is called a module’s port. From a hardware perspective, a port is the electromechanical link that connects two modules and guarantees a reliable module coupling. In the module’s OPC UA model, the port object has a skill called Couple, whose primary goal is to engage the electromagnet of the port and to monitor the connection. We demonstrate in this section how the concepts previously discussed can be 2https://github.com/ros2/geometry2 3https://github.com/ros/robot_state_publisher/tree/rolling 4https://www.smartfactory.de/ 2 Figure 1: Composing RSL models. (a) SDT. (b) Hardware setup. (c) OPC UA model. (d) Sequence diagram. 3 employed to enhance the coupling functionality of the port, enabling the composition of the RSL models of the coupled modules. We continue using the example given in section 1, where the RSL models of the two modules shown in Fig. 1(b) need to be composed to enable the robot of the handling module to change a tool in the tool changer. The sequence of poses is defined relative to the local reference pose Pref and can be provided together with the module’s OPC UA model. Fig. 1(c) shows the simplified OPC UA models of both modules in parts concerned with the use of the SRL. We use the notation and the model’s simplifications taken in the SRL UA CS [ 6 ]. The dependencies between the spatial locations are shown by the green arrows. Each module’s component is geometrically described using the SpatialObjectType Addin as described in the companion specification. We suggest that the port’s current coupling functionality be enhanced by the addition of an additional skill, the UpdateTopology skill. This skill accepts a parameter Port of type NodeId, which references the port object of the neighbor’s UA server (see 1 in Fig. 1(c)). Coordinate frames and transformations between them can be presented as a graph with the frames as nodes and the transformations as edges. To avoid potential transformation conflicts, the tf2 requires the graph to be acyclic and form a tree to provide a quick transform lookup [ 5 ]. Fig. 1(b) shows the transformation trees overlaid on each module. The transformation can be computed between the frames within one tree, but not between the disconnected ones. A spatial dependencies tree (SDT) is shown in Fig. 1(a), where the nodes of the tree represent spatial locations, or frames, and the arrows denote child-parent relations between frames, that is, an arrow points to a parent. This also aligns with the OPC UA model, where relations between spatial locations are made in the direction of a base frame. When we connect the modules and create the static transformation with the parent frame D1 and the child frame D′ 2 , we might have a conflict, as now the frame D′ 2 has two parents: A′ 2 and A1 (see the dotted red arrow D′ 2→D1 . To avoid this, we have decided to use the RSL concept of alternative frames. In the OPC UA RSL model of the tool changer, the ModuleBase has an alternative frame ToOwnCouplingFrame (see 2 in Fig. 1(c)), which base is the alternative frame ToNeighbourCouplingFrame of the Port (see 3 in Fig. 1(c)). Effectively, this is an inverse transformation between the module’s base frame and the port frame, which makes the port frame the root of the transformation tree (see the dashed arrow A” 2→D” 2 in Fig. 1(a)). When executing the skill UpdateTopogy with the port’s NodeId as a parameter, we want to build an SDT with the port’s frame as a root: C2→B2→A” 2→D” 2. A sequence diagram in Fig. 1(d) shows an exemplary process of modules’ coupling and composing their RSL models. The process starts with the activation of the electromagnetic lock by executing the Couple skill. After the modules are securely coupled, the UpdateTopology skill of the HandlingModule is called. In the background, the server uses the UA client to connect to the ToolChanger and get all the SRL dependencies, as described in the SRL UA CS [ 6 ]. From them, it tries to build the neighbor SDT with the root in the frame of the spatial object given as the parameter to the skill. The ModuleStatePublisher takes this SDT and creates a static transform broadcaster for each edge of the tree. Lastly, it creates the static transform with the parent frame of the handling module’s port and the child frame of the tool changer’s port. This transform is always known as the connection between the modules is standard and fixed. 5 Discussion and Conclusion Combining RSL models from various submodules is vital for the RCPPMs. Using the ROS2 tf2 package together with the OPC UA RSL CS appears to be helpful for this purpose, given the tf2’s features and the distributed nature of ROS2, as well as the powerful modeling capabilities of OPC UA. There is still a significant amount of work that must be completed. First experiments involving online editing of the URDF description of the modules showed non-scalable results. Nevertheless, using the URDF notation for the description of the module’s kinematics might be useful, as the URDF is more informative compared to the current version of the RSL UA CS. Additionally, there are many ready-to-use URDF models of the most popular robots. Another useful functionality worth implementing is the generation of an RSL UA model from the tf tree of the robot. As one of the main features of the tf2 is the frames’ transformation quiring capability, this functionality must be added to the RSL UA model, so a user could quire for the arbitrary frame transformation using the standard OPC UA interface. The current RLS UA model only defines if a spatial location is static or might change in the future. The model can be improved by incorporating the type of transformation, such as rotation or translation, or even the constraints that must be respected during the movement in this frame. This allows for a more precise path specification for the robot. In addition, it is necessary to consider other more general and complicated use-cases, such as an interaction between two robots, potentially on mobile platforms, for handing over a product. Finally, as ROS is sometimes criticized for not being suitable for industrial applications with high requirements for reliability and real-time constraints, it is possible to develop a custom backend using a Kinematics and Dynamics Library (KDL) 5 , which is an application-independent framework for modeling and computing kinematic chains, and the tf2 package uses it as its backend. 5https://docs.orocos.org/kdl/overview.html 4 The article offers preliminary concepts regarding the automatic composition of the RSL models in the skill-based robotic RCPPMs during their reconfiguration. Although it focuses on the integration of two distinct technologies, it illustrates the potential of utilizing an industry-accepted information modeling and communication framework, such as OPC UA, and an advanced coordinate transformation backend to enhance the plug-and-produce capabilities of the skill-based RCPPMs. Conference This is the accepted manuscript of an article published by 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA) 6 on 21.10.2025. The final version of record is available at the IEEEXplore7. Funding This research has been supported by the European Union’s HORIZON Research and Innovation Action Program under the grant agreement No 101138782, the project RAASCEMAN 8, and is distributed under the CC BY 4.0 license. References [1] Aleksandr Sidorenko et al. Skills composition framework for reconfigurable cyber-physical production modules. In 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), pages 1–8, 2024. [2] Roman Froschauer et al. Capabilities and skills in manufacturing: A survey over the last decade of etfa. In 2022 IEEE 27th International Conference on Emerging Technologies and Factory Automation (ETFA), pages 1–8, 2022. [3] M. Volkmann et al. Integration of a feasibility and context check into an OPC UA skill. IFAC-PapersOnLine, 54(1):276–281, 2021. [4] Patrick Zimmermann et al. Skill-based engineering and control on field-device-level with OPC UA. In Proceedings of the IEEE international conference on emerging technologies and factory automation (ETFA), September 2019. [5] Tully Foote. tf: The transform library. In 2013 IEEE Conference on Technologies for Practical Robot Applications (TePRA), pages 1–6, 2013. [6] OPC Foundation. OPC Unified Architecture Part 210: Relative Spatial Location. Industry Standard Specification OPC 10000-210, OPC Foundation, January 2023. [7] OPC Foundation. OPC UA Companion Specification for Robotics — Part1: Vertical integration. Industry Standard Specification OPC 40010-1, OPC Foundation, June 2019. 6https://doi.org/10.1109/ETFA65518.2025 7https://doi.org/10.1109/ETFA65518.2025.11205661 8https://cordis.europa.eu/project/id/101138782 5