Toward a Plug-and-Work Reconfigurable Cobot

The ongoing trend from mass-produced to mass-customized products with batch sizes as small as a single unit has highlighted the need for highly adaptable robotic systems with lower downtime for maintenance. To address these demands, this article proposes the development of a novel reconfigurable collaborative robot (cobot), which has the potential to open up many new scenarios within the rapidly emerging flexible manufacturing environments. As the technological contribution, we present a complete hard- and software architecture for a quickly reconfigurable EtherCAT-based robot. This novel approach allows to automatically reconstruct the topology of different robot structures, composed of a set of body modules, each of which represents an EtherCAT slave. As the theoretical contribution, we propose a method to obtain in an automatic way the kinematic and dynamic model of the robot and store it in universal robot description format (URDF) as soon as the physical robot is assembled or reconfigured. The method also automatically reshapes a generic optimization-based controller to be instantly used after reconfiguration. While this article focuses on reconfigurable manipulators, the proposed concept can support arbitrary serial kinematic tree-like configurations. We demonstrate the contributions with examples of the following: how the topology of the robot is reconstructed and the URDF model is generated, and a Cartesian task application for a cobot built with the basic modules, demonstrating the quick reconfigurabilty of the system from a 4-degrees-of-freedom (DOF) robot to a 5-DOF robot, in order to satisfy new workspace requirements.

many small-and medium-sized enterprises struggle to benefit from robotics. The main perceived barriers are the limited flexibility to serve manufacturing trends of shorter product life cycles, smaller lot sizes, and mass-customized products [1], requiring new paradigms of highly configurable robot solutions. While being flexibly programmable and customizable from a software perspective, the hardware customizability of existing cobots is limited to the end-effector tooling. Conventional cobots are strictly fixed in their physical properties such as the number of degrees of freedom (DOF), kinematics (workspace volume and shape), as well as payload capacity. The size and payload capacity appear to be "rigidly" proportionate: the higher the payload capacity, the bigger the robot. These observations motivate the work on reconfigurable robots, i.e., modular robots that can be frequently reconfigured in their physical shape even after their initial build. On the other hand, quickly reconfigurable robots offer the required versatility to adapt and realize fit-to-task kinematic arrangements on demand, addressing changes in the manufacturing process with minimal downtimes of the automation line. In particular, the physical characteristics of reconfigurable robots can be rapidly customized to meet specific and varying application requirements, in terms of payload, workspace, kinematics, and task dexterity. Reconfigurable robots can be split and merged to quickly increase throughput for simple tasks with few required DOF and reduce energy consumption. For maintenance, individual modules can be selectively and swiftly swapped. Swapped modules can be comfortably returned to the manufacturer for maintenance, whereas a conventional robot would have to be substituted entirely or maintained on-site resulting in longer downtimes.
The first prototypes of modular manipulators start to appear between the late 80s and early 90s, with some pioneering work in [2]- [4]. Later in the 90s, Chen proposed a generic approach for the automatic model generation of reconfigurable robot systems [5] and later exploited it to realize a reconfigurable robotic workcell [6]. From the early 2000s, other applications such as search and rescue robots [7], and space applications [8] have been explored along with self-reconfigurable robots [9], [10], intrarobot reconfiguration [11], or approaches for reconfigurable redundant manipulators [12]. The topic was also investigated more recently by works focusing on spring-assisted modular robots [13], autonomous exploration [14], self-reconfiguration planning [15], or optimization-based design [16], [17]. In the industrial world, a modular arm was developed by Schunk [18] and employed in [19] and [20]. A prototype modular robot was also proposed by Traclabs in [21].
To our observation, works concentrating on the electromechanical module design and modeling of reconfigurable robots have been dominating the literature until recently. Only fewmostly recent-works address how to enable a quickly reconfigurable robot to be also quickly programmable and operational by the user immediately after its reconfiguration. From our perspective, the flexibility benefits offered by reconfigurable robots are tangible only if the time to physically assemble the robot and the time to program it for the desired task are on an equally short time scale.
This directly leads to research questions and challenges concerning the fundamentally necessary capabilities for automated module discovery [22], [23], autogeneration and verification of complete and accurate kinematic and dynamic models, as well as automatic controller generation and tuning [24], [25].
In [26], an axiomatic design is applied to define a general architecture of reconfigurable robot systems that, with respect to previous approaches, allows to deal with more general types of modules and connections. In this regard, the authors introduced an object incidence matrix (OIM), which contains module-specific kinematic/dynamic parameters, extending the assembly incidence matrix (AIM) introduced in [27] to describe the robot topology. Nonetheless, neither of these works has shown how to automatically extract this inherent information from the communication network. Recently a similar work was presented in [28], where the kinematic structure is automatically detected, although no indication of the time scale of the reconfiguration process was given and only kinematic model of the robot was reconstructed, not allowing to implement dynamics-based controller as the one presented in this article.
The key contributions of this article are as follows: 1) A method for the automatic robot model detection and generation, by exploiting four-port EtherCAT network configurations.
2) The software architecture to realize a controller that, independently of the robot configuration, implements a torque-controlled compliant behavior, with no need for user input. While the model generation method is applicable to any reconfigurable robot, this article focuses on user-reconfigurable cobots of size, payload, and power ratings, equivalent to the commercially available conventional cobots requiring torquecontrolled functionality as a crucial requisite. The technological contribution of this article is the introduction of a novel hardand software architecture for user-reconfigurable cobots, which extends the software-centered flexibility and programmability of the conventional cobots also to the hardware level. The proposed method enables to operate the robot regardless of reconfigurations. It hides the specific hardware configuration details from the user. The presented novel reconfigurable cobot is entirely torque controlled and composed of interchangeable modular plug-and-work components featuring common electromechanical interfaces (EMI). Connecting two modules with the provided EMIs requires only a single torque wrench and less than one minute of time for a nonexperienced user.
As theoretical contribution, this article describes the automated configuration discovery of the connected modules, the kinematic and dynamic model generation, as well as the control and software interface adaptation required after each physical reconfiguration of the robot modules. It discusses all steps involved in the robot reconfiguration process and indicates the technical features enabling it in Section II. This involves the low-level communication systems required for the automated network topology recognition described in Section III, and subsequently, the robot physical topology reconstruction detailed in Section IV. Section V explains the reconfigurable software architecture including decentralized controllers on the module level, a hard real-time (RT) middleware with automatically reconfiguring centralized controllers, and higher level application interfaces. Section VI provides more details on the centralized controller reconfiguration. Section VII illustrates a hardware prototype with an application demonstration. Finally, Section VIII concludes this article.

II. RECONFIGURATION PROCESS OVERVIEW
The overall process of the robot assembly and reconfiguration consists of five steps as depicted in Fig. 2. Initially, the user manually assembles the robot by connecting the modules to realize the desired kinematic configuration suitable to the requirements of the targeted automation task. This is the only manual step where the user input is required. As soon as this step is completed and the physical robot is assembled from the interconnected modules, a network communication is established among the modules and the network topology can be discovered, as described in Section III. This enables to reconstruct the parent/child relationship among the modules. Each type of module also contains a unique identifier that permits after the discovery of the network and the identification of the interconnected modules, to access a database and obtain all parameters of each module. This information is then used to reconstruct the physical properties of the robot: kinematic, dynamic model, and semantic information such as which module is an End-Effector, or which modules are part of the same kinematic chain. Finally, the software architecture is dynamically reconfigured at the end of the robot reconfiguration permitting the user to operate the robot immediately and perform the required task right after the completion of this process. The rapid reconfigurability of the robot allows the user to quickly iterate the entire process to arrive at the most effective solution. The same process can be performed to quickly adapt the robot configuration to the new task and/or workspace settings.

III. NETWORK TOPOLOGY RECOGNITION
The requirements for the network technology suitable for the implementation of the proposed method are as follows: 1) Since each slave will comprise one electronic device, the topology of the network used in the proposed electronic must permit chaining of slaves to create tree-like robots. Only this way, modular serial kinematic robots, such as robotic arms, and tree-like robots, such as legged locomotion platforms, can be designed. 2) For kinematic and dynamic modeling, it must be feasible to infer the exact network topology, i.e., to extract the graph with slaves being the graph's nodes and the connections among the slaves being the graph's edges.

A. EtherCAT Networks
One communication network standard that satisfies these requirements is the EtherCAT standard that is briefly recalled here. In order to reconstruct the robot topology, we assume that for each robot module, the embedded slave device includes at least one EtherCAT slave controller (ESC) chip. Fig. 3 illustrates the base feature of different ESC chips complying with the EtherCAT standard. Each ESC is comprised of an EtherCAT processor unit and at least the Ports 0 to 2. Optionally, more ports (e.g., a Port 3) may exist (dotted port). In the following, only four-port slaves (Ports 0-3), as depicted in Fig. 3, will be considered. The Port 0 has a special function as a so-called upstream port, since it always points toward the network master. 1 When the EtherCAT master inserts a data telegram into the ring, it will arrive to a slave through Port 0. The telegram advances to the next port when a port is closed; open ports pass the telegram toward a slave connected to them, until it will be received back through this port and forwarded to the next one. Finally, the telegram arrives back to the master. Any port of the ESC is automatically opened or closed when a communication link on that port becomes active or inactive.
Each ESC exhibits a register, accessible by the master, which holds the open/closed state of each port.

B. Topology Reconstruction Algorithm
The network implementation allows to connect slaves in apparent topologies that are bus, tree-, or star shaped, resulting in robots with series or tree-like kinematic chains. However, an EtherCAT actual network topology is always an open ring where only the organization of the ports in the ESC makes the apparent network topology-and thereby, the robots physical topology-appear differently. The master sees all slaves lined up in a certain order on this ring. In this way, two different apparent network topologies (physical robots) can lead to the same order of slaves on the ring, as Fig. 4 exemplifies.
The example shows two robots, Robots A and B. The apparent topology of Robot A differs from the apparent topology of Robot B in that Slave 5 (Torso module) uses the Ports 0, 1, and 3 for Robot A, whereas for Robot B, the Ports 0, 1, and 2 are being employed. Both apparent network topologies yield the same common actual network topology ring seen by the EtherCAT master. This can be verified by following the outgoing network line across all slaves back to the master. The difference in the apparent network topology leads to a difference in the physical robot topology. The reconstruction of the apparent network topology from the order of the slaves along the network ring is, therefore, the first step to the automatic reconstruction of the robot kinematics and dynamics. This becomes possible by applying the convention that Port 0 is always the upstream port and by the ESC's register of open and closed ports, which can be read and set from the EtherCAT master.
The EtherCAT master can then reconstruct the apparent network topology from the network ring by looping over all slaves on the ring.
Each slave has a parent slave in the tree-like apparent network topology. This parent is a precursor on the network ring, but not necessarily the direct neighbor of the slave. Considering the EtherCAT network rules, it is possible, by looking at the open ports of each slave on the ring, to determine its parent, as implemented in the simple Open EtherCAT Master [29]. The result of this step is a graph structure χ representing the apparent network topology with the slaves being the nodes and the connection among the ports being the edges of the graph. As in [5], the graph χ can be represented in a more compact form by an AIM, with the difference that in our graph all types of modules (even joints) are vertexes. Every slave of the network (joints and links alike) is treated equally so that the robot topology can be detected.

IV. ROBOT PHYSICAL TOPOLOGY RECOGNITION
At this point, we identified the graph χ describing the network topology with each node representing an EtherCAT slave (see Section III). For each node, we can extract the information fully characterizing the module hosting the slave from the centralized database (see Section IV-A).
The convention for the frame assignment described in Section IV-B allows us to expand each slave node into multiple physical nodes as described in Section IV-C. This information is now aggregated into a tree-like data structure φ, where each node represents a physical body module. This new graph φ contains bodies as nodes, and joints and physical connections as edges; rather than slaves and ports, respectively. This tree reflects the physical topology of the robot and can be converted effectively to universal robot description format (URDF) [30] that will be exchanged among the different software agents. With the given robot model, we can compute kinematics and dynamics quantities as according to Featherstone [31] (see Section IV-D).
In Fig. 5, a nonexhaustive set of possible representations of robotic modules are depicted. Each robotic module comprehends at least one of the electronic devices with an embedded ESC, where available ports are associated to an EMI to connect to other modules. Robot modules can for instance be Link and Joint modules. The ESC inside a Joint or Link module features either one single (open end, last member of a chain) or two EtherCAT connections (interior member of a chain). End-Effector modules can only be placed as the ends of a chain and can have arbitrary application-related purposes such as sensor modules, gripper and tools modules, or mobility modules such as feet or wheels for various types of locomotion.
Base modules function as a control unit and allow to branch the network, and therefore, the robot's kinematic chain. It includes a minimum of one ESC, as in the other modules, in which all the four ports are available for communication. The Base module also contains an embedded PC where, together with the other software modules, the EtherCAT master is running, controlling the communication with the slaves and providing a command interface to the user. To this end, the Port 0 is used to connect to the EtherCAT master, leaving three available ports that can be used to connect robot branches. More ESCs can be combined in the Base module so that a higher number of branches can be connected. For example, the Base module presented in Fig. 5 combines two ESCs communicating with the EtherCAT master, thereby, allowing communication with five robot branches. In a similar way, Hub modules can be created with one or more ESCs, just like the Base modules without the EtherCAT master. Hub modules enable multiple branching points at any point in the structure.

A. Module Database
After creating χ, each slave is asked for its Module identifier stored in the microprocessor of the slave device. This identifier serves as a key to lookup the module properties in a centralized module database. The module identifier code embeds the following: 1) A Module type, which can be: 1 for an active Joint, 2 for a Base, 3 for an End-Effector, and 4 for a passive Link. 2) A Module id, which is used to distinguish between different module of the same type. For instance, it will be 1 for a straight Joint module and 2 for an elbow Joint module. 3) A Module size, which is 1 for small size modules, 2 for medium size, and 3 for large size. 4) A Module revision number, with increasing value for successive versions of the module design. The properties stored for each module type and version inside the centralized module database comprehend at least the following: 1) The coordinate transformations between the coordinate frames assigned to the module. 2) The inertial parameters of the module. This includes the center of mass (CoM) coordinates w.r.t. the upstream frame, and the module mass along with the module inertia parameters w.r.t. the CoM. For Joint modules, the parameters are stored separately between the upstream body and the downstream body of the joint. 3) Semantic information describing the common purpose of the module, which identifies, for example, an End-Effector module as a "gripper" or a "foot" or a "wheel." 4) Parameters for possible kinematic, differential or dynamic constraints associated with the module. Joint motion range, torque, and speed limits are common constraints. 5) Links to a 3-D mesh file graphically representing the module body, and coordinate transformation between the upstream frame of the body and the mesh origin.

B. Module Coordinate Frame Assignment
We introduce a coordinate frame convention to formalize the automatic model generation. A coordinate frame on each connection interface and on each joint axis define all the kinematic properties of a module. An additional reference frame on each moving body CoM, with axes parallel to the upstream frame, locates the inertial properties of the module. These coordinate frames {f } and the relative transformations T between them enable the reconstruction and description of the robot in URDF (see Section IV-C).
The frame axes are named as X, Y, and Z. As a convention in this article, the Z-axis of the module interface always points downstream. The optional leading subscript indicates a special purpose, such as a "j" means that the frame defines the joint axes of action. Frames without the optional purpose subscript indicate the placement of one of the interfaces of the module. The trailing superscript is the index or identifier associated with the ESC, while the trailing subscript refers to the port of the ESC: { purpose f slave_id port_id }. The coordinate frames are kept parallel to the upstream frame where possible. If a reorientation of one coordinate frame with respect to the upstream frame is necessary, the approach is to rotate about the minimum number of axes. The two frames in a connected EMI are by default coincident. They can have an orientation offset Ω about the common axis. For joint axes indicated by the purpose subscript "j," the axis of action is always the Z-axis.
The coordinate frame assignment for Link and End-Effector modules is straightforward. In Fig. 6, example I shows the frame convention when two Joint modules are connected to each other. Example II shows the frame convention applied to a Base module. It is visible that for each port, there is a coordinate frame attached to the EMI.

C. Modeling and URDF/SRDF Generation
The coordinate frames convention introduced in Section IV-B, permits to unequivocally derive the robot physical model. Since reference frames associated to paired connection interfaces will be coincident, the relative kinematics between two subsequent modules will depend solely on parameters of the parent module. Following the notation in [31] for kinematic trees, we can denote as λ(k) the parent of a module of index k. The T λ(k),k transformation matrix between modules λ(k) and k, can be defined as the one between the frames associated to the input Port 0 of the modules {f (3) and p out ∈ {0, 1, 2, 3} is the port number where the subsequent module is connected. It assumes the dummy value of 0 only in case of the End-Effector module. For a module k, which can be any node in χ, the transformation depends only on the parent node λ(k) and the edge connecting the two nodes, which embeds the value of p out . Therefore, the relative forward kinematics between two modules a and b can be computed by traversing the graph from node a and iteratively call (1) until b is reached.
Algorithms such as those in [5] and [32] can be used to obtain the full forward kinematics model. The modular kinematics for any module k is where the aforementioned transformation matrices are as follows: describing the proximal and distal parts of the Joint module, respectively, T k 0,p out between input port (0) and the output port for Link/Base modules, and T k 0,tcp between input port and the TCP of End-Effector modules.
q k is the joint displacement of the module k.ŝ k j ∈ se(3) is the twist of the joint of module k expressed in the frame {f k j }. The 6-D coordinate vector s k j representing the twist coordinates of the joint axis is constant, with s k j = [0, 0, 0, 0, 0, 1] T for revolute joints and s k j = [0, 0, 1, 0, 0, 0] T for prismatic joints. By traversing the graph χ, each node can be expanded by applying (2) and using the data retrieved from the database, to obtain the graph φ. For example a Joint module node is expanded into two nodes representing the proximal and distal bodies, connected by an edge representing the actuated joint. The nodes store the dynamical parameters of each moving body and the edges the transformations relating the bodies to each other. This could be converted to an OIM [26] or AIM [27] for a more compact representation. Considering the URDF format (an XML format) as a de-facto standard for robot operating system (ROS)-based libraries, we convert the graph φ to an URDF file to describe the kinematics and dynamics model of the robot, representing the robot as a series of link elements (which consists of inertial, visual, and collision properties) connected by either fixed, prismatic, or revolute joint elements. The mapping between nodes and edges of φ and the URDF XML elements is, therefore, 1:1. Note that the static physical connection between two links (for instance between the distal and proximal body of two successive Joint modules) is represented by a fixed joint element, leaving to the URDF parser of the dynamic library of choice, the task of computing the dynamic parameters of the composite body.
Semantic information of the robot, such as a description of the end-effectors, kinematic chains, and joints composing them, is instead written in a semantic robot description format (SRDF), introduced by the MoveIt! framework [33] to complement the URDF.

D. Kinematic and Dynamic Algorithms
The dynamic library of choice derives unequivocally the kinematic and dynamic model from the URDF. Particularly efficient implementations of dynamic libraries, suitable for computations in a high-frequency RT control loop, are the ones using spatial algebra notation [31] such as kinematics dynamics library (KDL) [34], Pinocchio [35], or rigid body dynamics library (RBDL) [36]. In our current implementation, the latter was used, although any of these libraries allows to numerically compute from the URDF input all the main kinematic and dynamic quantities. The main algorithms to describe rigid body dynamics implemented are as follows: 1) The inverse dynamics or recursive Newton-Euler algorithm (RNEA) τ = RNEA(model, q,q,q) = M (q)q + n(q,q).
3) The composite rigid body algorithm (CRBA) where model is a data structure obtained by parsing the URDF. In particular, for the controller implemented in Section VI.C, the RNEA algorithm is used to compute the Coriolis-centrifugal and gravitational forces n and the CRBA to compute the manipulator mass matrix M . Other quantities such as point Jacobians, accelerations and velocities can be computed from the model structure as in [31].

V. RECONFIGURABLE SOFTWARE ARCHITECTURE
To exploit the reconfigurability of the hardware, also the software architecture should provide the necessary flexibility to automatically adapt to the new robot topology. It enables to make the robot a plug-and-work system, ready to be operated right after assembly, providing access to all the required API, without the need to define a new controller or the need for user input and tuning. To achieve the aforementioned, the proposed software architecture is structured on three main components, which are going to be described from the lower to the higher level.

A. Module Level
The firmware on each hardware module allows communication over the EtherCAT network, with an interface providing state measurements to higher levels of the architecture. The lower level implementation of active modules, e.g., joint and wheel modules includes a decentralized controller, which drives the module given the references from the higher levels.

B. Middleware Level
The middleware level exploits XBot [37], a cross-robot software framework that abstracts the diverse variability of the robotic hardware, assuring deterministic hard RT performance and delivering enhanced flexibility through a plug-in architecture. XBot provides to the user a standard API to communicate with the robot, regardless of its specific structure (manipulator, humanoid, quadruped, etc.), and independently of the particular software layer that the user wanted to operate within, requiring only the URDF and SRDF files. It, therefore, adapts its API to the discovered robot topology. Changing the robot topology, adding, for example, a kinematic chain, results in a different API that is compatible with the available components of the robot to control.
In the center of Fig. 7, the different components of XBot are depicted, which are detailed in [37]. The lowest layer implements the EtherCAT master, which realizes the bidirectional communication between the centralized software components and the decentralized ones implemented at the firmware level inside robot hardware modules. The main component of this architecture level is the Plugin Handler, which is responsible for running different RT plugins and executing them sequentially. One or more Communication Handler instead organize the communication to the third non-RT layer that is the application level. The XBotInterface provides an RT and non-RT API that are generated based on the model description obtained via the physical topology recognition.

C. Application Level
This third architecture level is the non-RT application software level. Software modules in this level run in non-RT threads, which asynchronously receive data from the middleware level and send command references to it. For instance, the interface to the ROS framework is built-in with XBot, allowing for integration with user-defined and third party ROS nodes.
To further simplify the development at the application level, the CartesI/O [38] library provides an autogenerated ROS API allowing the user to specify reference trajectories in the Cartesian space. It generates trajectories online and executes them in a hard RT control loop (inside a XBot RT plugin), while ensuring the RT safeness of the operations.
The reconfigurability on this level is intrinsic as the applications can run and terminate at arbitrary moments in time and interact with the underlying architecture levels through requests to a Communication Handler.

VI. RECONFIGURABLE CENTRALIZED CONTROL
All safety critical centralized controllers such as interaction, force, and impedance controllers run as RT plugins in the middleware architecture level. The controllers must respect the robot dynamics limits and remain stable even if the robot physical topology changes, which necessitates the reconfigurability also in the control architecture.

A. Optimization-Based Control
The proposed control architecture makes use of the OpenSoT library [39], which exploits quadratic programming (QP) and the concept of Stack of Task [40] to execute multiple tasks and achieve complex whole-body motion behaviors.
Tasks are mathematically described as convex quadratic programs, formulated as cost functions to minimize under linear constraints. The benefit of this approach is that global minimizers to such optimization problems are fast and efficient with guaranteed convergence. For example, a generic task can be described as the weighted least-square cost function defined by the matrix A, the column vector b, a weighting matrix W , and the robot state vector x. Tasks can be defined in the joint space, with the purpose to minimize joint state variables (e.g., torques or velocities) or other indexes, or in the Cartesian space, with the goal to impose a specific behavior to the robot (e.g., controlling the CoM or an end effector).
Constraints are defined by a generic function that can take the form of a linear inequality constraint where the column vectors l and u are lower and upper bounds, and the matrix C is the constraint matrix. Again, each column of the matrix C corresponds to a DOF of the robot. In the same way, each row corresponds to a constraint. Consequently, adding or removing a robot DOF changes the number of columns of C. The rows of the matrix C, and thereby, also the number of elements in the vectors l and u change with the number of constraints being active to the task. Tasks are atomic entities, which can be executed concurrently with soft or hard priorities. Soft priorities are assigned to "equally important" tasks by the weighted superposition of their individual cost functions. Equivalently, the concurrent tasks might be added as rows to the existing cost function. Hard priorities are assigned by minimizing cost functions of lower priority tasks subject to the preserved optimality of higher priority tasks using null-space projection techniques, equality constraints, or similar methods.

B. Controller Reconfiguration Principle
Controller reconfiguration is, therefore, equivalent to adding or removing rows or columns in the matrix equations of cost functions and constraints. The job of automatically composing the mathematical formulation of the controller is carried out by OpenSoT with the inputs given from the automatically discovered physical robot topology and the user-defined stack of tasks. A key feature of this step is that the user is not required to update the control task just because a new module has been added. End-effector task frames can be automatically shifted to new end-effector locations. The task formulation w.r.t. the end effector remains identical and numeric dimensions of the optimization problem are updated automatically.

C. Impedance Controller Implementation
A Cartesian impedance controller has been selected for demonstration in this article. It is particularly suited for tasks involving physical interaction with the environment. An impedance control law relates the wrench exerted on the environment by the manipulator's end effector F ext ∈ m to the deviation of its actual Cartesian position x ∈ m from the desired equilibrium point x d , according to the law where Λ d , D d , and K d are m × m matrices representing the desired mass, damping, and stiffness, respectively, and e = x − x d is the Cartesian error. The damping matrix is updated at each control loop, depending on the desired stiffness, the desired damping ratio, and the actual Cartesian mass matrix of the arm, e.g., with one of the techniques described in [41]. Without the external force feedback, the desired mass matrix cannot be chosen arbitrarily, but it is determined by the equivalent Cartesian mass matrix Λ(q) as where J (q) is the task Jacobian matrix of size m × n and M (q) is the manipulator's mass matrix of size n × n.
As in [41], the link-side dynamics of a robot with n flexible joints can be described by where q ∈ n is the joint state vector, n(q,q) ∈ n is the vector of gravitational and Coriolis-centrifugal forces, and τ d ∈ n is the desired torque vector. By selecting τ d = δτ + n(q,q) to compensate for the nonlinear terms, the closed-loop behavior (8) is achieved by choosing a δτ ∈ n solution of the following QP [42]: where f = Λ(q)(ẍ d −J (q)q) − D dė − K d e and C is the set of linear constraints as in (7) that imposes limits on position, velocity, acceleration, and torque. Equation (11) represents the main task in Cartesian space, for which one of the solutions is the well-known τ * = J (q) T f . In the case of redundant manipulators, the nullspace dynamics can be determined by adding dynamically consistent (see [41] and [43]) lower priority tasks expressed in the joint space (e.g., a postural task) or in the Cartesian space (e.g., conditions on other frames of the manipulator). We add the nullspace resolution task to the second level of priority in the Stack of Tasks. In this way, the structure of the controller remains unchanged when modifying the physical structure of the robot even in the presence of redundancy (e.g., adding modules to realize a 7-DOF manipulator).
We can see how (11) is written as in the generic form (6), where A = JM −1 is an m × n matrix, while x = δτ is a n × 1 vector and b = JM −1 This controller formulation is particularly suited for reconfigurable robots since adding and removing modules to the structure will just change the shape of the A matrix and the length of the robot state vector x, while no change to the controller or retuning of control parameters is needed.

VII. EXPERIMENTAL RESULTS
To validate the presented method, a reconfigurable robot prototype consisting of several straight and elbow Joint modules, an End-Effector module, and a Base module has been developed. With these basic modules, several tree-like robots can be created. The Joint modules are actuated by the Alberobotics actuators [44], [45], which feature integrated torque sensing, high power-to-weight ratio, and broad torque and velocity ranges. The end effector used in this prototypical implementation (Tool exchanger) includes a magnetic actuator to quickly attach or detach different tools. For this example, we use two EMIs of the Base module to attach module chains. The Base module contains Fig. 8. Side, top, and isometric view of the EMI. One of the two C-couplings required to establish a connection and its placement around the conical surface of the EMI, is also shown in the picture. A couple of screws can tighten the two C-couplings to establish the mechanical connection.
a power board and a compact PC with an RT operating system to run the centralized software modules up to the middleware level. The application level software runs on an external PC communicating with the embedded PC of the Base module via WiFi.
All module prototypes comprehend the slave device required by the proposed method. The EMIs allow to quickly establish a reliable mechanical connection that ensure an uninterrupted power and communication link between the modules.
It is realized by a hollow flange with a conical shape accommodating the power and communication bus connectors as shown in Fig. 8. The mechanical connection is established by mating the flanges of two modules with a pair of identical C-couplings, which can be tightened together with two screws. Such an interconnection establishes a form closure around the interface, and was also exploited in [46].
For the electrical connection instead, we exploited a commercial MPTC/MPSC connector with EIA-364 standard test approval for shock and vibration. This electrical connector allows for axial clearance of about 1 mm and is mounted on a printed circuit board with a rubber support for compliance w.r.t. the mechanical connector.
The proposed mechanical interface was designed to withstand a worst-case resultant moment of 170 Nm, with a safety factor of 1.5. The corresponding deformation/displacement is up to a maximum of 0.3 mm that guarantees the electrical connectivity. Fig. 9 illustrates automatic topology discovery and recognition with the experimental setup. The example is a tree-like robot with two chains extending from the Base module [see Fig. 9(1)]. Following Section III, the EtherCat master discovers the apparent network topology as a graph χ with each EtherCAT slave represented as a node [see Fig. 9(2)]. The displayed graph contains the position of the slave in the EtherCAT ring and the number of open ports. A 4-bit word identifies which ports of the ESC are open. For each port, the corresponding bit is set to one if open or zero otherwise. For each module, the Module Identifier is collected, which contains the following four fields characterizing it: type, id, size, and revision as described in Section IV. With the identifier, the information characterizing each module is retrieved and aggregated to χ [see Fig. 9(3)]. Fig. 9. Topology of a generic robot composed of the basic modules can be recognized with the proposed method. In this picture, a two-arm robot model has been built (1) and information on each module collected by the EtherCAT master (2). From this data, the proposed method reconstructs the network topology χ (3) and physical topology φ (4). A snapshot of the URDF representation of φ is shown in (5), and its virtual rendering in (6), matching the real robot. Different colors indicate different modules and show how the data are propagated through χ to φ, and then, stored in URDF. Light green, blue, and yellow indicate, respectively, Joint, Base, and End-Effector modules. In gray are instead indicated the fixed joints, rigid transformations representing the mechanical connections established between each module. Each node in the tree represents a module and contains all the associated kinematic, dynamic, and semantic data of the module. From this tree structure, the physical robot topology φ can be obtained [see Fig. 9(4)], and represented in the URDF format [see Fig. 9(5)].

A. Automatic Discovery Experiment
In Fig. 9(6), the output of the process, the URDF model, is rendered to assess the correct model generation.
At this point, both the simulation and robot hardware are ready to be used. The time required for building a robot structure from modules and automatically generate the model takes on average less than 5 min [compare also Fig. 10(2)].

B. Cartesian Task Experiment
To show the efficacy of the introduced method, we present an application example, where the same task is performed with two different robot configurations. In the example task, the robot is instructed to draw on two sheets of article. One sheet is further away than the other and necessitates a higher reachability of the arm. The task is repeated twice: once with 4 DOF (closer sheet) and one with 5 DOF (to reach the second farther sheet). The tool held by the end effector is a simple pen. Fig. 10 captures the main phases of the experiment starting from building the first 4-DOF robot [see Fig. 10(1)]. The automatic discovery phase [see Fig. 10(2)] comprises the network and physical robot topology recognition, and the controller reconfiguration. Next, the robot and controllers are started to kinesthetically teach and execute the drawing task [see Fig. 10(3)]. The whole procedure repeats for the 5-DOF robot in the adapt, discovery, and repeat phases [see Fig. 10(4)- (6)]. After in about 13 min, the entire experiment is completed. 2 For this experiment, a non-RT state machine runs at the application level of the software architecture of Section V to control the behavior of the robot. From the GUI, the user can put the robot in teaching mode to calibrate the workspace, specify the 2 Video of the experiment is available at: https://youtu.be/DHi7aI1HcpE Fig. 11. Actual end-effector pose and its reference on the x-y plane for the drawing task of the 4-DOF and 5-DOF robots.
drawing to execute, and select the control parameters (stiffness and damping ratio).
The rest of the procedure executes automatically. The controller does not need to be modified by the user after reconfiguration, since the software modules already reconfigure the middleware API and the controller architecture. In the automatic model generation, the only difference is the presence of one more module with an additional DOF in the kinematic chain. This is handled automatically in the discovery phase [see Fig. 10 (5)]. For this task, the defined controller uses a Stack of Tasks [39] with a translation and orientation Cartesian impedance task on the higher level of priority, and a Postural task on the second and last level of priority as explained in Section VI. The postural is required for robots that are redundant with respect to the task. The Stack of Tasks is defined a priori before the experiment.
In Fig. 11, the actual position of the end effector and the given reference are plotted in Cartesian coordinates, both for the 4-DOF and 5-DOF robot cases. The stiffness values used for this experiment are the same for the two robots, with a translational stiffness on the x-, y-, z-axes of 2500 [N/m], and rotational stiffness on the roll and pitch rotations of 20 [Nm/rad] with null stiffness on the yaw axis. This proves there is no need to retune the controller parameters after reconfiguration. The values for the damping matrix are instead computed as in [41] by setting a damping ratio of 0.7. Maximum error on the x-y plane during the drawing task is 0.0024 m for the 4-DOF robot and 0.0033 m for the 5-DOF robot.
With identical controller gains, the increased tracking error for the 5-DOF robot can be explained by accumulated model errors when higher number of modules are involved. One way to reduce the tracking error is raising the stiffness gains. Another option is enhancing the model accuracy for each module, i.e., from identification to decrease error contributions from model-based compensation terms. This will be part of future work.
The proposed method, comprising of the automatic kinematic and dynamic model generation, provides all the tools to implement other types of controllers capable of improving the trajectory tracking performance, although sacrificing the compliance behavior property of the impedance control, with techniques as those proposed in [47] and [48].

VIII. CONCLUSION
The article presents a novel method and a complete architecture for quickly hard-and software reconfigurable robots. The architecture comprises a set of modules with modular electromechanical communication, power, and mounting interfaces along with a fully reconfigurable software stack. The software stack comprises the lowest module firmware level, a hard RT middleware for centralized control and safety-critical algorithms as well as a higher non-RT application level.
Using the proposed method, the article successfully demonstrates and exemplifies how a robot can be built, programmed for a task, commanded to execute it, reconfigured for a larger workspace, and commanded again to execute the task in minimal time within 13 min approximately. The time to physically assemble and program the robot for the desired tasks is on equally short time scales. This paves the way to exploit the versatility of reconfigurable modular robots to cope with frequent product variation, minimize maintenance downtimes, and build new robot designs on-demand. The proposed approach enables robots not only to assist in the production of mass customizable products, but permits robots to become mass-customizable themselves.
Future research of this work will focus on the development of software assistant tools to help the user identify the optimal robot configuration for formally defined task requirements as well as on the further extension of the presented approach to floating-base robots for locomotion, mobile manipulation, and combined loco-manipulation tasks.