Module for a modular robot

Abstract

A module (4) for a modular robot (2) is disclosed. The module is configured to store a digital twin (5) of the module and, in response to determining that the module has been connected to another module, to transmit at least part of the digital twin to the other module.

Description

[0001] Module for a modular robot

[0002] Field

[0003] The present invention relates a module for a modular robot, to a modular robot and to a system comprising a modular robot.

[0004] Background

[0005] Modular robots, having interchangeable parts (or "modules") are known. An example of such a modular robot is Lynxmotion (TM) Servo Erector Set Professional modular robotic construction system. Reference is also made to Ye Dai et al.: " Research on Reconfiguration Strategies for Self-reconfiguring Modular Robots: A Review", Journal of Intelligent & Robotic Systems, 110:47 (2024).

[0006] When a robot integrator connects parts of a robot, they generally ensure that those parts are compatible in terms of physical connection, electrical connectivity (for example, bus type and connector pin positions), and power connectivity (for instance, voltage and current rating). Often, the integrator will also need to check for software connectivity and may need to write or to install software that allows the various parts of the robot to communicate.

[0007] 138271PCT1Summary

[0008] According to a first aspect of the present invention there is provided a moduie for a modular robot. The module is configured to store a digital twin of the moduie and, in response to determining that the module has been connected to another module, to transmit at least part of the digital twin to the other module.

[0009] This can allow a better description of the robot to be constructed which can help enable automatic commissioning of the robot.

[0010] The digital twin may include a three-dimensional model of the module, a set of physical simulation parameters and an application programming interface including an interface for controlling the module.

[0011] The three-dimensional model may be compliant with Unified Robot Description Format (URDF) format. The three-dimensional model may be compliant with COLLADA interchange file format.

[0012] The application programming interface may include an interface for gathering sensor data from a sensor in the module.

[0013] The physical simulation parameters may include information about mass, a centre of mass and / or an inertia tensor for the module. The physical simulation parameters may include, for each moving part of the module, information about a pivot point, degree of freedom angles, and / or limit(s) of movement. The physical simulation parameters may include information about parts that deform, such as Young's modulus and / or torsion modulus. The physical simulation parameters may include information about a limit of operation of a module, such as maximum speed, rotational inertia of joints and torque output, and / or strain limit(s).

[0014] The three-dimensional model may include, for each sensor of the module, information about the sensor and the position of the sensor.

[0015] The at least part of the digital twin may comprise a power budget, pivot points and information about sensor(s).

[0016] The module may comprise at least one power interface, at least one data interface, at least one processor and non-volatile memory storing the digital twin of the module.The module may be configured, in response to being connected to a further module and receiving at least part of a further digital twin from the further module, to forward the at least part of the third digital twin to the other module.

[0017] The module may be configured, in response to determining that the module has been connected to another module, prior transmitting the at least part of the digital twin, to transmit power requirement to the other moduie.

[0018] The module may be configured to store sensor data, calibration data, and / or in-field calibration data. The module may be configured to store data which allows refinement of a foundation model, such as LoRA extensions and LoRA weights. The module may be configured to store cryptographic keys.

[0019] According to a second aspect of the present invention there is provided a modular robot comprising a plurality of connected modules including one or more modules of the first aspect of the invention.

[0020] According to a third aspect of the present invention there is provided a system comprising the modular robot of the second aspect of the invention and a server storing a digital twin of the modular robot. The modular robot is communicatively linked to the server.

[0021] According to a fourth aspect of the present invention there is provided a method comprising a module for a modular robot, in response to determining that the module has been connected to another module, transmitting at least part of a digital twin stored in the module to the other module.

[0022] According to a fifth aspect of the present invention there is provided a computer program which, when executed by at least one processor in a module, cause the at least one processor to perform the method of the further aspect of the invention.

[0023] According to a sixth aspect of the present invention there is provided a computer program product comprising a machine readable medium, which may be non- transitory, storing a computer program of the fifth aspect of the invention.Brief Description of the Drawings

[0024] Certain embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings in which:

[0025] Figure 1 is a schematic block diagram of a robot system which includes a modular robot comprising a plurality of modules and a sever;

[0026] Figure 2 is an exploded, perspective view of a modular robot comprising a plurality of modules;

[0027] Figure 3 is a more detailed block diagram of the robot system shown in Figure 1; Figure 4 is a schematic block diagram of storage in a module;

[0028] Figure 5 is a schematic block diagram of a server;

[0029] Figure 6 is a process flow diagram of a method of commissioning a modular robot; Figure 7 is a process flow diagram of a method of setting up power when a module is attached to another module; and

[0030] Figure 8 is a process flow diagram of a method of initialisation when a module is attached to another module.

[0031] Detailed Description of Certain Embodiments

[0032] Referring to Figure 1, a modular robot system 1 is shown.

[0033] The modular robot system 1 comprises a modular robot 2 and a server 3.

[0034] The modular robot 2 (which may also be referred to as a "robotics platform" or simply "robot") comprises a plurality of modules 4 (which may also be referred to as "modular parts" or simply "parts", or "components"). Each module 4 has a given functionality, such as providing a linkage, a joint, a gripper, a scoop, a tool (for instance a drill or welding tool) and the like, and can include at least one actuator, such as a motor, and / or at least one sensor, such as a position sensor and / or camera. The modules 4 are interchangeable and are assembled to form the robot 2.

[0035] Each module 4 has an embedded digital twin 5 (in other words, stores a digital twin 5 of itself) which can be transmitted to another connected module 4 and forwarded to, for example, the server 3, where a digital twin 6 of the robot 2 can be constructed and stored.

[0036] Referring to Figure 2, an example of a modular robot 2 is shown,The robot 2 comprises a base 4, 4B;a first robotic linkage 4, 4LI, a second robotic linkage 4, 4L2, and a gripper 4, 4G. The first and second robotic linkages 4, 4LI, L2 form an articulated arm 7 between the base 4, B and gripper 4, 4G.

[0037] The modules 4 may be assembled in a linear series or chain between two ends, for instance, as in this case, between the base 4, 4B and gripper 4, G. Modules 4 may, however, be arranged in more complex arrangements, for example, such as an arrangement which includes at least one branch in which one module 4 is connected to at least three other modules 4. The robot 4 may be static or may be mobile.

[0038] Referring to Figure 3, the system 1 is shown in more detail.

[0039] Each module 4 may include one or more actuators 11, such as motors, and / or one or more sensors 12, such as a camera or position sensor

[0040] Each module 4 includes a power management unit 21 and at least one power interface 22 via which power can be transmitted to and / or from another module 4. In this example, the power interface(s) 22 is (are) wired. In some cases, however, the power interface(s) 12 may be wireless, and power may be delivered, for example, using inductive coupling.

[0041] Each module 4 includes at least one processor 31, memory 32 and storage 33 (for example in the form of non-volatile memory) storing the digital twin 5, and at one data interface 34 via which data is transmitted between modules 4. The data interface 34 may be wired and can take the form of an Ethernet-based fieldbus such as EtherCAT. Other forms of data interfaces may be used, such as USB. Furthermore, a power interface 22 and a data interface 34 may be integrated into a single interface, such as a USB interface. In some cases, the power interface 34 may be wireless and data can be exchanged via, for example, a short-ranged wireless technology, such as Bluetooth (RTM).

[0042] The digital twin 5 includes, among other things, information about electrical connectivity and power requirements for the module 4, information about software driver(s) (which may also be referred to as "software interface(s)") and / or suitable classes of device to use (such as linkage, battery, end effector, joint, mobile platform, camera and the like), a description of the capabilities of the module 4 in terms of sensors and actuators, an articulated 3D model that can be imported into a physics simulation, and calibration values of joints, sensors and other parts. Classes may bemore general (and so the number of classes may be quite small, say four to ten) or more specific (and so the number of classes may be larger).

[0043] The modules 4 confirm to one or more mechanical standards, such as ISO940-1:2004, which allows the modules 4 to be interchangeably attached.

[0044] The robot 2 is powered by at least one power supply 41. A power supply 41 may be mains powered. A power supply 41 may, however, harvest energy and may, for example, take the form of photovoltaic cells. A power supply 41 may be housed in one or more modules 4, in other words, on board the robot 2. A module 4 may include a battery (not shown).

[0045] As will be described in more detail hereinafter, the interfaces 22, 34 allow a module 4 to obtain enough power to establish the interface requirements of the module 4 and a protocol for further communication. The module 4 can then transfer at least some of the digital twin data to a connected device or module. This data can include information about electrical connectivity, power requirements, a software driver or suitable class of device to use, a description of the capabilities of the module in terms of sensors and actuators, an articulated 3D model that can be imported into a physics simulation and calibration values of joints, sensors and other related parts or systems.

[0046] Referring still to Figure 3, the robot 2 is connected to the server 3 via a router 43 via a wired or wireless link and via a network 44, such as a local-area network (LAN) or wide-area network (WAN).

[0047] The server 3 includes at least one processor 45, memory 46 and storage 47 storing the model 5 of the robot 2. The server 2 can reside on the local network or be hosted in a cloud service.

[0048] Referring also to Figure 4, a digital twin 5 is embedded in each module 4 and is held in storage 33.

[0049] The digital twin 5 includes a 3D model (or "solid model") 51, a physics simulation 52, application programming interfaces (APIs) 53, sensor data 54, calibration data 55 and in-field calibration data 56.

[0050] Storage 33 may also hold data which allows refinement of a network or output. For example, storage 33 may also hold low-rank adaptation (LoRA) extensions 57, andLoRA weights 58. Storage 33 may also hold cryptographic keys 59. The module 4 can use a cryptographic hash to sign and authenticate data. A distributed ledger or block¬ chain can be used. This can be used to establish that data was trusted when it was built by a manufacturer and to ensure that the record of changes made to the data, such as calibration values, are signed by the module 4 that recorded data during use and stored on the module.

[0051] Referring to Figure 5, the server 6 stores a 3D model 6 of the robot 2 that it has constructed from the models 5 provided by the modules 4. The server 6 also stores a foundation model 61 and LoRA extensions 62 for each module 4. Thus, in this case, the server stores a base LoRA extension 62B, a first linkage LoRA extension 62LI, a second linkage LoRA extension 62L2, and a gripper LoRA extension 62G.

[0052] Referring to Figure 6, a method of commissioning a robot 2 is shown.

[0053] As explained earlier, the robotic system 1 is built from a plurality of components 4 (or "modules"). Each module 4 includes a processor 31 that controls the digital interface and power management of the system 4. Before power-consuming components, such as servos 11 and sensors 12, are turned on, the module 4 goes through a bootstrap process.

[0054] As modules 4 are connected (step SO), each module 4 negotiates a power budget, via already-connected modules 4, with the server 3 before subsequent devices 4 in a daisy-chain are powered up (step SI). The power supply may be monitored or controlled by the server 3 via a protocol such as General Purpose Interface Bus (GPIB).

[0055] Referring also to Figure 7, a process by which the modules 4 powered up into a low power state will now be described.

[0056] The base module 4B powers up in a low-power state and the server 3 sends a initialisation instruction signal 71 to the base module B to initialise (step SI.1.1.1). The base module 4B returns power requirement data 72 including information about how many modules are connected to It which, in some cases, can be achieved without powering them up, for example, using resistors to ground (step SI.1.1.2). The server 3 responds with an instruction 73 to proceed and to power up the next module in the chain (step SI.1.1.3).The process is repeated for the next module, in this case first linkage module 4LI with signals 71, 72, 73 passing through the base module 4B (steps SI.1.2.1 to SI.1.2.3). The process is repeated for each module 4 2, 4G (steps SI.1.3.1 to SI.1.3.3 and steps SI. 1.4.1 to SI.1.4.3) until the last module 4G sends a report 74 that there are no more modules (step SI.2).

[0057] At this point, the modules 4 in the assembled robot 2 are in a low power state and able to communicate

[0058] Referring to Figure 8, a process of initiation will now be described.

[0059] The server 3 sends a request 75 to all of the connected modules 4 to send all or part of its embedded digital twin 5 (step S2.1). Each module 4 returns data 76 to the server 4 (steps S2.2.1 to S2.2.4).

[0060] The data 76 can include a 3D model 51 (Figure 4), physics simulation information 52 (Figure 4), API 53 (Figure 3), sensor information 54 (Figure 3), calibration information 55 (Figure 4) and in-field calibration day 56 (Figure 4) which may be cryptographically signed. The data 76 can include Al-related data such as adapter layers, LoRA and other Al models 57 (Figure 4), 58 (Figure 4) and / or control logic modules (not shown) for interfacing the module with a general robotic control system which resides on the server 3, such as a foundation Al model 61 (Figure 5). An example of such a foundation model is a Vision Language Action (VLA).

[0061] If there is insufficient storage space on the module for a LoRA or other Al model, the module can, instead, send instructions for downloading the model from an internet service, for example, in the form of a URI, torrenting magnet link or other resource locator.

[0062] The server 3 collates the information from the digital twins and builds a model 6 of the robot 2 (step S2.3) Based on the built model 6 of the robotic platform 2, the server 3 calculates a power budget 77 (step S2.4).

[0063] The power budget 77 allows the server 3 to determine how much power can be delivered to each module 4.

[0064] The server 3 also calculates the allowed data rate for each device 4 and sets the sensor data transmission regime, for example, periodic polling by the module, usingmemory mapping or by streaming data depending on capabilities. The server 3 may request modules to compile data and / or perform closed loop control depending on advertised capabilities.

[0065] The server 3 transmits respective information 78 about the allowed power budget to each module 4 (step S2.5.1). Once a module 4 receives its information 78, it sends acknowledgement message 79 (steps S2.6.1 to S2.6.4).

[0066] Referring again to Figure 7, the server 3 transmits respective information 80 which sets the allowed power for the module 4 (steps 3.1 to S3.3). This allows the module 4 to switch to a higher power modes. During use, a module 4 and / or server 3 can transmit a message (not shown) to report that the module 4 is not receiving enough power and / or to instruct the module 4 to use less power. A module 4 can identify a situation that it is not receiving enough power and may take measures to reduce power consumption and also to report this to the server 3.

[0067] Optionally, the digital twin documents can be signed with a cryptographic signature 59 such as public key using RFC 4880. Additionally or alternatively, blockchain can be used to create a distributed ledger (not shown) recording original manufacturers and changes to the modules.

[0068] If the server 3 monitors the movement of the system and finds that it does not respond as expected, then modifications to calibration data or the LoRA or other model can be made. This data can be stored in the device 4 and, optionally, signed with a public private key 59 or blockchain hash to ascertain the veracity of the device(s) that performed any changes or recalibration.

[0069] In this example, a robot arm is created from repeated units of the same intelligent joint module, that is linkage 4L. The repeated units are electronically the same, but the mounting, such as tube length, base and end effector connection, can differ from module to module. As such, the embedded digital twin 5 reflects the system 4 including the length of tube and mounting hardware. Any attached module or server system can build a model of the robot and transmit the whole to upstream systems or solve embodiment non-specific problems using the model that has been generated.A module 4 can be made from a single device or a conglomeration of suitable devices, for example a gripper and an arm. Thus, any digital twin 5 should reflect the structure of the module 4 and any relevant parameters.

[0070] As explained earlier, a device 3 can contain one or more motors, one or more sensors and / or one or more power sources. A sensor may take the form of a camera. Its digital twin data can be used to tell a device with which it is interfaced what to expect from the sensor in a 3D simulation and how to interact with the sensor. Typical sensors such as cameras, touch sensors and accelerometers can be simulated in 3D simulation environments and data is transferred based on manufacturing specification, manufacturing calibration & in-the-field calibration data.

[0071] A base 4G for the platform 2 can serve as hub for the rest of the platform. The base 4G can transfer not only a digital twin data to the server, but to the body. Data for the platform 2 can be processed onboard or transferred to a robot controller processing system (not shown) that could be connected by wire or wirelessly, or be instantiated in the cloud.

[0072] The modules 4 are able to transmit their embedded digital twin data and to accept proposed updates to the digital twin. The data includes a 3D model of the device, including where it is connected and what its requirements are in terms of power and voltage via connections, as well as the types and format of sensory data that can be incorporated into a physics simulation model by the recipient.

[0073] It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of robotic systems and component parts thereof and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.

[0074] Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present invention also includes any novel features or any novel combination of features disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated tosuch features and / or combinations of such features during the prosecution of the present application or of any further application derived therefrom

Claims

Claims1. A module for a modular robot, wherein the module is configured to store a digital twin of the module and, in response to determining that the module has been connected to another module, to transmit at least part of the digital twin to the other module.

2. The module of claim 1, wherein the digital twin includes:■ a three-dimensional model of the module;■ a set of physical simulation parameters; and■ an application programming interface including an interface for controlling the module.

3. The module of claim 2, wherein the physical simulation parameters includes information about mass, a centre of mass and an inertia tensor for the module.

4. The module of claim 2 or 3, wherein the physical simulation parameters includes, for each moving part of the module, information about a pivot point, degree of freedom angles, and limit(s) of movement.

5. The module of claim 2, 3 or 4, wherein the three-dimensional model includes, for each sensor of the module, information about the sensor and the position of the sensor.

6. The module of claim 2, wherein the at least part of the digital twin comprises:■ power budget;• pivot points; and■ information about sensor(s).

7. The module of claim 1 or any one of claims 2 to 6, wherein the module comprises:■ at least one power interface;■ at least one data interface;■ at least one processor; and■ non-volatile memory storing the digital twin of the module.

8. The module of claim 1 or any one of claims 2 to 6, wherein the module is configured, in response to being connected to a further module and receiving at least part of a further digital twin from the further module, to forward the at least part of the third digital twin to the other module.

9. The module of claim 1 or any one of claims 2 to 6, wherein the module is configured, in response to determining that the module has been connected to another module, prior transmitting the at least part of the digital twin, to transmit power requirement to the other module.

10. The module of claim 1 or any one of claims 2 to 9, wherein the module is configured to store sensor data.

11. The module of claim 1 or any one of claims 2 to 10, wherein the module is configured to store calibration data.

12. The module of claim 1 or any one of claims 2 to 11, wherein the module is configured to store in-field calibration data.

13. The module of claim 1 or any one of claims 2 to 12, wherein the module is configured to store data which allows refinement of a foundation model.

14. The module of claim 13, wherein the data comprises LoRA extensions.

15. The module of claim 13 or 14, wherein the data comprises LoRA weights.

16. The module of claim 1 or any one of claims 2 to 15, wherein the module is configured to store cryptographic keys.

17. A modular robot comprising:■ a plurality of connected modules including the module of claim 1 or any one of claims 2 to 16.

18. A system comprising:■ the modular robot of claim 17; and■ a server storing a digital twin of the modular robot;wherein the modular robot is communicatively linked to the server.

19. A method, comprising:a module for a modular robot, in response to determining that the module has been connected to another module, transmitting at least part of a digital twin stored in the module to the other module20. A computer program which, when executed by at least one processor in a module, cause the at least one processor to perform the method of claim 19.

Images