Self-Organization and Self-Coordination in Welding Automation with Collaborating Teams of Industrial Robots

Transcription

1 maches Article Self-Organization Self-Coordation Weldg Automation with Collaboratg Teams Industrial Robots Günr Starke *, Daniel Hahn, Diana G. Pedroza Yanez Luz M. Ugalde Leal APS GmbH European Centre for Mechatronics, Vaalser Str. 460, Aachen, Germany; (D.H.); (D.G.P.Y.); (L.M.U.L.) * Correspondence: starke@aps-mechatronik.de; Tel.: Academic Editor: Robert Park Received: 31 August 2016; Accepted: 24 November 2016; Published: 30 November 2016 Abstract: In weldg automation, growg terest can be recognized applyg teams dustrial robots to perform manufacturg processes through collaboration. Although robot teamwork can crease pritability cost-effectiveness production, programmg robots is still a problem. It is extremely time consumg requires special expertise synchronizg activities robots to avoid any collision. Therefore, a research project has been itiated to solve those problems. This paper will present strategies, concepts, research results applyg robot operatg system (ROS) ROS-based solutions to overcome existg technical deficits through tegration self-organization capabilities, autonomous path, self-coordation robots work. The new approach should contribute to improvg application robot teamwork collaboration manufacturg sector at a higher level flexibility reduced need for human tervention. Keywords: dustrial robots; collaboration; autonomy; self-organization; trajectory ; collision avoidance; ROS-based control; simulation 1. Introduction The application dustrial robots automated weldg processes is well established with creasg numbers robot sales worldwide year by year [1]. To rema competitive this growg market to meet customer dems, all robot manufacturers vest a lot efforts to improve performance ir products. This will be achieved, particular, through technical novation, an crease functionality, better reliability. In this context, for a number years novel automation concepts have entered focus terest. They are based on production cells with multiple dustrial robots advanced control concepts that allow robots to share a common work space to execute manufacturg processes through collaboration. The reasons applyg teams collaboratg robots manufacturg are manifold. Benefits are especially obvious case complex weldg jobs that are difficult, efficient, or uneconomic to be completed by only one sgle robot. Therefore, if applicable, robot teamwork can contribute to crease pritability, efficiency, cost-effectiveness production automation [2]. Currently, most multi-robot stations beg stalled or fered on market are built from robots same type or a product family. This is because dividual concepts developed by robot manufactures to assure controlled teraction collaborative activities. Very common are master-slave concepts to support complex time-consumg programmg procedures through specially-tailored proprietary stware functions. Notable examples this Maches 2016, 4, 23; doi: /maches

2 Maches 2016, 4, context are for stance MultiMove function ABB, Independent/Coordated function Motoman Yaskawa, or RoboTeam function launched by KUKA [3 5]. In parallel to product development robot manufacturers, extensive scientific-driven research has also given birth to numerous novel technologies robotics through last decades. This has led to considerable functional improvement, creased applicability, better performance robot systems. In this context multi-robot technology has also been subject research technological development. Meanwhile, many valuable results, dependent on specific settgs applications, are available. They provide a useful platform technologies stware tools for furr robotic development, especially for multi-robot applications [6,7]. In particular, open source products with free access to already-existg technological achievements, for stance fields motion, collision avoidance, environmental perception, localization, searchg, mappg, are creasgly applied by developers deployg new system designs advanced robotic technology [8,9]. However, it must be recognized that most results gaed from research this sector have been dedicated to applications mobile systems or teams mobile robots beg volved coordated actions at different degrees system autonomy. Well known this context are results research itiatives field RoboCup Soccer RoboCup Rescue, where a contuously-growg community scientists researchers has created a wide platform for research, technological development, competition, exchange multiple technical technological solutions [10 12]. Less considered, compared to worldwide research itiatives field mobile robots, is development advanced technologies autonomy for multi-robot applications dustrial production environments. This is especially true field arc weldg automation. The reason for this are technical technological complexities because, here, coordation cooperation are concerned not only with how to control movement robots side team, but also how to distribute workload between robots a way which assures maximum economic efficiency team performance how to cope with conditions restrictions caused by weldg process itself. Motoman Yaskawa pioneered multi-robot technology for arc weldg applications 1994 became a market leader this sector. However, applicability ir technology is restricted allows design setup collaboratg multi-robot stations only with Motoman products (robots controllers) only for certa applications weldg automation [13]. Despite this progress, collaborative weldg automation with multi robot technology remas complex many technical problems issues are still unsolved. One se issues, for stance, is related to question how to proceed if collaboration with a team heterogeneous dustrial robots with totally different control devices shall be implemented to reach certa economical goals production. In this case technical realization mostly fails because extensive efforts necessary for programmg, lackg teroperability, sufficient control teraction concepts. Therefore, view this situation, research project presented this paper has been itiated to vestigate problems multi-robot applications more detail to propose basic technical solutions which shall contribute to overcomg still-existg problems to assure more flexibility applyg multi-robot technology production environments with arc weldg automation by means advanced control concepts tegration a certa degree autonomy to existg systems. To enter any research related to this topic, a couple aspects questions particular relevance have to be addressed first order to provide a certa basele for project work: How does one generate a neutral job description that will specify activities to be executed by robots? How does one apply job description for action self organization robot team work? How does one implement autonomy terms path self-coordation? How does one assure collision-free motion robots side a common work space?

3 Maches 2016, 4, How does one create design an appropriate communication, teraction, control frastructure? 2. XML-Based Job Description Fundamental to any action controlled teraction for multi-robot systems is a detailed description production job to be executed by robots. Typically, specification robot activities is part operator s work durg explicit programmg each dividual robot synchronizg ir teraction to avoid any collisions. To replace so called teach- programmg which is, as already said, complex ten very time consumg, scripted solutions, such as Petri Nets, icon-based programmg, or or scripts have been favored. With project an XML-based job description was proposed. It is both human mache readable, can be applied platform-dependently, is able to provide all formation path data to assure proper coordation robot activities by computers. For robotized weldg this job description has to consider not only geometrical, but also technological, data. Both need to be complemented by structions to also control peripheral devices, if needed. The geometrical data job description typically represent spatial positions weld les, end-effector orientations durg weldg, also pots 3D workspace which need to be used by robots for safety reasons home positiong. Additionally, technological data have to specify Maches process 2016, conditions, 4, 23 like weldg speed, weld gun orientation, stick-out wire 3 electrode, 23 or weavg torch. Fally, data have to be considered to defe power source wire How does one assure collision-free motion robots side a common work space? feeder conditions, How does as well one create as weldg design position, an appropriate like horizontal, communication, vertical up, teraction, overhead, vertical control down, or weldg frastructure? gravity-affectg positions. The generation job description project was performed by means a specially-designed stware tool. It has cluded an editor, graphical user terfaces, 2. XML-Based a set Job functions Description to create XML files teractively by user. The semantics beg applied are Fundamental related to ternational to any stards action weldg controlled engeerg teraction for (ENmulti-robot ISO 15611, systems 15614). is a Figure 1 shows adetailed series description structions production data taken job to from be executed a typical by XML-based robots. Typically, job description specification that has been robot activities is part operator s work durg explicit programmg each dividual robot created with project. synchronizg ir teraction to avoid any collisions. <?xml version="1.0" encodg="utf-8"?> <!-- name workpiece, xml file will be named "wp_example.wdf" --> <workpiece name="wpexample"> <geometry> <!-- mesh contag geometry on workpiece --> <mesh filename="file:/path/wp_name.stl"/> </geometry> <!-- parameters file --> <parameters filename="file:/path/param_example.dat"/> <jobs> <job name="job1"> <!-- weldg parameters --> <weldparam>par01</weldparam> <trajectory> <!-- defg weld seam startg pot --> <!-- only x, y z coordates are cluded --> <!-- orientation will be calculate by planner --> <startpot> <x>0</x> <y>0</y> <z>1000</z> </startpot> <!-- weldg parameters --> <weldparam>par01</weldparam> <lear> <endpot> <x>0</x> <y>200</y> <z>1000</z> </endpot> </lear> <!-- circular seam segment through auxpot to endpot --> <circular> <!-- weldg parameters for this seam --> <weldparam>par01</weldparam> <auxpot> <x>100</x> <y>300</y> <z>1000</z> Figure XML-based job description. To replace so called teach- programmg which is, as already said, complex ten very time consumg, scripted solutions, such as Petri Nets, icon-based programmg, or or scripts have been favored. With project an XML-based job description was proposed. It is both human mache readable, can be applied platform-dependently, is able to provide all formation path data to assure proper coordation robot activities by

4 Maches 2016, 4, In this context, all XML descriptions beg applied project only address movement a tool, for stance a weld gun, to execute a manufacturg job. Instructions or formation related to any robot or kematic structure robots are not considered. Therefore, XML job descriptions are very flexible ir use can be adapted to any robot or weldg mache if an appropriate post-processor is available. 3. Planng Self-Organization Robot Team Work As mentioned before, goal this research was to enable teams robots to organize, plan, coordate ir work autonomously without any tervention human operator. To meet this goal, it was decided not to start from scratch by developg new tools, but to use services robot operatg system (ROS) as an open source framework to apply ROS functions like MoveIt! for motion, verse kematic calculations, collision checks, to control any teraction robots, even if y are a heterogeneous nature [14]. The first activity to implement was a solution to decode XML job description. For this purpose, a ROS node has been created with use library roscpp TyXML. With an tegrated parser node had to extract position data weldles, as well as correspondg process parameters, to load m to an action list. After coordate transformations position data from workpiece coordates to world coordates robot cell, generated action list served as a database for any furr activity. From practical pot view, any robot activity weldg automation has to consider, prciple, two stard application scenarios importance for concept envisaged: 1. Planng robot actions beg executed a static workg environment at a defed spatial position orientation workpiece; or 2. Planng robot actions beg executed a contuously changg workg environment. This will happen, for stance, case varyg workpiece positions frequent reorientation part to be welded by means an tegrated multi-axis workpiece positioner Self-Organization Robot Collaboration Static Workg Environments Although any action for robots volved team needs to be adapted to type application scenario, re is anor important aspect to consider. It is related to economic goals. In this context distribution activities side team robots, which has to assure mimal job execution times, is addressed. Thus, motion self-organization also have to cope with an optimization problem balancg work load side team. In order to cope with this kd optimization problem, self-organization algorithms have been developed implemented. They were designed to consider different application scenarios to allow determation distribution activities real-time by followg certa optimization criteria. In this project y were related to rule mimum path lengths. For a static workg environment, algorithms used a set matrices (n + 2) (n + 2) elements, one for each robot team, where (n) represents total number les to be welded. The extension by two additional matrix elements was necessary to consider robot movements from ir home positions at begng any job execution, return to home position after havg falized last weldg job. Inside matrix itself, each element P i,k with i = 1,..., n + 2 (column dex) k = 1,..., n + 2 (le dex) contas a time factor seconds. This factor eir dicates estimated traversal time robot (based on Euclidian distances) when movg from its current position to a target position side workg space. Or, case matrix elements located on ma diagonal, factors represent time weldg jot beg addressed through position dices matrix element. For stance P 2,2 dicates weldg time for jot 1, P 3,3 for jot 2, etc.

5 Maches 2016, 4, Maches 2016, 4, factors represent time weldg jot beg addressed through position dices matrix element. For stance P2,2 dicates weldg time for jot 1, P3,3 for jot 2, etc. Accordg to to example presented Figure Figure 2 2 calculation calculation starts starts at element at element P1,1 (home P 1,1 (home position) position) contues contues searchg searchg nearest target nearest position target for position robot for to go next. robot This toposition go next. is This found position by evaluation is found all bytime evaluation factors all matrix time factors elements column matrixdex elements i = 1, respective column dex i elements = 1, respective P1,2 up to P1,n+2. elements The matrix P 1,2 upelement to P 1,n+2 found. The matrix with element lowest found time with factor determes lowest time factor le determes dex k which has leto dex be used k which to identify has to be used position to identify robot position to go next. robot By settg to godex next. By i equal settg k, dex correspondg i equal k, matrix correspondg element Pi,k matrix = Pk,k element on ma P i,k = diagonal P k,k is addressed. ma diagonal This represents is addressed. This weldg represents time (20 s) for weldg jot time to (20 be welded s) for next. jot Similar to be calculations welded next. were Similar related calculations to matrices were related dedicated to to matrices or dedicated robots to team. or Matrix robots elements team. beg Matrix used already elements beg a calculation used already cycle have a calculation to be neglected cycle have all to furr be neglected activities. all furr activities. Figure 2. Self-organization matrix with time data seconds (example). After After all all robots robots team team have have falized falized ir ir first first weldg weldg operations, operations, self-organization self-organization algorithm algorithm contued contued with with a a new new search search operation. operation. The The startg startg pot pot was was now now that that matrix matrix element element on on ma ma diagonal diagonal which which has been has been found found to identify to identify jot selected jot selected for weldg. for weldg. From this From matrix this position matrix position algorithm algorithm aga tried aga to tried fd to fd next lowest next lowest time factor time by factor checkg by checkg all elements all elements column with dex i = 2. As soon as lowest time factor (2 s) has been identified, a new le column with dex i = 2. As soon as lowest time factor (2 s) has been identified, a new le dex k dex k (k = 5) is found. This specifies matrix element on ma diagonal (P5,5) with time (k = 5) is found. This specifies matrix element on ma diagonal (P 5,5 ) with time factor factor (60 s) related to next jot selected for weldg. In this way all furr calculation cycles (60 s) related to next jot selected for weldg. In this way all furr calculation cycles have to be have to be performed, each with a column-wise search for lowest time factor, to fd new le performed, each with a column-wise search for lowest time factor, to fd new le dex k for dex k for next weld, followed by a le-wise identification matrix element Pi,k on next weld, followed by a le-wise identification matrix element P i,k on ma diagonal ma diagonal with i = k. This had to be performed for matrices all robots volved with i = k. This had to be performed for matrices all robots volved team. team. Durg this self-organization procedure correspondg time factors for each robot have been Durg this self-organization procedure correspondg time factors for each robot have accumulated cycle by cycle, so that actual duty time (time to go + time to weld) for each been accumulated cycle by cycle, so that actual duty time (time to go + time to weld) for each robots was always available could be monitored. robots was always available could be monitored. The duty time robots was special importance when approachg end calculation The duty time robots was special importance when approachg end optimization procedures. Normally number residual jots to be welded is eir: calculation optimization procedures. Normally number residual jots to be welded (i) less than number robots team; or is eir: (ii) equal to number robots team. (i) less than number robots team; or In case (i), self-organization algorithm had to distribute fal weldg tasks not (ii) equal to number robots team. only le with shortest path length criteria. It also had to care for a balanced workload In case (i), self-organization algorithm had to distribute fal weldg tasks not robots team, order to assure mimal job execution times. Therefore, priority weldg only le with shortest path length criteria. It also had to care for a balanced workload task distribution has preferably been given to those robots with shortest accumulated duty times. robots team, order to assure mimal job execution times. Therefore, priority weldg Any decision next action agreed or next action disagreed after each calculation cycle was taken by task distribution has preferably been given to those robots with shortest accumulated duty times. self-organization algorithms as follows: Any decision next action agreed or next action disagreed after each calculation cycle was taken by [Accumulated self-organization dutyalgorithms time as robot follows: so far + Residual time for welds still to do]/[number robots [Accumulated team] duty = time Estimated duty robot time so per far robot + Residual on average time for welds still to do] / [Number IF [Estimated robots duty team] time = Estimated per robotduty average] time per > robot [Actual on average accumulated duty time robot] THEN Decision: Next action agreed

6 Maches 2016, 4, Maches 2016, 4, IF [Estimated duty time per robot average] > [Actual accumulated duty time robot] THEN Decision: Next action agreed IF [Next action agreed] THEN [Calculation dividual Duty Rate DRi i robots] DRi i = [Estimated duty time per perrobot average]/[actual / accumulated duty time robot]; with i = (1,..., m); m = total number robots team Fal distribution weldg tasks to robots with shortest duty time: FOR I = 1 to to Number residual welds to do next X = Max {DR {DR1, 1, DR2,..., DRm 2 m } X identifies robot robot to to take take over over one one residual residual welds. welds. Delete DutyRate DRx = X from { } NEXT Self-Organization Dynamically-Changg Workg Environments As mentioned above, a second typical application scenario weldg automation represents stallations with robots tegrated workpiece positioners to enable a reorientation workpieces accordance to quality dems. Especially, turn tilt tables are ten applied to enable weldg horizontal or so called gravity positions (Figure 3). For high quality welds this position is essential importance because symmetrical heat heat put put to to base base material material optimal optimal weld weld pool pool behavior. behavior. Figure 3. Turn tilt table for weldg a gravity position. To run self-organization process with respect to dynamically-changg workg To run self-organization process with respect to dynamically-changg workg environments, environments, ROS based control system had to start aga extractg weldle positions ROS based control system had to start aga extractg weldle positions tool tool orientations from XML job description. After transformation to world coordate orientations from XML job description. After transformation to world coordate system system used by ROS MoveIt!, an action list has, aga, been prepared by MoveIt! as database used by ROS MoveIt!, an action list has, aga, been prepared by MoveIt! as database for for self-organization procedures. self-organization procedures. The organization work load distribution activities to robots volved The organization work load distribution activities to robots volved team team had to cope aga with shortest path length rule to assure mimal job execution times. had to cope aga with shortest path length rule to assure mimal job execution times. However, However, this time, not only robot movement was relevance, but also orientation this time, not only robot movement was relevance, but also orientation workpiece on workpiece on turn tilt table, position weldles side configuration space. turn tilt table, position weldles side configuration space. To consider se constrats efficiently, all welds to be executed have been split to two To consider se constrats efficiently, all welds to be executed have been split to two classes classes first. One class typically contaed all lear welds or one all circular welds. This first. One class typically contaed all lear welds or one all circular welds. This separation separation was necessary because different path concepts for robots when executg was necessary because different path concepts for robots when executg lear lear or circular welds combation with external axes turn tilt table. Figure gives or circular welds combation with external axes turn tilt table. Figure 4 gives an overview structure implemented self-organization algorithms. After loadg all an overview structure implemented self-organization algorithms. After loadg all weldle weldle positions process-related parameters from <ROS Param Server> durg an positions process-related parameters from <ROS Param Server> durg an <Initialization> phase, <Initialization> phase, a <Check job> sequence followed to separate types weldg tasks to a <Check job> sequence followed to separate types weldg tasks to two classes LIN two classes LIN CIRC welds. CIRC welds.

7 Maches 2016, 4, Maches 2016, 4, Figure 4. Self-organization algorithm implemented for collaborative robot weldg with external axes Figure 4. Self-organization algorithm implemented for collaborative robot weldg with external a turn tilt table. axes a turn tilt table. The algorithm starts with LIN class checks location orientation lear weldles workpiece fixed on turntable. In order to allow weldg a gravity position, table orientation had to to be be always a tilt a tilt position position 45, 45, as shown as shown Figure Figure 3. If one 3. If one lear lear weldles weldles from from LIN class LIN was class detected was detected weldg weldg a horizontal a horizontal (gravity) (gravity) position position was allowed, was allowed, MoveIt! took MoveIt! overtook responsibility over responsibility through through transfer transfer correspondg correspondg WeldStart position WeldStart position contued tocontued plan robot to plan motion robot <Move motion Robots>. <Move The Robots>. selected The robot selected to execute robot to execute weld weld this context this was context always was that always onethat withone with shortest shortest Euclidian Euclidian distance distance to weldle to weldle at time at time decision. decision. In our test application, typically two robots different types have been considered for collaboration. Therefore, self-organization algorithms Figure 4 clude two path- activities controlled by MoveIt!, one for an ABB (Västeras, Sweden) robot, one for a KUKA (Augsburg, Germany) robot (LBR). In case a weldle horizontal position from LIN class could not be found, table was commed to contue rotatg small angular steps until a weldle with an appropriate orientation was available. After all welds LIN class were falized, weldg jots from CIRC class followed. Aga, self-organization algorithm started to access CIRC class to check if current orientation one circular weldles fit to an orientation horizontal (gravity) position. The gravity position was was found found frame frame K 1 K1 turntable turntable if if length length WeldStart WeldStart position position vector vector K 1 is a maximum. K1 is a maximum. In this case, In this a circular case, a circular weldle weldle gravity gravity position position has been has found, been found, a robot a robot team needs team toneeds be determed to be determed for weldg for task weldg execution. task execution. The selection The selection criterion criterion was, aga, was, aga, shortest Euclidian shortest distance Euclidian to distance WeldStart to position. WeldStart As soon position. as As nearest soon as robot nearest was found, robot MoveIt! was took found, overmoveit! responsibility took over started responsibility verse kematic started calculations verse kematic to enable calculations robot to move to enable to WeldStart robot to position move through to put WeldStart correspondg position through jotput angles to correspondg motion controller. jot angles to motion controller. While turntable remaed a fixed a fixed position, control control pots pots P c on Pc on circular circular path path have have been been calculated. calculated. The reference The reference was awas locala coordate local coordate system system K c with Kc with WeldStart WeldStart position position as orig. as orig. The X c -axis The was Xc-axis defed was as defed direction as direction vector between vector WeldStart between WeldStart WeldEnd. ZWeldEnd. C was directed ZC was directed parallel to Zparallel 3 to table Z3 coordate table coordate system K 3 accordg system K3 to accordg Figure 5. to Figure 5.

8 Maches 2016, 4, Maches 2016, 4, Figure 5. Geometrical conditions robot turntable motionfor for circular welds a a gravity position. By means this this defition, control pots pots PPC(t) C could be calculated along circular weldle for any time t by: by: (c) (c) PPCx(t) = [(R s β(t))/s / α(t)] cos (α(t) + φm) φ M ) (1) (1) (c) (c) PPCy(t) = [(R s β(t))/s/ α(t)] s (α(t) + φm) φ M ) (2) (2) where: R = radius circular weldle; φm M = angle betweenxc X C und vector frompstart P START to to center pot pot M M circular path; path; β(t) = angle between vector M_Pc c vectorm_pstart; ; α(t) = angle between vector PPSTART_Pc c vector M_Pc. c. A coordate transformation was necessary to transform coordates PPc(t) c to coordate system K3 3 turntable: (3) (3) P(t) = c T3 P(t) = c T Pc(t) (3) 3 (c) P c (t) (3) Prior to weldg process a gravity position with simultaneous movement a robot turntable, Prior to an weldg angle δ needed process to be a gravity specified position as with angle simultaneous between movement radius vector ato robot (3) PSTART turntable, Y-Axis K3: an angle δ needed to be specified as angle between radius vector to (3) P START Y-Axis K 3 : s δ = (3) PSTARTx / r1 s δ = (3) P (4) STARTx /r 1 (4) cos cos δ δ = = (3) (3) PPSTARTy / r1 (5) /r 1 (5) r1 2 = (3) PSTARTx (3) PSTARTy 2 (6) r 2 1 = (3) P 2 STARTx + (3) 2 P STARTy (6) With knowledge angle table rotation Δδ per time terval Δt, any change With knowledge δ angle table rotation δ per time terval t, any change control positions (3) P(t) on circular weldle could be calculated while turntable rotates at an control positions angular speed ω: (3) P(t) on circular weldle could be calculated while turntable rotates at an angular speed ω: (3) (3) PPX(t) X = R s (δ + n Δδ) δ) (7) (7) (3) (3) PPY(t) Y = R cos (δ + n Δδ) δ) (8) (8) with: ω = Δδ / Δt. (9)

9 Maches 2016, 4, with: ω = δ/ t. (9) R 2 = (3) P x 2 + (3) P y 2 (10) n = 0, 1, 2,..., m. (11) After transformation from K 3 to world-coordate system K 0 by: (0) P(t) = 3 H 0 (3) P(t) (12) The weldg circular path a gravity position could be executed with a rotatg table. The rotational speed table has been determed by weld path length weldg speed specified XML-based job description. In case neir a lear weld nor a circular weld could be found gravity position on turntable, station control had to comm table to rotate by a certa angle (for stance: ±30 ) until new weldles from list could be found gravity position for weldg. As soon as weldgun has reached WeldEnd position, rotation turntable stopped weldg task was completed. The self-organization algorithms contued with Check Job (Figure 4) until all jots were welded. 4. Autonomous Collision Free Motion Planng As recognized from previous section, algorithms proposed for self-organization coordation work side robot team do not consider any trajectory to enable a proper collision-free execution weldg jobs beg assigned to each robots. Therefore, especially for traversal movements from one weldle to next, it was necessary to extend self-organization coordation functionality with appropriate resources for motion. As most efficient tool for this motion task ROS, we selected tegrated Open Motion Planng Library (OMPL) MoveIt! to provide collision-free paths [15]. From library motion algorithms provided by OMPL, samplg based methods have been favored for problem. Instead a detailed construction configuration space, samplg based methods explore C space by a samplg scheme. This means eir: pickg pots C space romly storg status robot at se pots as knot a search-tree, n creatg a roadmap (learng phase) to fd any shortest path between a given start target position (query phase), or, alternatively, usg a sequence rom sample-based motions on dynamically-feasible path elements to construct a search-tree to fd a collision-free path towards a target position. The motion methods beg used our project addressed two most efficient methods. One m was RRT connect (rapidly-explorg rom trees) that allows a fast bidirectional search a collision-free path (accelerated by factor 3 5 compared to stard uni-directional RRT) [16]. RRT is an algorithm that crementally grows a tree from samples drawn romly a 3D search space. As soon as a sample q r is drawn, a connection is attempted between q r nearest, already-existg state q c tree. If this connection is feasible represents a path free collision, q r results a new state tree. Normally, length new connection between q r q c is limited by a growth factor q. In case connection between q r q c is larger than this limit, a new state will be defed at maximum distance allowed. Thus, growth factor determes rate growg. Growg tree contues until a new q r has reached target position a collision-free path is found. It is obvious that cremental sample based path will take considerable time. To make calculations faster, RRT connect has been selected. Here, two trees, one from start position one from target position are growg towards each or. States two trees can be connected

10 Maches 2016, 4, through a path segment which fulfills shortest distance orem. In this way a collision-free path between start target positions for any robot motion can be found much more quickly than with stard RRT approach. However, both methods mostly converge to solutions that are far from optimal. The second path procedure beg applied project was BKPIECE (bidirectional kodynamic motion by terior-exterior cell exploration). This has been selected to also consider dynamic constrats robots [17], especially when URDF group node concept was used. The advantage BKPIECE is that dynamic behavior robots volved team are described by physical models simulation stead solvg equations motion. Furrmore, BKPIECE does not require state samplg metrics to evaluate distance between states, like RRT. It applies path on basis trees created by forward propagation motion. Rom motion state space is performed. The start motion is always related to state nodes already known search tree. Each search motion is limited by a fixed time terval (simulation step size) termediate states along each motion are generated at a fixed resolution (propagation step size). Based on se time frames, dynamics robot terms speed, acceleration, impact forces, friction, etc. durg motion is vestigated through physical simulation. If dynamic parameters are with allowed limits no collision with obstacles or self-collision is detected, n a new path segment search tree with a new node is established. To enable a fast search, exploration state space will be directed with high priority to areas which are covered less by nodes search tree. The calculation coverage is achieved by BKPIECE through discretization state space to grids with a fixed cell size. Envisaged are cells that conta only one new state node tree. To meet this goal cell size needs to be adapted by furr discretization levels until convention one node per cell is reached. Durg with discretization state space, re are two types cells to consider: exterior cells with less than 2n neighbor cells (n = dimension state space) contag projections search motion, terior cells with 2n neighbored cells covered by projections nodes from search motions. For robot manipulators spatial movement typically results a three-dimensional projection. Durg first phase path with BKPIECE, a significant number exterior cells will be created, while after a certa time many exterior cells change ir status to terior cells. To assure fast, as mentioned, BKPIECE will give priority to search operations areas with exterior cells order to cover entire state space as quickly as possible. This strategy will crease probability fdg a collision free path from start to target destation. Similar to RRT connect, BKPIECE fers furr advantages because search tree creation from two directions, from startg pot, as well as from target position. This will guarantee faster motion collision checks. Therefore, BKPIECE seems to be favorable especially for multi robot applications As procedures, prciple, consist romly-generated path elements or segments motion which allow a dynamically feasible movement robots, it might take a certa computation time a few seconds until a collision-free path is found. Similar to RRT connect, aga it is underled that, also with BKPIECE, path beg found is not an optimum. Sometimes it is too long or cludes redundant movement. Therefore, a path optimization is required which aims eir to mimize path length or travel time. In this context, project a lear shortcut optimization was applied achievg acceptable results. It is achieved by tryg to successively lk path nodes via straight les configuration space, test new path element to avoid any collision, replace old path by new one. After a few iteration cycles a simplified trajectory can be found (Figure 6).

11 Maches 2016, 4, Maches 2016, 4, Figure Figure Raw Raw trajectory trajectory after after lear lear shortcut shortcut optimization. optimization. At end process paths produced by OMPL are translated by MoveIt! to dynamically feasible trajectories. Each pot along trajectories beg found contas 3D position data world coordates end-effector orientations quaternion form. Therefore, to complete each cycle, verse kematics calculations have have to be to performed be end to end obta to obta jot positions jot positions robots robots match match desired desired poses. Dependg poses. Dependg on number on number attempts attempts fdg afdg dynamically-feasible a dynamically-feasible collision-free collision-free path, related path, to related numberto jots number dividual jots jot subdivisions dividual jot subdivisions robots volved robots team, volved computation team, requires computation some time. requires Therefore, some time. it is obvious Therefore, that it is obvious that cycle times willcycle havetimes an impact will have on an performance impact on performance team robots team executg robots weldg executg jobs through weldg collaboration. jobs through collaboration. A detailed study A detailed thistudy impact this impact subject is Section subject 7. Section ROS-based IT Infrastructure for Motion Planng Control. Based on on ROS ROS MoveIt! MoveIt! services services [18], [18], as well as aswell on as self-organization on self-organization functionality functionality described before, described an IT-frastructure before, an IT-frastructure has been designed has been designed implemented implemented to enable autonomous enable autonomous as well as platform-dependent as well as platform-dependent control control robot work order robot to work assure proper order to collaboration assure proper executg collaboration predefed executg weldgpredefed jobs. Figureweldg 7 illustrates jobs. Figure proposed 7 illustrates system architecture, proposed recognizg system MoveIt! architecture, as recognizg key module MoveIt! thisas frastructure. key module Furrmore, this frastructure. modules Furrmore, for self-organization modules for coordation self-organization robot coordation work, for terpretation robot work, predefed for terpretation job descriptions, predefed as well as for job terfacg descriptions, as ROS well environment as for terfacg with external ROS devices environment have been with designed external devices addedhave to enable been communication, designed added teraction, to enable communication, control with real teraction, robots, peripheral control devices, with real or even robots, with peripheral a robot simulation devices, or tool even like with GAZEBO a robot forsimulation monitorgtool like visualizg GAZEBO for teammonitorg activities. visualizg team To activities. save time avoid costs for additional hardware stware to adapt communication teraction To save mechanisms time avoid to realcosts physical for additional devices hardware safety requirements, stware priority to adapt with communication project has been teraction given tomechanisms simulation studies to real with physical GAZEBO. devices It provides safety a powerful requirements, simulation priority environment with for project ROShas applications been given [19]. to simulation studies with GAZEBO. It provides a powerful simulation environment for ROS applications [19].

12 Maches 2016, 4, Maches 2016, 4, Figure 7. IT frastructure for autonomous, self-organization, control collaboratg robots executg weldg jobs though teamwork. 6. Interaction between MoveIt! GAZEBO 6. Interaction between MoveIt! GAZEBO To enable any teroperability between ROS-based control platform Figure 7 GAZEBO, To enable ROS any as teroperability well as simulation between tool require ROS-based formation model control data platform robots, Figure turn7 tilt GAZEBO, table, ROS as well workg as environment. simulation tool Therefore, require aformation 3D model description model data ROS was robots, applied which turn was based tilt table, on URDF (unified workg robot environment. description format) Therefore, files. a 3D URDF model is an description XML-based ROS model was description. applied which Specifications was based related on URDF to (unified kematical robot structure, description geometrical format) files. dimensions URDF is an XML-based mechanical elements, model description. colors, mass moments Specifications ertia, related or or to kematical physical properties, structure, suchgeometrical as friction, dimensions or even boundg mechanical volumeselements, for collision colors, checks mass are moments part URDF. ertia, or or physical properties, such For as friction, project or even work, boundg two heterogeneous volumes for weldg collision robots checks different are part size URDF. kematic structure (ABBFor Irb 6640project KUKA work, LBR two IV), heterogeneous as well as a two-axis weldg turn robots tilt-table different have size been selected kematic structure modeled by (ABB device-oriented Irb 6640 URDF KUKA fileslbr to cope IV), with as well any application as a two-axis MoveIt!, turn astilt-table well have GAZEBO. been selected modeled by device-oriented URDF files to cope with any application MoveIt!, as well as Visualization GAZEBO. Control Simulation However, to assure visualization two robots, as well as turn tilt table Visualization simultaneously, it Control was necessary Simulation to combe dividual URDFs each device through groupg to just However, one file. to This assure is because visualization MoveIt! ROS two Master robots, Server, as well at its as current state turn development, tilt table simultaneously, can only work with was onenecessary URDF fileto at combe a time. dividual URDFs each device through groupg to The just groupg one file. This is dividual because URDF MoveIt! files robots ROS Master turnserver, tilt table at its could current be achieved state development, by use XML can only macro work concept with one supported URDF file by at ROS. a time. The macro files are dicated through attribute <xacro>. The Therefore, groupg <world.urdf.xacro> dividual URDF had been files used robots as a group nodeturn to support tilt 3Dtable visualization could be achieved all three by kematic use devices, XML with macro only concept one URDF supported file. Additionally, by ROS. The with macro regard files toare dicated weldg through job selected attribute to be executed <xacro>. Therefore, by team<world.urdf.xacro> robots, correspondg had been used workpiece as a group model node hasto tosupport also be 3D loaded visualization to URDF all three file kematic should devices, be attached with toonly one turnurdf tilt file. table Additionally, to completewith regard model to description weldg forjob MoveIt! selected to be executed by team robots, correspondg workpiece model has to Inalso order be to loaded also apply to <world.urdf.xacro> URDF file should GAZEBO, be attached some to additional turn GAZEBO-specific tilt table to complete tags, for model example description terms for material MoveIt! colors, collision specific data, ertial blocks, transmission parameters In order (lk to also actuators apply to <world.urdf.xacro> jots) had to be added. GAZEBO, some additional GAZEBO-specific tags, for example After this extension, terms material MoveIt! colors, was now collision able tospecific providedata, also ertial full blocks, configuration transmission package to parameters visualize any(lk activity actuators teraction to jots) had two to be robots added. turn tilt table model. This has been achieved by MoveIt! plug- RViz (ROS Visualizer) by GAZEBO simulator.

13 Maches 2016, 4, After this extension, MoveIt! was now able to provide also full configuration package to Maches 2016, 4, visualize any activity teraction two robots turn tilt table model. This has been achieved by MoveIt! plug- RViz (ROS Visualizer) by GAZEBO simulator. Neverless, full ROS tegration with GAZEBO will be be obtaed if if a controlled simulation robot teamwork is is available. Therefore, mechanisms need to to be specified on how to to control any activity robots table models GAZEBO through ROS messages, services, dynamic reconfiguration. For this purpose, a control terface node has been implemented. A Akey keyelement this this terface was was ROS ROS control control plug- plug- which which provides provides generic generic close-loop control, control, typically typically on on basis basis a PID a PID controller controller (Figure (Figure 8). Inputs 8). Inputs are arejot state jot data statefrom data fromencoders encoders robot s robot s actuators, actuators, waypots waypots generated generated by by trajectory trajectory planners planners MoveIt!. MoveIt!. As output, As output, jot jot position position data data have have been been selected. selected. They They are are used used as as feedback to to PID PIDcontroller to control any motion each dividual kematic device simulation scenario. Figure Structure a ROS controller. The The ROS controllers are able to execute jot-space trajectorieson ona agroup group jots jots addressed addressed by by each each robots robots by by positioner. positioner. In Inorder order to topass pass trajectory trajectorygoals goalsto to controllers, a a so-called jot trajectory action node had to be implemented as an action server. The server reports success if if trajectory goals are are fulfilled allows defition certa path goal tolerances, like like time time delays delays permitted permitted reachg reachg target target position, position, or path or positiong path positiong errors thaterrors are acceptable that are durg acceptable motion. durg motion. To To manage data data flow flow between action server ROS ROS controller, an an frastructure to to start/stop load/unload controllers has been provided by means a controller manager module. It It is is able to to control data data transfer towards GAZEBO can can also also connect MoveIt! to to real real physical robot robot systems, as as dicated Figures As As one one action server is is required per per ROS ROS controller, three action server nodes had had to to be be implemented MoveIt! configuration to to manage data data flow flow between followg entities: ABB jot trajectory action Arm Arm controller_abb; KUKA jot trajectory action Arm Arm controller_lbr; Table jot jot trajectory action action Axis Axis controller_table. controller_table. In In this way action was brought to to respective controllers ABB KUKA robots to to turn tilt table, which have been selected as as demonstration test stallation.

14 Maches 2016, 4, Maches 2016, 4, Action Interface Controller Manager waypot ROS Trajectory Action ABB Trajectory Controller ABB robot waypot ROS Trajectory Action V KUKA Trajectory Controller KUKA robot waypot ROS Trajectory Action Table Trajectory Controller Turn/Tilt-Table Figure 9. GAZEBO-ROS/MoveIt! controller frastructure. Figure 9. GAZEBO-ROS/MoveIt! controller frastructure. 7. Simulation 7. Simulation Robot Robot Collaboration Collaboration In order In order to start to start execution execution a weldg a weldg job job to simulate to simulate how how team team robots robots will organize will irorganize work, gaed ir work, from self-organization, gaed from self-organization, self-coordation, self-coordation, trajectory trajectory activities with MoveIt!, activities <roslaunch> with MoveIt!, tool <roslaunch> has been used tool tohas start been used ROSto nodes start ROS to setup nodes those to parameters setup those that are parameters relevancethat to realize are a relevance certa functionality. to realize a Content certa functionality. to be loaded is, Content for stance, to be loaded description is, for robot stance, models description turn robot tilt table models model. The model turn descriptions tilt table have model. been complemented The model by physical descriptions formation have been related complemented to workpiece by physical selected formation weldg related to (piece workpiece 1 pieceselected 2). for weldg At system (piece start, 1 or piece by default, 2). all options related to determation workpiece are At system start, by default, all options related to determation workpiece are disabled. Therefore, it is necessary to dicate part which is to be welded. This can be achieved, disabled. Therefore, it is necessary to dicate part which is to be welded. This can be achieved, for stance, by: for stance, by: < $ roslaunch world_move_group world_ organization. launch piece1:= true > < $ roslaunch world_move_group world_ organization. launch piece1:= true > Or Or launch launch files files have have to to be be applied to to load XML description weldg weldg job job GAZEBO GAZEBO simulation module, cludg workpiece model (for (forstance: <piece <piece 2>) 2>) as shown as shown Figure Figure Figure 10. Workpiece 2, robots, turn table simulated GAZEBO. Figure 10. Workpiece 2, robots, turn table simulated GAZEBO. Furr launch files are also necessary to load visualization RViz, trajectory controllers, Furr launch action files are servers, also necessary robot_state_publisher. to load visualization As soon RViz, as all nodes, trajectory controllers, controllers, action servers, robot_state_publisher. As soon as all nodes, controllers, terfaces, parameters are loaded, lks between ROS, MoveIt!, GAZEBO are achieved all nodes are prepared to run application.

15 However, what about efforts provided by MoveIt!? To be able to verify se efforts organizg work two robots more detail, same weldg job was planned aga but, this time, weldg has been executed by only one robot. The resultg number calls times for call execution are visualized Figure 12. In Figure 12 re are total 217 cycles different dividual durations. Out se Maches 2016, 4, Results from Application Tests a Static Workg Environment The applications scenarios selected to test technical feasibility to study performance our approach were focused first on weldg jobs a static workg environment. To start at a lower level complexity, it was decided to compose team robots by two similar six-axis ABB manipulators. They should collaborate executg defed weldg jobs. The geometry workpiece should combe lear as well as circular welds. Therefore, table plate positioner model has been loaded with <piece 2> first, as shown Figure 10. The 14 jots to be welded with this application test have been positioned at a fixed orientation. The weldg position was defed to be always horizontal. Accordg to Figure 10, positions two robots have been chosen close to positioner, opposite to each. In this way robots were forced to operate with overlappg work spaces when executg weldg job through collaboration. As mentioned a previous section, MoveIt! always used to start with generation an action list by evaluation XML job description. Then it contued fully autonomously organizg work two robots selected for test by callg self-organization node first. The outcome were lists activities beg subscribed to each robots. Prior to this subscription, an optimization process was passed to meet economic goals by distributg only those series weldg tasks Maches towards 2016, 4, each 23 robots, which assured a mimum execution time The resultg sequences activities subscribed to two robots provided put for MoveIt! obviously collision-free 144 operations trajectories can be analyzed towithout generateany waypots for result. movement They have been aborted virtual due robots to time simulation overflow. environment GAZEBO. The procedures were performed accordance to technologies The overall described time for previous robot 1 sections. was measured to as s, while for robot 2 took MoveIt! s. Reasons may be a non-balanced workload as result from All calculations activities MoveIt! have been performed real-time to enable self-organization processes perhaps more complex verse kematic transformations related to a fluent transfer trajectory data towards ROS controllers for controllg movement robot 2. robots. Neverless, execution times measured for two robots dicate that total In order to justify performance computational efforts durg self-organization workload was shared distributed to each two devices accordance to ratio trajectory calculations view dems for real-time control, to underst times. Therefore, as a result from first application tests it could be demonstrated that mechanism, robot time teamwork constrats, will reduce restrictions total MoveIt! execution had to times cope with, weldg a series jobs experimental considerably. tests have Programmg been performed. was done with 1.4 m. This is very fast compared to stard Teach- programmg. Therefore, In paper case contues two with ABB an robots overview (same type) important which results, have been as well selected as with for experiences tests, a reduction first conclusions job execution gaed from time various by nearly application 50% can tests. be observed Focus has due been to collaboration. given firstlythis to application is what tests we expected. a static workg environment. Results are presented Figures Figure 11. Times trajectory with RRT connect to weld workpiece 2 a horizontal Figure 11. Times trajectory with RRT connect to weld workpiece 2 a horizontal position position with two robots (vertical: time seconds horizontal: number motion plan with two robots (vertical: time seconds horizontal: number motion plan executions). executions).

16 Maches 2016, 4, Maches 2016, 4, Figure 12. Times trajectory with RRT connect for for only one one robot to to weld weld workpiece 2 2 a horizontal a position position (vertical: (vertical: time time seconds seconds horizontal: horizontal: number number motion plan motion executions). plan executions). The diagram Figure 11 shows different calls times activities performed To verify by MoveIt! this assumption to execute weldg more detail, 15 jots tests represented have been by contued, <piece 2>. The but data now are with based more on complex dividual application plans for each scenarios. robot with RRT connect planner. To enable faster, lear weldles have been additionally split to 130 dividual 7.2. Results from Application Tests Dynamically Changg Workg Environments path segments m length, respectively, to arc segments 10, case circular To weldles. verify performance self-organization, self-coordation, autonomous collaboration The timeat diagram higher levels dicates complexity, 184 a series calls for tests robot have 1 been 108carried calls for out robot toger 2. In with total we a new can see test 292 scenario. path This is activities shown performed Figure 13. byinstead MoveIt! with two robots a time frame same type, s = now 1.4 m. two completely The red leheterogeneous diagramweldg represents robots a programmable (ABB, six-axis time limit. KUKA, Allseven-axis) calculations a controllable beyond tilt 3 s limit turn were table not (two-axis) considered have bybeen MoveIt!. applied They to will test not contribute prove totechnical feasibility process our approach. start a new<piece call automatically. 1> was selected first because its simple geometry its lear fillet-type weldles. Out total 292 calls, 18 operations have to be considered for calculatg collision-free As it was trajectories foreseen to that move weldg robots should on always traversal be paths performed with pot-to-pot a gravity movement position durg (PTP) application mode, for stance, tests with from dynamically one weldle changg to conditions, next. Considerg turn that 130 tilt calculations table had to were be oriented used to from specifya loadg movement position (Figure two robots 13b) towards along an weldles angular through table position terpolated 45 control (Figure pots, 13a). Furrmore, obviously 144 an operations cremental can be reorientation analyzed without any workpiece durg result. job They execution have been was aborted required due to assure time overflow. weldles were always positioned a gravity position prior to weldg. The overall time for robot 1 was measured to as s, while for robot 2 took MoveIt! s. Reasons may be a non-balanced workload as result from self-organization processes perhaps more complex verse kematic transformations related to robot 2. Neverless, execution times measured for two robots dicate that total workload was shared distributed to each two devices accordance to ratio times. Therefore, as a result from first application tests it could be demonstrated that robot teamwork will reduce total execution times weldg jobs considerably. Programmg was done with 1.4 m. This is very fast compared to stard Teach- programmg. In case two ABB robots (same type) which have been selected for tests, a reduction job execution time by nearly 50% can be observed due to collaboration. This is what we expected. However, what about efforts provided by MoveIt!? To be able to verify se efforts organizg work two robots more detail, same weldg job was planned aga but, this time, (a) weldg has been executed by only one robot. (b) The resultg number calls times for call execution are visualized Figure 12. Figure In Figure Weldg re are <piece total 1> 217 a permanent cycles gravity different position dividual with ABB durations. KUKA Out robots. se (a) weldg position; (b) loadg position. 217 cycles, 130 cycles are considered for trajectory calculations along predefed weldles with

17 Maches 2016, 4, terpolated waypots. Four cycles were necessary to calculate trajectories traversal movement from one weldle to next, for return to home position. Accordg to this calculation, 83 cycles have been aborted because collision problems /or time overflow. Compared Figure 12. to Times time trajectory for with activities RRT connect two robots, for only now one robot a resultg to weld workpiece time 2 only a horizontal s totalposition could be (vertical: measured. Mosttime seconds horizontal: cycles neednumber a time motion aroundplan 0.02 s. This is executions). 1/10 time MoveIt! has spent for path with teams two robots. Therefore, view se results, it might be favorable to focus on parallelism, if self-organization autonomous To verify path this assumption with MoveIt! more detail, for multi-robot tests have applications been contued, is requested. but now with more complex To verify application this assumption scenarios. more detail, tests have been contued, but now with more complex application scenarios Results from Application Tests Dynamically Changg Workg Environments 7.2. Results from Application Tests Dynamically Changg Workg Environments To verify performance self-organization, self-coordation, autonomous collaboration To verify at performance higher levels self-organization, complexity, a series self-coordation, tests have been carried autonomous out toger collaboration with a atnew higher test levels scenario. complexity, This is shown a series tests Figure have 13. been Instead carried two out toger robots with same a newtype, test scenario. now two This completely is shown heterogeneous Figure 13. Instead weldg two robots robots (ABB, six-axis same type, KUKA, now two seven-axis) completely heterogeneous a controllable weldg tilt robots turn (ABB, table (two-axis) six-axis have KUKA, been seven-axis) applied to test a controllable prove tilttechnical turn table feasibility (two-axis) our have approach. been applied <piece to1> test was selected prove first technical because feasibility its simple our geometry approach. <piece its 1> lear was selected fillet-type first weldles. because its simple geometry its lear fillet-type weldles. As As it it was was foreseen that that weldg weldg should should always always be be performed a gravity a gravity position position durg durg application tests tests with with dynamically dynamically changg changg conditions, conditions, turn turn tilt table tilt had table tohad be oriented to be oriented from a loadg from a position loadg (Figure position 13b) (Figure towards 13b) antowards angular table an angular positiontable 45position (Figure 13a). 45 Furrmore, (Figure 13a). anfurrmore, cremental reorientation an cremental reorientation workpiece durg workpiece job execution durg was job required execution to assure was weldles required to were assure always weldles positioned were always a gravity positioned prior a gravity to weldg. position prior to weldg. (a) (b) Figure Figure Weldg Weldg <piece <piece 1> 1> a a permanent permanent gravity gravity position position with with ABB ABB KUKA KUKA robots. robots. (a) (a) weldg weldg position; position; (b) (b) loadg loadg position. position. Based on list actions derived from correspondg XML job description system, aga, started to plan organize activities two robots tilt turn table fully autonomously. This happened accordance to self-organization algorithms rules described Section 3.2. While was progressg, list actions has been contuously decreased dependg on activities already havg been realized. They were deleted from list after execution. As jots to be welded at <piece 1> always represent straight les horizontal position, Cartesian path between WeldStart WeldEnd at each jot could be planned through a list

18 Section 3.2. While was progressg, list actions has been contuously decreased dependg on activities already havg been realized. They were deleted from list after execution. As jots to be welded at <piece 1> always represent straight les horizontal position, Maches 2016, 4, Cartesian path between WeldStart WeldEnd at each jot could be planned through a list waypots beg terpolated at path segments 10 mm per terpolation cycle. The generated waypots path did not beg need terpolated to be simplified, at path segments sce it was 10 mm already per terpolation shortest path cycle. to The be generated found path did Cartesian not need space. to be simplified, sce it was already shortest path to be found Cartesian space. As described, it it was task MoveIt! to to plan plan trajectories for for movement robots robots to check to check for collision, for collision, eir between eir between robots robots workpiece, workpiece, betweenor between robots mselves. robots In mselves. case a collision In case was a predicted collision was by MoveIt!, predicted by MoveIt!, process was aborted process was a newaborted attempt was a started new attempt to fdwas a collision-free started to path. fd a Therefore, collision-free especially path. Therefore, complex application especially scenarios complex beg application applied for scenarios testg, beg applied for processes testg, can be time-consumg processes can be may time-consumg result varyg may computation result times. varyg This computation phenomenon times. is recognized This phenomenon time is recognized diagram time diagram process presented Figure process 14. presented Figure 14. Figure 14. Times cycles with BKPIECE to weld <piece 1>. The The weldg weldg job job to to enable enable collaboration collaboration two two robots robots a tilt a tilt turn table turn (15 table axes (15 axes motion motion total) took total) MoveIt! took 43 MoveIt! 43 cycles as dicated cycles as dicated Figure 14. Compared Figure 14. to Compared application to tests application described tests Section described 7.1 with Section dividual 7.1 with motion dividual, motion now, now procedures have procedures been carried have out been by applyg carried out by URDF applyg group-node URDF concept group-node (see: Section concept 6) (see: use Section a BKPIECE 6) use planner. a BKPIECE A threshold planner. 15 s (red A threshold le) was defed 15 s (red to abort le) a was defed cycle to abort due to a time overflow. cycle due to time overflow. Accordg Accordg to to Figure Figure an an average average time time total total s = 6.6 s = m 6.6 was m measured. was measured. Ne Ne cycles cycles had been had been aborted aborted due due to time to time overflow. overflow. In In one one case case it it was was necessary necessary to to call call dividual dividual motion motion planners planners for for ABB ABB KUKA KUKA robot robot (blue (blue orange orange pots) pots) because because a a lack lack results results from from calculations calculations with with group-node group-node concept. concept. Fally, Fally, s total total time time were were spent spent for for trajectory trajectory optimization optimization activities. activities. Then Then degree degree complexity complexity has has been been creased creased aga aga by by selection selection an an application application scenario scenario to weld to weld <piece <piece 2>, which 2>, which cluded cluded a composition a composition lear lear circular circular weldles. weldles. As shown As shown Figure 15, it Figure took MoveIt! 15, it took 62 MoveIt! 62 cycles different cycles times different to plan times collaboration to plan side collaboration team side robots. The total time to plan activities robot 1 (ABB), robot 2 (KUKA LBR), three-axis turn tilt table was 398 s, i.e., 6.6 m. Ne motion plans were aborted. The loss time related to aborted plans was around 136 s. Furrmore, 8 s were necessary for path simplification. Although group node concept with <world.urdf.xacro> BKPIECE path planner have been applied itially for trajectory, dividual planner calls based on RRT connect to solve problems are ten recognized because aborted calls with group-node concept.

19 three-axis turn tilt table was 398 s, i.e. 6.6 m. Ne motion plans were aborted. The loss Maches time related 2016, 4, to 23 aborted plans was around 136 s. Furrmore, 8 s were necessary for 19 path 23 simplification. team Although robots. The group total time node to concept plan with activities <world.urdf.xacro> robot 1 (ABB), robot BKPIECE 2 (KUKA path LBR), planner have three-axis been applied turn itially tilt for table trajectory was 398, s, i.e. 6.6 dividual m. Ne planner motion calls plans based were on aborted. RRT connect The loss to Maches 2016, 4, time solve related to problems aborted are ten plans recognized was around because 136 s. Furrmore, aborted calls with 8 s were group-node necessary for concept. path simplification. Although The group node turn concept tilt table with <world.urdf.xacro> movement appeared as an BKPIECE dividual path planner planner because have been applied CIRC welds, itially which for trajectory required a, constant dividual table rotation planner whilecalls circular based on weld RRT path connect had to be to solve tracked by one problems robots. are ten recognized because aborted calls with group-node concept. Figure 15. Time diagram procedure to weld <piece 2>. The turn tilt table movement appeared as an dividual planner because CIRC welds, which required a constant table rotation while circular weld path had to be tracked by one Figure robots. 15. Time diagram procedure to weld <piece 2> Evaluation The Real-Time turn Simulation tilt table movement appeared as an dividual planner because CIRC welds, which required a constant table rotation while circular weld path had to be As collaborative work performed by by a team a team robots robots cooperation cooperation with with a turn a turn tilt table tilt tracked by one robots. has table been has visualized been visualized evaluated evaluated by means by means real-time real-time simulation simulation (Figure 16), (Figure sometimes 16), sometimes it could be it recognized could be recognized that that took tootook muchtoo time much to calculate time to calculate verse verse kematic kematic solution solution for 7.3. Evaluation Real-Time Simulation entire for system entire system 15 axes 15 axes a desired a desired position. position. As collaborative work performed by a team robots cooperation with a turn tilt table has been visualized evaluated by means real-time simulation (Figure 16), sometimes it could be recognized that took too much time to calculate verse kematic solution for entire system 15 axes a desired position. Figure 16. Simulation robot collaboration. Figure 16. Simulation robot collaboration. In this case, was divided per robot was calculated dividually. This resulted simulation sequences where only one robot at one time was executed. The reason was, as already mentioned, that ROS Master Figure Server 16. Simulation MoveIt! are robot only collaboration. able to support path by means only one URDF file at a time. Durg simulation, to visualize was also how path planner MoveIt! have planned to contue next movement robots configuration space. For this purpose motion fered an animation before execution movement. A shadowed robot, shown

20 In this case, was divided per robot was calculated dividually. This resulted simulation sequences where only one robot at one time was executed. The reason was, as already mentioned, that ROS Master Server MoveIt! are only able to support path by means only one URDF file at a time. Durg simulation, to visualize was also how path planner MoveIt! have planned to Maches 2016, 4, contue next movement robots configuration space. For this purpose motion fered an animation before execution movement. A shadowed robot, shown Figure 17, represents trajectory to beto executed be executed next, while next, while real robot real model robot hasmodel been visualized has been visualized its actual position. its actual position. Figure 17. Motion with real shadowed robots for detailed evaluation process. As soon as result was evaluated released by MoveIt!, trajectory data were As soon as result was evaluated released by MoveIt!, trajectory data were transferred to GAZEBO simulated robots moved. In this way quality results transferred to GAZEBO simulated robots moved. In this way quality results could be studied detail if necessary. could be studied detail if necessary. Due to different cycle times durg trajectory with MoveIt!, but also because Due to different cycle times durg trajectory with MoveIt!, but also because variations motion execution which were fluenced by communication data transfer variations motion execution which were fluenced by communication data transfer speed speed between MoveIt! GAZEBO simulator, measurable total times weldg job between MoveIt! GAZEBO simulator, measurable total times weldg job execution execution simulation were not applicable to predict any execution times to be expected simulation were not applicable to predict any execution times to be expected reality. reality. However, GAZEBO has been very useful demonstratg technical feasibility However, GAZEBO has been very useful demonstratg technical feasibility applicability our approach. It also provided powerful tools for studyg performance applicability our approach. It also provided powerful tools for studyg performance self-organization autonomous obtag collision-free executable trajectories self-organization autonomous obtag collision-free executable trajectories for a coordated controlled execution given weldg jobs through collaboration by teams for coordated controlled execution given weldg jobs through collaboration by teams dustrial robots. dustrial robots. By application URDF group-node concept trajectory, it was possible to control By application URDF group-node concept trajectory, it was possible to move simulated robots simultaneously. However, as soon as group-node concept failed control move simulated robots simultaneously. However, as soon as group-node concept fdg executable trajectories, dividual planners per robot had to be used to replace m. failed fdg executable trajectories, dividual planners per robot had to be used to replace Fast solutions have been achieved, but only with simulated movements, robot by robot. m. Fast solutions have been achieved, but only with simulated movements, robot by robot Interface Concept to Control Real Physical Robots 7.4. Interface Concept to Control Real Physical Robots The MoveIt!-based motion concept developed project was able to generate not only The MoveIt!-based trajectories motion waypots to control concept developed movement project robotwas models able to agenerate simulation not environment only trajectories GAZEBO. waypots The output to control movement procedures was also robot applicable models for a simulation control real environment physical robots GAZEBO. beg connected The output to ROS procedures control was environment also applicable shown for Figure control 7. For real thisphysical purpose, robots controller beg connected terface to needs ROS to be extended on one control sideenvironment by hardwareshown modules, like Figure real-time 7. For this Ernet purpose, a TCP/IP controller network terface to support needs to communication be extended on, one on side by or hardware side, by stware that has to be implemented to transform output data from MoveIt! to a robot-specific mache code, as well as to feedback data from robots to MoveIt! For communication with KUKA robot LBR IV, KUKA Ernet KRL XML package can be used. It supports data exchange through use XML messages.

21 Maches 2016, 4, For ABB robots appropriate hardware for networkg has to be established. Furrmore, a special stware converter has to be developed tegrated to controller terface MoveIt!. This wraps waypot data from MoveIt! to messages defed syntax cares for transmission to ABB robot controller. By means READ task, provided by ABB controller, strgs a maximum 80 characters can be decoded to start defed robot programs side ABB controller. A SEND task can be used side ABB controller to send messages to ROS world. In this way bi-directional communication can be achieved managed. However, connection to real physical robots, which will replace GAZEBO simulator, was not part project, refore, a topic future work. 8. Conclusions The proposed ROS-based concept with tegrated self-organization, autonomous trajectory, simulation capabilities fers new perspectives advantages applyg collaboratg multi-robot systems for weldg automation purposes. Even if robot teams are composed totally heterogeneous maches, with ROS it could be demonstrated that just one programmg language is sufficient to support direct communication any teraction between m. This makes control collaborative automation easy fast to implement. It became obvious durg project work that ROS ROS-based stware functions, available as open source products, can provide a suitable platform for developers to implement powerful telligent solutions capable applyg controllg dustrial robots special application scenarios advanced automation concepts. User put to operate multi-robot applications could be reduced considerably by our approach. Instead complex programmg synchronization, now it is focused more or less on description manufacturg job to be executed by robots. The results achieved so far from extensive application tests performance studies have demonstrated technical feasibility our approach, prciple. The selected algorithms for trajectory, represented by RRT connect BKPIECE, are able to create fast results at acceptable times. Individual trajectory for one robot with RRT connect could be performed with seconds for an entire weldg job, for stance, 14 welds four PTP-based traversal movements. This is a very promisg result which should stimulate follow-up research. An crease time could be recognized as soon as number robots additional peripheral kematic systems, like multi-axis workpiece positioners, are considered for collaboration. Especially, verse kematic calculations, as well as more extensive collision checks, will extend times. However, sufficient results smooth control can be expected from our approach, if applications are restricted towards teams with only two or three robots, respectively, with kematic devices up to a maximum DOF. In addition to dividual trajectory calls per robot, group node concept with grouped URDFs has been troduced tested. Its application resulted a decreased number cycles or calls, but at creased times per call due to more complex collision checks verse kematic transformations. If those calculations with group-node concept can be achieved without any time overflow, a smooth collision-free teraction robots can be expected as demonstrated Figure 14. However, at creasg complexity calculations efforts, URDF group-node concept will lose its applicability because creasg numbers calls with time overflow. The growg domance dividual activities should be recognized, this case, as shown Figure 15. Therefore, future work should be focused on technological improvement better applicability. A promisg approach seems to be implementation parallel activities as soon as number robots or peripheral devices creases towards defed limits beyond. Operatg with dividual ROS frameworks motion planners per robot is recommended this

22 Maches 2016, 4, case. A ROSTCP-based communication frastructure to assure gapless teraction side team is to create. Additionally, useful could be implementation a pre-calculus for motion collaborative control as one strument for furr improvement. In view goals visions Industry 4.0, which had stimulated our project, outcome achieved so far demonstrates how cognitive functions autonomy may open new perspectives towards development telligent maches advanced automation concepts. In this context frameworks ROS dustrial ROS can fer excellent tools, functions, open source stware, especially applicable for research technological development field robotics robot applications. The technical approach on self-organization autonomous path, developed to improve applicability robot teamwork collaboration weldg automation, may also contribute to meet goals visions developg telligent maches that will help humans to master challenges future. Acknowledgments: The authors like to thank German Research Foundation (DFG) for fundg this project. Special thanks also to APS GmbH-European Centre for Mechatronics, Aachen for ir support for providg resources that had been necessary to work on this project successfully. Author Contributions: Günr Starke conceived ideas for project, defed goals research, specified work program. As project manager he supervised progress work, coordated research activities, wrote this paper. Daniel Hahn provided technical support field robotics, robot modelg, control. He also supplied project work with relevant feedback. Diana G. Pedroza Yanez Luz M. Ugalde Leal developed ROS IT-frastructure to organize, plan, coordate robot actions to enable collaboration. In this context, Ms Ugalde has focused her research on application teams robots for collaboration static workg environments, while Ms Pedroza has concentrated her scientific work on application collaboratg robots dynamically changg workg environments. Both m performed experiments functional tests, measured relevant process data, contributed to evaluation results from application tests. Conflicts Interest: The authors declare no conflict terest. References 1. IFR: Executive Summary World Robotics 2016 Industrial Robots. Available onle: org/fileadm/user_upload/downloads/world_robotics/2016/executive_summary_wr_industrial_ Robots_2016.pdf (accessed on 24 November 2016). 2. Papakostas, N.; Michalos, G.; Makris, S.; Zouzias, D.; Chryssolouris, G. Industrial applications with cooperatg robots for flexible assembly. Int. J. Comput. Integr. Manuf. 2001, 24, [CrossRef] 3. ABB: ABB MultiMove Functionality Heralds a New Era Robot Applications. Available onle: library.e.abb.com/public/734fb908d1c8ee50c12576dd005b69d0/abb%20multimove%20functionality.pdf (accessed on 28 November 2016). 4. Hub Technologies. Available onle: technologies/prt/start.htm (accessed on 28 November 2016). 5. MOTOMAN XRC 201 Controller Independent-Coordated Function. Available onle: hubspot.net/hubfs/366775/downloads/documentation/ pdf?t= (accessed on 6 October 2016). 6. Parker, L.E. Current research multi-robot systems. Artif. Life Robot. 2013, 7, 1. [CrossRef] 7. Lazica, A. Recent Advances Multi-Robot Systems; I-Tech Education Publishg: Rijeka, Croatia, Ravankar, A.; Ravankar, A.A.; Kobayashi, Y.; Emaru, T. SHP-Smooth Hypocycloidal Paths with Collision-Free Decoupled Multi-Robot Path Planng. Int. J. Adv. Robot. Syst. 2016, 13, [CrossRef] 9. Latombe, J.C. Robot Motion Planng; Sprger: New York, NY, USA, RoboCup. Available onle: (accessed on 28 November 2016). 11. Chen, X.; Stone, P.; Sucar, L.E.; Zant, T. RoboCup 2012: Robot Soccer World Cup XVI; Sprger: Berl/Heidelberg, Germany, Yan, Z.; Joueau, N.; Cherif, A.A. A Survey Analysis Multi-Robot Coordation. Int. J. Adv. Robot. Syst. 2013, 10, [CrossRef]

23 Maches 2016, 4, Multi-Robot Technology. Available onle: (accessed on 6 October 2016). 14. About ROS. Available onle: (accessed on 25 November 2016). 15. Șucan, I.A.; Moll, M.; Kavraki, L.E. The Open Motion Planng Library. IEEE Robot. Autom Mag. 2012, 4, [CrossRef] 16. Kuffner, J.; LaValle, S.M. RRT-connect: An efficient approach to sgle-query path. In Proceedgs 2000 IEEE International Conference on Robotics Automation, San Francisco, CA, USA, April Şucan, I.A.; Kavraki, L.E. Kodynamic motion by terior-exterior cell exploration. In Algorithmic Foundation Robotics VIII; Sprger: Berl/Heidelberg, Germany, MoveIt! Setup Assistant Tutorial. Available onle: html/doc/tutorial.html (accessed on 4 October 2016). 19. Gazebo: ROS Control, Tutorial. Available onle: (accessed on 4 October 2016) by authors; licensee MDPI, Basel, Switzerl. This article is an open access article distributed under terms conditions Creative Commons Attribution (CC-BY) license (