1 Introduction

To achieve a competitive edge, companies are constantly on the lookout for ways to offer a higher level of customisation of their products at increasingly higher quantities and with a shorter lead time [1,2,3]. This, in turn, calls for more flexible and intelligent development processes. Robotic automation has the potential to improve quality, flexibility, and save costs for manufacturers with shorter production runs and facilitate higher production up-time [4]. However, traditional robot programming methods and transitional phases between Computer-aided Design (CAD) and Computer-aided Manufacturing (CAM) still suffer from inefficient and time-consuming processes [5, 6]. Additionally, these inefficiencies become an even more significant hurdle when applied to the high demand for product customisation. Finally, when coupled with the initial expenses and required expertise linked with the implementation of robotic manufacturing, many Small- and Medium-sized Enterprises (SMEs) struggle to justify the adaptation of such systems [7]. Automatic generation of robot welding programs can be challenging and complex, depending on the geometry, especially when the geometry is parametric and constantly adapted to user demands.

In addition to higher flexibility and robotic implementation, utilising aluminium alloys in marine structures is also becoming increasingly desirable [8]. Aluminium alloys, with their high strength-to-weight ratio, allow for more lightweight designs, which can be useful for marine applications. This, unfortunately, comes with a price of several challenges in its manufacturing to reach adequate levels of structural integrity [9]. With regard to welding, these challenges are reflected as requiring higher levels of consideration of welding conditions and techniques to ensure proper fusion. In addition, the reflective nature of aluminium surfaces makes it more difficult for visual sensing systems, and the alloys are also more susceptible to thermal distortion.

This paper presents a framework and approach for generating robot welding programs starting from CAD. The particular distinction between the presented approach and earlier work is the focus towards high-mix-low-volume products, which can vary highly in geometry. Thus, the generation algorithm should be generalised with respect to geometry. Additionally, the program generation also considers requirements for particular welding operations in order to ensure sufficient structural integrity for the resulting welds. Such considerations become even more critical when manufacturing heat-sensitive materials such as aluminium.

The method utilises a combination of approaches for Automatic Offline Programming (AOLP), Automatic Feature Recognition (AFR), and a Knowledge Base (KB) to (1) automatically extract potential welds in addition to other relevant information from the CAD environment, (2) classify the different welding operations, and finally (3) generate rule-adhering robot welding programs. The developed system is incorporated into Siemens NX, using the NXOpen Python API to allow CAD functions to be accessed programmatically. It should be noted that while Siemens NX is used as a CAD-starting point in this paper, other CAD tools, such as Open Cascade and SolidWorks, can be used similarly [10, 11]. While the framework is developed with Python robotics toolbox as the underlying collision and kinematic functionality, the methods and algorithms described are not dependent on any particular tool, given that the same functionality is available.

The paper is structured in the following way. In Section 2, a literature review is conducted, describing current methods and presenting the identified gaps that are approached in this paper. In Section 3, the approach and system architecture is described in addition to the underlying methods for local wall extraction. Following, in Section 4, is a case study using several aluminium helideck nodes and a stiffener presentation as input for the automatic weld program generation. The parts and models used were provided by industrial project partners Marine Aluminium AS and Leirvik AS and are based on actual use cases. Section 5 then discusses the method’s viability and potential further work, going through the implementation. Finally, the conclusions are presented in Section 6.

2 Literature review

Present-day robotic programming methods are mainly comprised of two different programming modes; online and offline [12]. Online programming is done using teach pendants, relying on the expertise and skill of the robot operator to determine the robot’s behaviour [13]. While this allows for a more “hands-on” and intuitive problem-solving environment, the potential for automation is also more limited. Additionally, modifying and changing the product designs often leads to a manual reprogramming of parts or the entirety of the program while also requiring significant downtime of the cell during programming [14]. Offline Programming (OLP) relies on a digital environment to effectively simulate the robot programming process with spatial and kinematic models of the manufacturing environment, decreasing the required downtime [15]. This digital representation, in turn, enables robot programming and decision-making to be approached programmatically and with more intelligent algorithms, leading to so-called automated offline programming (AOLP).

AOLP is when algorithms, functions, and intelligent systems are layered on top of the path-planning capabilities of offline programming in a simulated manufacturing system, resulting in an automated process. Such automated functionality is appealing to industries that have a high demand for customisation and variation, which has resulted in an increase in research interest over time [13].

Many approaches have been presented for generating robot programs, with varying levels of autonomy, flexibility, and stability. For simplified setups, basic AOLP systems extending from CAD can be derived through the utilisation of in-built APIs for weld path extraction in combination with transformation calculations to invoke basic robot operations from the controller and assumptions about the setup [16,17,18]. However, manual steps are still required to provide viable tool orientations. In the case of [17], the setup enabled orientations to calculated with less attention to collision and singularities.

Other approaches utilise knowledge-based engineering principles and semantic knowledge models to automate decision-making for the generation of robot programs [19, 20]. While this enables the automatic generation of viable welding programs, current efforts utilising knowledge-driven systems have shown limited display regarding welding path complexity and flexibility in product geometries [21].

While these approaches are capable of solving the tasks they were intended for, further improvements are necessary for adaptation into industrial settings. For one, the program generation should be flexible and be able to solve based on product topology. Secondly, the output of the programs should contain solutions that are viable in ensuring structural integrity, as shown in the knowledge-driven methods. Larkin et al. demonstrated that using greedy search algorithms to find solutions from decomposed tasks- and configuration spaces is a viable topology-driven approach for welding operations [7]. With welding tool operations for these spaces established, path planning algorithms such as probabilistic roadmap (PRM) and rapidly exploring random trees (RRT) were further shown to be capable of solving the remaining via-point motions. The benefit of this approach is the flexibility and independence from deriving rule sets that only work on particular product geometries. Instead, only the collision topology and simulated manufacturing cell are considered baseline elements.

Recent advances in AOLP within existing welding research still need more diversity in targeted product geometry and managing the output programs to ensure viable welding. For welding operations, this includes consideration of gravity and welding requirements. While the aforementioned knowledge-driven approaches target this domain, their flexibility towards product geometry is limited. Therefore, the approach presented in this paper aims at providing a welding program generation method capable of generating solutions for diverse geometries, given that solutions obeying the given criteria exist. Furthermore, while extending from the CAD environment and extracting useful welding information, the presented method incorporates feature recognition to automatically extract potential welds and useful weld-related information in the CAD environment to classify and generate robot welding programs [22].

3 Approach

This section describes the underlying approach to drive the automatic generation of rule-adhering robot welding programs from CAD. The general idea is that an autonomous CAD-to-robot program generation can be enabled in the CAD environment by utilising available APIs, similar to [16,17,18]. However, in addition to extracting and transferring weld information throughout the program generation system, the proposed approach also layers topology analysis and feature recognition to this stage to automatically extract potential welds and useful information for both program generation and classification down the line [22]. These welds are then transferred to a manufacturing simulation environment, where several proposed algorithms are used to generate collision-free, singularity-free, and rule-adhering robot welding programs. Figure 1 depicts the proposed approach’s overall steps and information flow, starting from a CAD model and resulting in so-called generalised program tasks. These generalised program tasks contain information about collision-free and allowed welding operations and the corresponding classifications, which can be used to determine appropriate welding parameters or procedures. The idea is that a local robot controller can be used as a final parser to generate updated trajectories based on these generalised tasks in combination with other specialised scanning-driven welding policies. The depicted system consists mainly of five essential steps for the program generation:

  1. 1.

    CAD-integrated feature recognition to detect all the potential weld paths in the CAD environment. Tessellated geometry is generated as part of the process for analysis and use in collision models in the CAM environment.

  2. 2.

    Topological analysis of scanning of potential welds to extract local wall vectors and calculation of welding faces and initial approach vectors for the welding gun.

  3. 3.

    Transfer weld package and collision models to the CAM environment and determine the transformation offset of the workpiece relative to the robot manufacturing setup.

  4. 4.

    Classify welds for the potential welding operations depending on workpiece orientation and welding directions.

  5. 5.

    Generate generalised welding tasks with classified requirement-adhering welds.

Fig. 1
figure 1

Approach overview, where the blue boxes represent digital information flow as the CAD data moves to generalised program tasks, and the orange boxes represent physical systems

The program generation approach proposed in this paper was developed using the CAD software Siemens NX along with the NXOpen Python API, which allows CAD functions to be accessed programmatically. Using the NXOpen API also allowed for the seamless transfer of information between the different systems, as client-server relationships could be deployed. Peter Corke’s Robotics Toolbox Python was used to simulate the manufacturing environment and generate robot trajectories [23]. Currently, the robotics toolbox implements basic collision handling from PyBullet [24]. However, meshes are only represented by their convex hull. As such, all models, or assemblies, were decomposed into parts and further decomposed into convex hull approximations with the open-source library Volumetric-Hierarchical Approximate Convex Decomposition (V-HACD) [25]. By using this approach, the final collision boundaries can be seen in Fig. 2, along with the unprocessed convex hull and original mesh. Each convex hull is represented as a different colour. The rationale for the initial part decomposition is due to the potential artefacts that V-HACD, in some cases, can introduce to the collision model [26], as can be seen in Fig. 2c. In the case of plate geometry, the decomposition into separate parts prior to V-HACD seemed more stable and avoided creating these artefacts. The browser-based visualisation module Swift offered by the robotics toolbox, was used to visualise the robot environment. By modifying the module to allow sockets over the web and integrating with the Python Flask module [27], a web-based simulation service for the manufacturing environment was deployed.

Fig. 2
figure 2

Original mesh and collision models. Each colour represents a separate convex shape

3.1 Topological extraction of relevant welding information

The robot program generation method used in this paper requires base information about the welds and local path topology to function in addition to the robot and manufacturing specifications. This local path topology comprises the welding points that constitute the lines or discretised to curve shapes, making up the welding operation. In addition, each point contains information about the directions of the walls closest to the weld (local walls). The local wall vectors are essentially the normal vectors of the faces intersecting with the weld but are easier to discretise for more complex shapes such as rounded surfaces. By knowing these, an initial approach vector can be calculated for the welding tool, allowing the sampling method to determine feasible robot welding operations. The extraction of local wall vectors is necessary in order to determine the face of the weld in cases where this is not defined manually in CAD. The main steps of the topological extraction are summarised as follows:

  1. 1.

    Collect intersection lines occurring between solid body elements in the CAD environment.

  2. 2.

    Segment solid body intersection lines that intersect with each other into separate lines.

  3. 3.

    Perform multi-directional slicing to obtain cross-sections for all potential welds.

  4. 4.

    Filter out welds that are assumed to be not accessible based on the angle of visibility from the weld face in the cross-section.

  5. 5.

    Calculate the local wall vectors and accurate groove angles.

Figure 3 depicts the underlying vector and angle definitions used to generate the welding procedures. The wall vectors denoted as \(\hat {\textbf {n}}_{1}\) and \(\hat {\textbf {n}}_{2}\), which is used to calculate an initial approach vector \(\hat {\textbf {a}}\), are shown in Fig. 3a. In certain cases, the weld gun needs to be shifted towards either wall to accommodate collision-free trajectories or in the welding direction \(\hat {\textbf {d}}_{w}\) to allow proper material fusion. These angles are shown in Fig. 3b and are defined as stick angle Rs and drag angle Rd. It should be noted that the local wall vectors are sensitive to features such as chamfers and fillets, as they are derived from tessellated models.

Fig. 3
figure 3

Definition of welding parameters and vectors. Welding axis γa, and welding face γf

The bisector of \(\hat {\textbf {n}}_{1}\) and \(\hat {\textbf {n}}_{2}\) is calculated simply as:

$$ \hat{\textbf{a}}_{\text{init}} = \hat{\textbf{n}}_{1} + \hat{\textbf{n}}_{2} $$

Shifting of the approach angle by the work- and stick-angles αs and αw can then be done with the following equation:

$$ \hat{\textbf{a}}_{d} = \cos(\alpha_{d}) \hat{\textbf{d}}_{w} + \sin(\alpha_{d}) \hat{\textbf{a}}_{\text{init}} $$

where \(\hat {\textbf {d}}_{w}\) is the welding direction and \(\hat {\textbf {a}}_{\text {init}}\) is the initial approach angle based on the bisector. Finally, the final approach vector \(\hat {\textbf {a}}_{d,s}\) with added rotation around the welding direction can be calculated with Rodrigues’ rotation equation as:

$$ \begin{array}{@{}rcl@{}} \hat{\textbf{a}}_{d,s} &=& \cos(\alpha_{w})\hat{\textbf{a}}_{d} + \sin(\alpha_{w}) (\hat{\textbf{d}}_{w} \times \hat{\textbf{a}}_{d}) \\ &\quad+&(1-\cos(\alpha_{w}))(\hat{\textbf{d}}_{w} \hat{\textbf{a}}_{d})\hat{\textbf{d}}_{w} \end{array} $$

The automatic extraction of the local wall vectors is a crucial element for the presented approach to obtain the initial approach vector and, consequently, the automatic program generation. To extract the local wall vectors, the weld cross-sections have to be generated through a multi-directional slicer [22]. In this paper, the multi-directional slicing is done using Eq. 4, which is simply a plane equation corresponding to the slicing plane of interest, where the slicing planes are defined using an arbitrary point p on the potential welds along with the welding direction \(\overrightarrow {\textbf {n}}\) with their subsequent coordinate point values in x, y, and z. Variable vi corresponds to one of three vertex points making up each triangle in the model. This is calculated for each vertex point making up the 3D tessellated assembly model:

$$ \begin{array}{@{}rcl@{}} Q_{i} &=&\overrightarrow{\textbf{n}}_{x}(\textbf{p}_{x}-v_{i, x})+\overrightarrow{\textbf{n}}_{y}(\textbf{p}_{y}-v_{i, y}) \\ && +\overrightarrow{\textbf{n}}_{z}(\textbf{p}_{z}-v_{i, z}) \end{array} $$

Six possible states are defined to determine whether a vertex intersects with the slicing planes. Three of these states occur when two vertex points of a triangle are located on each side of the plane. This corresponds to the Q variable being positive for one and negative for the other. This is illustrated in Fig. 4, with v0 and v1 being on opposite sides, as well as v2 and v1. The remaining three cases occur when one triangle vertex point is located precisely on the plane. In these cases, Q is equal to zero.

Fig. 4
figure 4

Arbitrary slicing plane [22]

Finally, local wall vectors in CAD can be extracted from the cross-sections with Algorithm 1. The algorithm works by assuming that there are three possible scenarios where a local wall vector is connected to the weld. The first two scenarios occur when a given line pair consisting of 3-dimensional points pa and pb on the cross-section plane contains a point that occurs close to the weld path. A given tolerance, γt, should be defined for models that contain tolerance gaps in the model. The third scenario is where the corresponding line passes through or is close enough to the welding path. As the correct directions of the wall vectors relative to the weld are still uncertain, they have to be checked in a second loop. This is done by calculating the bisector and performing a point-in-polygon check, eliminating the inward pointing vectors. The bisectors with the corresponding wall vector set that occur outside a polygon can be assumed to be the correct solution.

Algorithm 1
figure a

Cross-section scanning of local wall vectors \(\hat {\textbf {n}}_{1}\) and \(\hat {\textbf {n}}_{2}\).

Figure 5 shows the automatically extracted wall vectors \(\hat {\textbf {n}}_{1}\) and \(\hat {\textbf {n}}_{2}\) in blue and corresponding bisectors \(\hat {\textbf {a}}_{i}\) in yellow, scanned iteratively throughout the welds of a part assembly.

Fig. 5
figure 5

Visualisation of wall vectors (blue) and initial approach vectors (yellow) automatically scanned and generated from CAD

3.2 Classification and requirement adherence for welding operations

The classification of welding operations is used to determine whether the operation is suitable for the given material or if approved welding parameters exist. This is necessary to ensure that only valid operations are produced, meeting defined requirements and proper fusion. Additionally, the classification of operations also allows methods such as KBE to be implemented for rule-based reasoning.

The classification of the welds is done with respect to so-called welding positions, of which standards and procedures have already been established. These welding positions can be defined by applying minimum and maximum ranges to two parameters used to characterise welds: the angle ϕg, defined as the angle between the welding face \(\hat {\textbf {u}}_{b}\), and the gravity vector G, and the angle ϕw, defined as the angle between the welding direction \(\hat {\textbf {u}}_{w}\) and between the welding face \(\hat {\textbf {u}}_{b}\), and gravitational vector G, around the welding direction \(\hat {\textbf {u}}_{w}\). The representation of vectors and angles used to define welding positions can be seen depicted in Fig. 6.

Fig. 6
figure 6

Vectors for defining welding positions and operations. Welding axis \(\hat {\textbf {u}}_{w}\), and welding face \(\hat {\textbf {u}}_{b}\)

The weld direction to gravity angle ϕg can be calculated with the following equation:

$$ \phi_{g} = \cos^{-1}{\left( \frac{v_{w} \cdot G}{\mid v_{w} \mid \mid G \mid }\right)} $$

where vw is the welding direction vector, and G is defined as gravity vector of the given manufacturing environment. The relative weld face vector \(\hat {\textbf {u}}_{b}\) to gravity G around the welding direction \(\hat {\textbf {u}}_{w}\), ϕw can then be calculated as:

$$ \phi_{w} = \text{atan2} (u_{b} \cdot G, v_{w} \cdot (u_{b} \times G)) $$

Using these angles, the welding operations in the manufacturing environment can then be automatically classified with Algorithm 2.

Algorithm 2
figure b

Classification of welding operations.

Welding positions are a set of predefined welding configurations based on relative weld slope angles as well as the orientation of the weld face relative to a horizontal plane, of which standardised procedures can be developed. The classification is calculated based on the assumption that parameters Rw and Rg are sufficient for defining all types of welding operations in a relevant manner. Rg is the welding direction for the weld in relation to gravity g = [0,0,1].

Each lreq in Lreqs consists of limit values \(\phi _{\min \limits }\) and \(\phi _{\max \limits }\) for both ϕw and ϕg. If the corresponding values of ϕw and ϕg are found to be within the definition of a classification, it is subsequently added to the weld operation object. It is important to note that it is possible to obtain several classifications for a single operation depending on the chosen values.

3.3 Generation of robot welding programs

The generation of the robot welding programs is based on selecting potential poses, trajectories, and operations that comply with requirements. As such, the program generation has to make sure that the selected solutions are possible with respect to the manufacturing cell configuration, i.e., joint limits, singularities, and collisions. Additionally, the generated welding operations have to comply with the restrictions defined by the expert system, meaning that only classifications approved for the given context are allowed, as elaborated in Section 3.2.

Applying these restrictions, a greedy search algorithm is used to sample through a discretised weld task space, using the initial approach vector \(\hat {\textbf {a}}_{\text {init}}\). The calculation of potential weld tool positions and orientations used for the discretised welding tool space sampling is done with Algorithm 3 using the equations described in Section 3.

Algorithm 3
figure c

Calculation of discretised tool positions along the weld.

The greedy search can then be defined with Algorithm 4, where the aim is to create a list of homogeneous transformation matrices T (SE3). These can be defined with a point in 3D \(\hat {\textbf {p}}\) and robot weld tool frame vectors \(\hat {\textbf {a}}\), \(\hat {\textbf {n}}\), \(\hat {\textbf {o}}\), which are depicted with respect to the robot in Fig. 7. The normal vector \(\hat {\textbf {n}}\) is simply defined as the perpendicular \(\hat {\textbf {a}} \times \hat {\textbf {o}} = \hat {\textbf {n}}\). Additionally, robot poses q, and corresponding movement types and operations are included, resulting in a complete welding operation when interpreted by a local robot controller.

Algorithm 4
figure d

Generation of welding operations.

Fig. 7
figure 7

Robot coordinate frame definitions. Local robot coordinate frame, tool frame definitions (from welding tip): approach vector \(\hat {\textbf {a}}\), orientation vector \(\hat {\textbf {o}}\) (reversed in depiction), and normal vector \(\hat {\textbf {n}}\)

Essentially, the algorithm generates a discretised space of parameters that allows for calculating all the relevant robot poses throughout the welding operations. All that is left is to explore the solutions for each weld and check whether they comply with the manufacturing restrictions through a for-loop. The ValidatePose procedure is described in Algorithm 5. The algorithm loops through all the collision objects deemed relevant to the manufacturing, such as the part assembly decomposed convex hulls and simplified dummy shapes of surrounding structures. As the system is built around the robotics toolbox open-source library, the corresponding potential robot poses are calculated using a SciPy stiffness cost-minimiser function ikine_min [23]. Additionally, by setting the qlim flag to True, robot joint limitations can be considered. The final connecting movement motions can then be solved using PRM and RRT as outlined in Section 2.

Algorithm 5
figure e

Validation of given poses.

The ikine_min function will return false if no solution is found within the minimiser limits. The final generalised program output of the robot program generation contains the following elements:

  • Movement type

  • Movement speed

  • Target transformation, T

  • Target robot pose, q

  • Arc control.

where the movement type provides information about whether the robot movement should be considered a straight line in Cartesian space or joint space. Movement speed determines the robot’s motion speed. This information, along with the transformation target T and pose q, is used by the robot controller to generate the corresponding trajectories. Finally, the arc control activates the welding torch and weld source program.

4 Implementation

In order to assess the viability and characteristics of the presented approach, the assemblies depicted in Fig. 8 were used as subjects for the program generation. The models were provided by industrial partners in the Norwegian maritime industry based on real aluminium use cases currently manufactured with manual welding.

Fig. 8
figure 8

Implementation assemblies: helideck aluminium nodes (a) configuration A, (b) configuration B, (c) configuration C, and (d) aluminium assembly stiffener representation

4.1 Experimental setup

The presented automatic program generation method was implemented into a Siemens NX CAD environment using the Siemens NXOpen Python API. The offline programming environment, or manufacturing simulation server, was developed using the robotics toolbox for Python along with the Python Flask server module, elaborated in Section 3. The simulation manufacturing environment depicted in Fig. 1 was modelled based on one of the welding cells available at Manulab NTNU shown in Fig. 9. The cell consists of a Yaskawa Motoman GP25 equipped with a Fronius WF60I Robacta Drive CMT welding torch along with an MT1-500 positioner table. The joint kinematics between the robot welding arm and positioner was not considered for the scope of this paper. Instead, a set of pre-selected orientations for the positioner and part was used. Adding this functionality should not affect the results developed in this paper but rather result in faster and more efficient programs.

Fig. 9
figure 9

The robot cell comprising a Yaskawa Motoman GP25 robot manipulator and a MT1-500 workpiece positioner

4.2 Welding program generation requirements

In addition to collision-free and singularity-free robot operations, the welding specifications are also part of the program generation. Based on the ISO6947:2019 standard, the allowed welding operations used for the implementation were set to PA, PB, PD, and PF to ensure the proper fusion of the aluminium joints. The allowed deviations from the work angle αw were ± 5, and a stick angle αs of 15 (optimal) to 40.

4.2.1 Results

Table 1 tabulates the number of successful welding operations generated based on the four models comprised of three different helideck node configurations and a stiffener representation, shown in Fig. 8. The table contains the total number of parts along with successfully generated welds versus the total number of located existing welds. The final column shows the total time taken for the generation. As will be elaborated in Section 5, the system is capable of generating rule-adhering programs for all welds, given that a solution exists for the defined criteria. For the helideck nodes, which require manual repositioning in actual production, several welds did not have solutions with the static fixture.

Table 1 Program generation for the implementation assemblies depicted in Fig. 8

5 Discussion

As seen in Section 4, the system was able to generate generalised programs for all of the models provided, which contained different geometries with varying complexity. The experimental results using the assemblies depicted in Fig. 8 are tabulated in Table 1. The generated programs contained collision-free motions between a sequence of welds, where each weld had been characterised and classified based on the given weld topology and part orientation. While the presented approach was able to generate programs for each of the parts presented, the weld programs for the helideck nodes, Fig. 8a, b, and c do not contain valid welding operations for all of the possible welds, as simply no solutions adhering to the given rules existed for the given experimental setup shown in Fig. 9. These parts currently require repositioning several times in actual production with human welders in order to reach all the welds while obeying the specified allowed welding positions. However, the most problematic spots for the program generation were the holes in the structural corner plates bridging the main plates together, which contain welds on the inside, as shown in Fig. 10. From the experiments, it can be observed that the geometrical constraints of the holes lead to a loss of four welds for node A and eight welds for nodes B and C. One way to mitigate this issue could be by accommodating robotic welding accessibility at the design phase of the nodes in future design iterations. In essence, when excluding prohibited welding operations and other generation criteria, the system is capable of finding all solutions. The remaining welds could be accommodated by improving the weldability of the part in terms of design, modifying the manufacturing cell, or changing the criteria.

Fig. 10
figure 10

Inaccessible welds located in holes (marked in red) with given restrictions and setup

Another observation based on the results in Table 1 is that the generation speed for the programs performs relatively slow when compared to earlier implementations such as Larkin et al. [7]. The probable cause of this is attributed to the lower efficiency of the code used in the pose validation shown in Algorithm 5, which handles the generation of robot joint poses as well as checks for singularities, joint limits, and collisions. In theory, improving this aspect could improve the generation time significantly. However, to focus on the rule-adhering aspects of the automatic weld generation, this aspect was left to be studied in further work.

An important note is that the presented welding program generation method in its current state does not consider the joint kinematics between the robot arm and positioner table. Instead, predetermined positions of the robot table based on experience were used for the algorithms. This was left to be studied in future works in order to focus on the rule-adhering aspects of the program generation.

The system presented in this paper mainly focuses on generating generalised robot programs consisting of base-level information so that a local robot control parser can incorporate it into different systems. Transitioning into fully automatic systems requires including a robot sensor system, such as a vision system, to account for the inaccuracies of real-world conditions. Additionally, an intelligent vision system for application during welding could compensate for material heat deformation and improve multi-pass welding quality. Such implementations have been proposed in Bedaka, Vidal, and Lin [28], and Rider-Marco et al. [29].

Additionally, as mentioned in Section 3, prior to program generation, a pre-calibration step should be performed. This ensures that the discrepancy between the generated program and the actual setup is manageable for the down-the-line adjustment and sensing systems. When adjusting this discrepancy, if too large, the local robot controller may run into joint limits or singularities if following the program targets blindly. However, it is possible to automate this step using vision-based sensing systems for initial part localisation, such as 3D cameras. The authors used a simple four-point measurement in the experiments to determine the offset transformation.

6 Conclusion

A framework and approach for generating rule-adhering robot welding programs from CAD aimed at products with varying geometries have been developed and presented. The aim of generating the rule adherence of welding programs is to ensure that the system output of the CAD to program generator corresponds to viable welding operations that can be used for critical structures. In order to evaluate the system performance, three geometrically different node configurations and a stiffener piece provided by industrial collaborators were used as input, along with allowable welding orientations and operations. For the more complex node configurations (which require reorientation when welded manually), 32 weld path programs out of 42 were generated based on the given criteria and boundaries. For the least complex node, 20 out of 24 welds were generated with the same criteria. All 14 weld programs were successfully generated for the stiffener representation. The incomplete results for some node configurations are attributed to the non-existence of solutions given the allowed operations, manufacturing cell setup, and the geometry of the part itself. Thus, the proposed system can correctly generate programs adhering to allowed welding operations as long as a solution exists.