Module for a modular robot

Abstract

Module for a modular robot 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. The module is configured to store a set of cryptographic keys and to sign at least part of the digital twin and / or a hash of at least a part of the digital twin using a cryptographic key in a set of cryptographic keys.

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] US 9 475 199 B2 describes a robotic manipulator arm. The arm includes joints that are attachable and detachable in a tool-free manner via a universal mating adapter. The universal mating adapter includes a built-in electrical interface for an operative electrical connection upon mechanical coupling of the adapter portions. The universal mating adapter includes mechanisms and the ability to store and communicate parameter configurations such that the joints can be rearranged for immediate operation of the arm without further reprogramming, recompiling, or other software intervention.

[0008] 180220PCT1Summary

[0009] According to a first aspect of the present invention there is provided a module for a modular robot. 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. The module is configured to store a set of cryptographic keys and to sign at least part of the digital twin and / or a hash of at least a part of the digital twin using a cryptographic key in the set of cryptographic keys.

[0010] Sharing a digital twin can allow a better description of the robot to be constructed which can help enable automatic commissioning of the robot. Signing can help to ensure that an assembled modular robot is safe and is operated safely, for example, by verifying providence of modules, enforcing standards and protocols, and keeping a verifiable audit of robot commissioning and robot operation.

[0011] The set of cryptographic keys may include a public-private key pair for the module.

[0012] The module is configured to authenticate at least part of a digital twin and / or a hash of at least a part of a digital twin of another module using another cryptographic key of the cryptographic keys. The set of cryptographic keys may include a public key of the other module and / or of one of more other modules.

[0013] The digital twin may include a three-dimensional model of the module, a set of physical simulation parameters and / or an application programming interface including an interface for controlling the module. The digital twin may include data added after manufacture, such as re-calibration data, service record data and data relating to decommissioning.

[0014] The three-dimensional model can be used to automatically build a three-dimensional model of the system to establish the position of modules relative to each other, for instance, for reproducing simulated versions of camera views and the like.

[0015] 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.

[0016] The set of physical simulation parameters can be used to independently calculate the suitability of the system for a task and / or to establish the response of the system toinputs. The parameters can be used for monitoring module usage or wear for scheduling services or preventative maintenance.

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

[0018] The application programming interface may be used independently when controlling a module that is significantly sensor based, such as a sonar range finder

[0019] 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.

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

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

[0022] 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.

[0023] 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.

[0024] 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 module.

[0025] 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.

[0026] The digital twin may be an encrypted digital twin and access to the encrypted digital twin may be controlled using a blockchain contract. Blockchain contracts may be used to control decryption of an encrypted digital twin or part thereof. This can enablecontrolled access and so allow access via a subscription and / or allow updates. The blockchain contract may be stored using the blockchain. Blockchain contracts may receive information from blockchain oracles. The module may be configured, in response to receiving a request from another module, to send the encrypted digital twin to the other module for unlocking.

[0027] 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.

[0028] 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.

[0029] The server may be a remote server. For example, the robot and server may be connected by the Internet or other network.

[0030] The server may be a local server. Thus, the robot may operate as a self-contained network. The robot may, in that case, run offline and / or as an air-gapped network.

[0031] The robot may be temporarily connected to the server or to another, different server (for example, via a network, such as the Internet), for instance, to allow updates to software, parameters or other data.

[0032] The digital twin may form part of a larger or more complete digital twin (or "comprehensive digital twin"). Another part or other parts of the comprehensive digital twin may be stored remotely to the robot in one or more different locations. Other parts of the comprehensive digital twin may be downloaded on demand.

[0033] 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.

[0034] 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.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.

[0035] According to a seventh aspect of the present invention there is provided a method comprising adding data relating to a module for a modular robot to the module, generating a digital signature using the data and a private key and adding the digital signature to a block of a distributed blockchain ledger.

[0036] This can help to trace the source of the data.

[0037] The method may further comprise adding at least part of a digital twin to the block of the distributed blockchain ledger.

[0038] The method may be performed by a manufacturer of the module. The method may be performed by an entity after manufacturer of the module, such as a robot controller or computer system receiving inputs from a technician.

[0039] According to an eighth aspect of the present invention there is provided a method comprising receiving, by a modular robot controller, data relating to a module of a modular robot, retrieving a digital signature corresponding to the data from a distributed blockchain ledger; and authenticating the data using the digital signature and a public key

[0040] The data may include a hash of at least part of a digital twin.Brief Description of the Drawings

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

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

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

[0044] 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;

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

[0046] 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;

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

[0048] Figure 9 illustrates a blockchain-based digital twin;

[0049] Figure 10 illustrates addition of digital signatures to a blockchain;

[0050] Figure 11 illustrates generating a digital signature for manufacturer;

[0051] Figure 12 illustrates a server authenticating a blockchain during initialisation; and Figure 13 illustrates authenticating a digital signature of a manufacturer.

[0052] Detailed Description of Certain Embodiments

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

[0054] The modular robot system 1 comprises a modular robot 2 and a server 3 (or "control system").

[0055] 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.

[0056] 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 and which can be used to control an assembled robot 2.

[0057] Data relating to the digital twin 5, to the modules 4 and / or to related entities (such manufacturers and installers) may be referenced inside a blockchain 80 (Figure 9).

[0058] As will be explained in more detail hereinafter, the server 3 can use the blockchain 80, among other things, to identify provenance of a module (for instance, the manufacturer), its service history, certify calibration data and the like.

[0059] Referring to Figure 2, an example of a modular robot 2 is shown.

[0060] 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, 4L2 form an articulated arm 7 between the base 4, 4B and gripper 4, 4G.

[0061] 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, 4G. 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.

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

[0063] 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

[0064] 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.

[0065] 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, apower 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).

[0066] 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 be more 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). The digital twin 5 may include data added after manufacture, such as re-calibration data, service record data and data relating to decommissioning.

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

[0068] 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).

[0069] 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.

[0070] 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).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.

[0071] The server 3 is connected to a blockchain authentication network 48 comprising a network of blockchain servers 49.

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

[0073] 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.

[0074] 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, and LoRA weights 58. Storage 33 may also hold cryptographic keys 59. For example, the cryptographic keys 59 may include public and private keys for the module 5. Thus, a module 4 can sign at least part of the digital twin 5 and / or a hash of at least a part of the digital twin using a cryptographic key, in particular, the private key. The cryptographic keys 59 may include public keys of one or more other modules.

[0075] The module 4 can use a cryptographic hash to sign and authenticate the digital twin 5 or part of the digital twin 5, and other data. A distributed ledger or blockchain can be used. This can be used to establish that a digital twin or other 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.

[0076] 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.

[0077] Referring to Figure 6, a method of commissioning a robot 2 is shown.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.

[0078] 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).

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

[0080] The base module 4B powers up in a low-power state and the server 3 sends an initialisation instruction signal 71 to the base module 4B 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).

[0081] 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 4L2, 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).

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

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

[0084] 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 3 (steps S2.2.1 to S2.2.4).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).

[0085] 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.

[0086] 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).

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

[0088] 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, using memory 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.

[0089] 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).

[0090] 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 mode. 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.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.

[0091] 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 another 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.

[0092] 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.

[0093] 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.

[0094] 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 8i in-the-field calibration data.

[0095] 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.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.

[0096] Referring to Figures 3 and 9, the control system 3 or other part of the system 1 can use the blockchain 80, for example, to determine whether a module 4 is genuine or compatible with other modules 4.

[0097] The blockchain 80 includes a list of blocks (or "records") 81, 81i, 8I2, 8I3, 8I4 comprising a previous hash or, in the case of the first block, a genesis block 82, data 83 which may take the form of the digital twin, calibration production test data, LORA weights etc., a signature 84 and a public key (PK) 85, a consensus 86 (e.g., number used once, or "nonce") and a hash 87 generated from previous hash 82, data 83 and public key 85.

[0098] Referring to Figure 10, entities 101 may manufacture, modify or process modules 4 for a module robot 2. In the following example, the entities 101 are manufacturers. However, an entity may be a controller, a module or computer system.

[0099] A manufacturer 101, 1011, 101 may manufacture modules 4 for a modular robot 2. The manufacturer 101 can store a digital twin 5 of the module 4 in the module 4.

[0100] The genesis block 81, 81G can be created once by a trusted body (such as company standards organisation) or referenced from another public blockchain. The blockchain 80 can be shared across all manufacturers 101 and uploaded at module build time or module calibration time. In particular, the manufacture 101 can add the digital signature 84 and a public key 85 (which may be the public key of the manufacturer or a key specific to the module).

[0101] Referring also to Figure 11, the digital signature 84 is obtained using encrypting the hash 88 of data 89 using the secret key (SK) 90 (also known as a "private key") which corresponds to the public key 85.

[0102] Given that the robot 2 is modular and each module 5 can occupy a limited number of branches on a Merkle tree structure, the robot 2 can take advantage of the Merkle tree data structure, in other words, reduce the amount of data stored.Referring also to Figures 3, 8, 12 and 13, during initiation, the control system 3, having collated the information from the modules 4 and built a model 6 of the robot 2 (step S2.3), can authenticate the digital signatures 84 of the module(s) using the blockchain authentication network 48 using the public key to obtain a result true or false (step S2.3A). Once authenticated, the server 3 calculates the power budget 77 (step S2.4).

[0103] Each module 5 can have specific blocks 81 that encapsulate its digital twin. Data need not be repeated unnecessarily, but a hash pointer can be used to point to the same 3D model for every instance of a particular product.

[0104] Calibration data specific to the module can also be encoded into a block 81.

[0105] A digital signature on a hash pointer means that a secret key is used to encrypt the data. The public key can confirm that the data is correct and identify the identity of the signatory. This means that when a module uploads any data (which can be a part of digital twin), it has an audit trail back to the producer of that data.

[0106] 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.

[0107] All or part of the digital twin may be encrypted. Blockchain contracts may be used to control decryption of an encrypted digital twin or part thereof. This can enable controlled access and so allow access via a subscription and / or allow updates.

[0108] Not all modules need store a digital twin. For example, a module which does not store its own digital twin may be an aggregator, such as base or other node to which modules can be connected, and / or a server (which can operate as a control system) connected to a module which has a digital twin. The aggregator may contain the server. The server may be used to collect and / or build a complete digital twin (or "comprehensive digital twin") of the robot.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 to such 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, wherein the module is configured to store a set of cryptographic keys and to sign at least part of the digital twin and / or a hash of at least a part of the digital twin using a cryptographic key in the set of cryptographic keys.

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 / or■ an application programming interface including an interface for controlling the module.

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

4. The module of claim 2 or 3, wherein the physical simulation parameters include, for each moving part of the module, information about a pivot point, degree of freedom angles, and / or 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 / or 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 / or■ 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 7, 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 8, 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 digital twin is stored using a blockchain.

17. The module of claim 1 or any one of claims 2 to 16, wherein the digital twin is an encrypted digital twin and access to the encrypted digital twin is controlled using a blockchain contract.

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

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

20. 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.

21. 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 20.

22. A method, comprising:■ adding data relating to a module for a modular robot to the module;■ generating a digital signature using the data and a private key; and■ adding the digital signature to a block of a distributed blockchain ledger.

23. The method of claim 22, further comprising:■ adding at least part of a digital twin to the block of the distributed blockchain ledger.

24. A method, comprising:■ receiving, by a modular robot controller, data relating to a module of a modular robot;■ retrieving a digital signature corresponding to the data from a distributed blockchain ledger; and■ authenticating the data using the digital signature and a public key.

25. The method of claim 24, wherein the data includes a hash of at least part of a digital twin.

Images