A loading method for dynamic capability configuration of home embodied intelligent robots

Abstract

This application provides a method for loading dynamic capability configurations for a home-based embodied intelligent robot, comprising: Step 1: In response to a new hardware access signal, performing local hardware pairing and service registration; after the pairing and service registration are successful, retrieving a dynamic capability extension package corresponding to the accessed hardware, containing capability execution logic and interface configuration requirements, from a preset capability repository, and generating a global capability mapping table recording component installation status and hardware / software interface occupancy information based on the dynamic capability extension package; Step 2: In response to a received task instruction, performing capability retrieval in the global capability mapping table to determine the hardware readiness status and installation status corresponding to the target logic component required for the task to be executed, and then performing on-demand installation and data loading processing on hardware that meets preset criteria to produce a set of loaded capabilities containing the running entity of the target logic component.

Description

Technical Field

[0001] This application relates to the field of intelligent robot technology, and more specifically, to a method for loading dynamic capability configurations for a home-based embodied intelligent robot. Background Technology

[0002] With the rapid development of smart home technology, embodied intelligent robots for the home need to perform diverse tasks in complex and ever-changing home environments, such as cleaning, companionship, security, and entertainment. To adapt to different task requirements, robots typically need to dynamically connect to various hardware modules (such as robotic arms, sensors, and cleaning components) and load corresponding software capabilities, which places high demands on the robot's capability configuration and resource management.

[0003] In existing robot capability configuration schemes, a common approach is to use preset static configurations. This scheme first pre-installs fixed functional modules and drivers when the robot leaves the factory; then, when new functions are needed, users must manually download and install the corresponding software packages, which may require restarting the robot; finally, the new functions can be invoked by the robot. This configuration method achieves functional expansion to a certain extent, but it has obvious technical drawbacks. Due to the variable needs of the home environment, preset configurations cannot cover all task scenarios, and the manual installation process is cumbersome and dependent on user operation, resulting in poor real-time performance and flexibility of functional expansion. At the same time, statically installed drivers and software packages continue to occupy robot resources after the task is completed, failing to release them in a timely manner, causing resource waste and reducing the overall operating efficiency of the robot. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method for loading dynamic capability configurations for home-based embodied intelligent robots, thereby at least alleviating the aforementioned technical problems.

[0005] A method for loading dynamic capability configurations for a home-based embodied intelligent robot, comprising: Step 1: In response to the new hardware access signal, perform hardware pairing and service registration locally; after the pairing and service registration are successful, retrieve the dynamic capability extension package corresponding to the accessed hardware from the preset capability repository, which contains capability execution logic and interface configuration requirements, and generate a global capability mapping table based on the dynamic capability extension package, which records the component installation status and software and hardware interface occupancy information. Step 2: In response to the received task instruction, perform a capability retrieval in the global capability mapping table to determine the hardware readiness status and installation status of the target logic component required for the task to be executed. Then, perform on-demand installation and data loading processing on the hardware that meets the preset criteria to produce a set of loaded capabilities containing the running entity of the target logic component.

[0006] Optionally, the method further includes: Step 3: Retrieve the already loaded capability set, and based on the dynamic capability extension package associated with the already loaded capability set, perform service reconfiguration processing and service loading processing for the target logical component, so as to activate the target logical component and establish an instruction interaction link occupying the software and hardware interfaces according to the interface configuration requirements; Step 4: Monitor the execution status of the target logic component in real time, and in response to the task end signal, perform on-demand unloading processing for the service, the hardware, and the software and hardware interfaces to close the instruction interaction link, release the software and hardware interfaces and hardware resources occupied by the instruction interaction link, and reclaim the released resources to the preset local capability repository.

[0007] Optionally, the global capability mapping table generated in step 1 includes a type field for distinguishing the source of capability or the location of hardware deployment, a hardware ready field for recording the physical connection status of hardware, an installation status field for recording the loading process of logical components, and an interface configuration field corresponding to the interface configuration requirements; wherein, the type field is specifically distinguished into a cloud type that represents capability stored in the cloud and a local type that represents capability dependent on local hardware.

[0008] Optionally, for entries whose type field is marked as cloud-type, since they do not depend on local physical hardware, the hardware ready field is uniformly recorded as an un-added state indicating that the hardware is not connected, the installation status field is recorded as not installed, and the interface configuration field records the interface type required for communication with the cloud service; for entries whose type field is marked as local-type, if the hardware ready field is recorded as an added state indicating that the corresponding hardware has been connected and paired, then the installation status field is recorded as an un-installed state indicating that the logical components have not yet been loaded.

[0009] Optionally, for entries where the type field is of the local type, if the installation status field records an "installed" entry indicating that the logical component has been loaded, the installation status field further includes an unloadable tag or a non-unloadable tag to identify whether the component can be dynamically recycled after the task ends. Simultaneously, the content recorded in the interface configuration field is updated from a static interface type to real-time occupancy information for the software and hardware interfaces, indicating which component or process is currently occupying them. The software and hardware interfaces include a software logic interface for data interaction and a physical hardware interface for connecting physical devices.

[0010] Optionally, before obtaining the dynamic capability extension pack in step 1, the method further includes: The robot's current functions are monitored and summarized in real time to form a set of functional features. The set of functional features is then compared with a task target model that represents the capabilities required to complete the task, either parsed from the task instructions or preset locally, in order to identify whether the robot currently lacks local capabilities. If a local capability deficiency is determined, the computing resources are driven to search for capability items that match the local capability deficiency in the preset cloud capability warehouse, and after the search is successful, a configuration request information containing the capability item identifier is sent to the management terminal corresponding to the user terminal or management backend. In response to the configuration request being approved by the management terminal and the corresponding dynamic capability extension package being successfully downloaded from the cloud capability warehouse and stored in the local storage space, hardware discovery and storage processing for the hardware corresponding to the dynamic capability extension package are automatically triggered so that the robot can perceive the new hardware access and thus proceed to step 1.

[0011] Optionally, the service registration process in step 1 includes the following steps: The component resolver is used to parse the dynamic capability extension package and extract capability metadata, which includes the capability activation status (whether the capability can be activated at present) and logical component attributes describing its functional attributes. The extracted capability metadata is written into the global capability mapping table, which records the online capability sub-table for currently schedulable services, and the logical component reserve sub-table for storing components to be installed, based on the capability activation status and the logical component attributes, thereby completing the service registration of the capability corresponding to the newly connected hardware.

[0012] Optionally, step 2, performing the on-demand installation process, includes the following steps: Extract the set of environment variables containing environment variables from the dynamic capability extension package to define the software running parameters, and inject the set of environment variables into an isolated sandboxed running environment to configure the various runtime parameters required for the operation of the target logic component in the sandboxed running environment; Using a virtual environment management engine, based on the resource requirements of the target logical component, the computing power quota of the processor computing resources and the allocation of memory space are performed for the target logical component in the sandboxed running environment, thereby completing the installation action of allocating exclusive physical hardware resources to the target logical component.

[0013] Optionally, the service reconfiguration process in step 3 includes the following steps: Extract the predefined component communication configuration from the dynamic capability extension package associated with the retrieved already loaded capability set; The dynamic loading engine parses the extracted component communication configuration and, based on the parsed component communication configuration information, establishes a data acquisition path for obtaining data from the target logical component and an instruction delivery path for sending control instructions to the target logical component locally. Based on the interface mapping relationship between the target logical component and the physical world determined by the interface configuration field in the global capability mapping table, the mapping and binding operation of the physical hardware interface and the software logical interface in the software and hardware interfaces is performed, thereby fully activating the instruction interaction link used for interaction between components and between components and hardware.

[0014] Optionally, step 4, performing the on-demand uninstallation process, includes the following steps: During and after the task execution, the skill reference count is monitored in real time to quantify how many active tasks or processes use the target logic component, and it is continuously determined whether the skill reference count has returned to zero. If the skill reference count is determined to be zero and the task instruction that triggered this uninstallation process has been executed, then the cancellation operation of all software handles of the target logic component is immediately executed, and the occupation state of the target logic component on the software and hardware interface is released simultaneously to close the instruction interaction link, thereby releasing the software and hardware interface and hardware resources occupied by the instruction interaction link back to the preset local capability repository.

[0015] Optionally, the method further includes: Throughout the entire lifecycle of the target logical component from loading to unloading, the events and states generated during the runtime of the target logical component are continuously recorded to form a runtime log. After the task is completed, all relevant runtime logs are encapsulated into an execution audit payload containing metadata, which can be parsed externally and has self-interpretation capabilities. The encapsulated execution audit payload is synchronized to the remote audit server via a secure link, so that the remote audit server can trace and supervise the entire process of the target logic component from hardware access, installation, configuration to uninstallation based on the execution audit payload.

[0016] Technical advantages of the technical solution provided in this application This application presents a method for loading dynamic capabilities for embodied intelligent home robots. Addressing the technical shortcomings of traditional static configuration schemes, such as cumbersome operation, poor real-time performance, and low resource utilization, this method automatically performs hardware pairing and service registration in response to new hardware access signals, and acquires the corresponding dynamic capability extension package. This solves the problems of manual downloading and installation by users and operational delays in traditional solutions. Compared to traditional methods that rely on user intervention, this application achieves automated discovery and acquisition of new hardware capabilities, enabling the robot to respond quickly to hardware access and significantly improving the real-time performance of functional expansion.

[0017] A global capability mapping table is generated based on dynamic capability extension packages, recording component installation status and hardware / software interface occupancy information. This solves the problems of scattered hardware and software resource management and opaque status in traditional solutions. In traditional solutions, hardware drivers and software functions are usually stored separately, requiring traversal and searching during retrieval. However, the global capability mapping table in this application centrally manages hardware readiness status, software installation status, and interface configuration, providing a unified data view for subsequent task-driven capability retrieval. Compared to the scattered management method, retrieval efficiency and accuracy are significantly improved.

[0018] In response to task instructions, the system retrieves the hardware readiness and installation status of the target logic component from the global capability mapping table. Then, for hardware that meets preset criteria, it performs on-demand installation and data loading, producing a set of loaded capabilities containing the running entity of the target logic component. This process changes the traditional model of pre-installed and long-term occupied functions, achieving dynamic binding between capabilities and tasks. Installation and loading only occur when the task requires them and the hardware is ready, avoiding the ineffective occupation of robot resources by irrelevant functions and resulting in better resource utilization. Simultaneously, on-demand installation allows the robot to flexibly respond to diverse task requirements, enhancing its adaptability to task changes. Attached Figure Description

[0019] Figure 1 This application provides an embodiment of a method for loading dynamic capability configurations for a home-based embodied intelligent robot.

[0020] Figure 2 This application provides a loading device for dynamic capability configuration of a home-based embodied intelligent robot, as an embodiment of the present application.

[0021] Figure 3 This is an electronic device according to an embodiment of the present application. Detailed Implementation

[0022] like Figure 1 The image shows a method for loading dynamic capability configurations for a home-based embodied intelligent robot, according to an embodiment of this application, comprising: Step 1: In response to the new hardware access signal, perform hardware pairing and service registration locally; after the pairing and service registration are successful, retrieve the dynamic capability extension package corresponding to the accessed hardware from the preset capability repository, which contains capability execution logic and interface configuration requirements, and generate a global capability mapping table based on the dynamic capability extension package, which records the component installation status and software and hardware interface occupancy information. Step 2: In response to the received task instruction, perform a capability retrieval in the global capability mapping table to determine the hardware readiness status and installation status of the target logic component required for the task to be executed. Then, perform on-demand installation and data loading processing on the hardware that meets the preset criteria to produce a set of loaded capabilities containing the running entity of the target logic component. Step 3: Retrieve the already loaded capability set, and based on the dynamic capability extension package associated with the already loaded capability set, perform service reconfiguration processing and service loading processing for the target logical component, so as to activate the target logical component and establish an instruction interaction link occupying the software and hardware interfaces according to the interface configuration requirements; Step 4: Monitor the execution status of the target logic component in real time, and in response to the task end signal, perform on-demand unloading processing for the service, the hardware, and the software and hardware interfaces to close the instruction interaction link, release the software and hardware interfaces and hardware resources occupied by the instruction interaction link, and reclaim the released resources to the preset local capability repository.

[0023] Optionally, the global capability mapping table generated in step 1 includes a type field for distinguishing the source of capability or the location of hardware deployment, a hardware ready field for recording the physical connection status of hardware, an installation status field for recording the loading process of logical components, and an interface configuration field corresponding to the interface configuration requirements; wherein, the type field is specifically distinguished into a cloud type that represents capability stored in the cloud and a local type that represents capability dependent on local hardware.

[0024] Preferably, when generating the global capability mapping table based on the dynamic capability extension package in step 1, its multiple core fields are constructed in the following manner: First, the obtained dynamic capability extension package is deeply parsed to extract the type identifier describing the source of the capability or the required hardware deployment location, the hardware connectivity identifier describing the current physical connection status of the corresponding hardware, the component installation progress identifier describing the loading progress of the logical component, and the interface parameter description corresponding to the interface configuration requirements. Then, these extracted information are organized according to a preset field structure to generate the global capability mapping table. Each entry in this mapping table corresponds to an accessed or accessible capability item, and its fields are designed as follows: The type field is used to distinguish the source of a capability item, and its value is derived from the parsing of capability metadata in the dynamic capability extension package. Specifically, when the parsed capability metadata indicates that all the logic and resources required for the operation of the capability are stored in a remote cloud and do not depend on local physical hardware, the type field of the entry is marked as cloud type; conversely, if the capability metadata indicates that the execution of the capability must depend on specific locally accessed physical hardware (such as robotic arms, sensors, etc.), the type field of the entry is marked as local type. This type field provides the primary filtering basis for subsequent capability retrieval and resource scheduling.

[0025] The hardware ready field is used to record in real time whether the corresponding hardware has been physically connected and completed basic pairing. For entries with a cloud-type type field, since local hardware is not involved, this field is uniformly preset to indicate that the hardware is not connected and is not yet in the database, and usually remains unchanged throughout its lifecycle. For entries with a local type field, the initial value of this field depends on the result of the hardware pairing process in step 1: if the corresponding hardware is successfully detected and paired in step 1, the field is set to indicate that the hardware is connected and in the database; if the hardware is not yet connected or pairing fails, it is set to not in the database. This field will be dynamically updated in subsequent hardware hot-plug events to reflect real-time changes in the physical connection status of the hardware.

[0026] The installation status field is used to record whether the logical component corresponding to the capability item has been loaded locally. When all capability items are first generated as mapping table entries, their installation status field is initialized to "not installed," indicating that the logical component has not yet been loaded. In subsequent step 2, after the on-demand installation process for the target logical component is successfully performed, this field will be updated to "installed," indicating that the logical component has been loaded. Furthermore, an uninstallable or non-uninstallable tag can be attached to indicate whether the component can be dynamically recycled after the task ends.

[0027] The interface configuration field stores detailed interface parameters corresponding to the interface configuration requirements. The content of this field also originates from the parsing of the dynamic capability extension package. For cloud-type entries, this field records the interface type required for remote communication with cloud services, such as network protocol type, endpoint address, and authentication method. For local-type entries, this field records the software and hardware interface mapping relationship required for interaction with local physical hardware, including the specific identifiers of the involved software logic interfaces (such as device file paths and API function signatures) and physical hardware interfaces (such as GPIO pin numbers and I2C bus addresses). As the capability loading status evolves, the content of this field will gradually update from a static interface type description to dynamic information reflecting the current real-time occupancy status, such as the identifier of the component or process currently occupying the interface, thereby providing an accurate interface status view for establishing the instruction interaction link.

[0028] The global capability mapping table constructed in the above manner organically integrates capability source type, hardware readiness status, component installation progress, and interface configuration parameters, providing a unified and structured data foundation for capability retrieval, on-demand installation, service configuration, and resource recycling in subsequent steps.

[0029] Optionally, for entries whose type field is marked as cloud-type, since they do not depend on local physical hardware, the hardware ready field is uniformly recorded as an un-added state indicating that the hardware is not connected, the installation status field is recorded as not installed, and the interface configuration field records the interface type required for communication with the cloud service; for entries whose type field is marked as local-type, if the hardware ready field is recorded as an added state indicating that the corresponding hardware has been connected and paired, then the installation status field is recorded as an un-installed state indicating that the logical components have not yet been loaded.

[0030] Preferably, when assigning values ​​to fields of different types of entries in the global capability mapping table, the specific processing logic distinguishes between the following two scenarios: On the one hand, for entries whose type field is marked as cloud-based, since their corresponding capabilities are entirely hosted in the remote cloud and their execution does not depend on any locally connected physical hardware, a special field initialization operation is performed when generating the entry. Specifically, after parsing the dynamic capability extension package and identifying its type as cloud-based, the robot uniformly assigns the hardware-ready field to a state of not being loaded into the database, indicating no hardware dependency. This state remains fixed throughout the entire lifecycle of the entry and will not be updated due to hardware hot-plug events. Simultaneously, the installation status field is assigned a value of not installed, indicating that the logical components of the cloud capability have not yet been loaded locally. Furthermore, the robot extracts the communication parameters required for interaction with the cloud service from the dynamic capability extension package, including network transmission protocol type, cloud service endpoint address, and interface call authentication method, and structures these parameters into the interface configuration field to form an interface type record required for communication with the cloud service. Through the above initialization operations, cloud-based entries are clearly identified in the global capability mapping table as a capability item with "no hardware dependency, awaiting remote invocation."

[0031] On the other hand, for entries marked as local type in the type field, their field assignments are closely related to the actual hardware access status. When the robot detects that the corresponding hardware has been successfully accessed and the pairing process in step 1 has been completed, the hardware ready field is updated to indicate that the hardware is ready for storage. In this state, the robot performs an initialization assignment on the installation status field, recording it as not installed, indicating that although the hardware is ready, the corresponding logical components have not yet been loaded into the operating environment. At the same time, the robot parses the underlying interface parameters required for interaction with the local hardware from the dynamic capability extension package, such as device file path, hardware abstraction layer interface identifier, physical pin mapping relationship, etc., and writes these parameters into the interface configuration field to form an interface type record required for interaction with the physical world. If the hardware ready field remains not stored due to hardware not being accessed or pairing failure, the installation status field remains empty or invalid until the hardware is ready before subsequent installation operations can be performed. Through this associated assignment mechanism, local type entries are dynamically reflected in the global capability mapping table as a "hardware dependent, waiting for software loading" capability item, and its status evolves in real time with hardware access events.

[0032] Optionally, for entries where the type field is of the local type, if the installation status field records an "installed" entry indicating that the logical component has been loaded, the installation status field further includes an unloadable tag or a non-unloadable tag to identify whether the component can be dynamically recycled after the task ends. Simultaneously, the content recorded in the interface configuration field is updated from a static interface type to real-time occupancy information for the software and hardware interfaces, indicating which component or process is currently occupying them. The software and hardware interfaces include a software logic interface for data interaction and a physical hardware interface for connecting physical devices.

[0033] Preferably, when the hardware corresponding to an entry with a local type in the type field has completed the on-demand installation process in step 2, and the running entity of the target logical component has been successfully loaded into the runtime environment, the robot performs a status update operation for that entry. Specifically, firstly, the installation status field is updated from "not installed" to "installed," indicating that the logical component has been loaded. Simultaneously, the robot parses the policy configuration related to the lifecycle management of the component from the metadata of the dynamic capability extension package, such as whether the component belongs to the robot's basic services, whether it supports hot-plugging and unloading, etc., and attaches a corresponding uninstallable or non-uninstallable tag to the installation status field according to the parsing result. The uninstallable tag is used to identify that the component can be dynamically recycled to release resources after the corresponding task ends, which is suitable for temporary functional components; the non-uninstallable tag indicates that the component is a resident service component, which needs to remain loaded even after the task ends to provide continuous service or be quickly reused for subsequent tasks. This tagging process provides a direct basis for the on-demand unloading decision in step 4, enabling the resource recycling strategy to be executed differently according to the attributes of different components.

[0034] Preferably, after the target logic component is successfully loaded and activated, the robot synchronously performs a dynamic update operation on the interface configuration field. First, it extracts the detailed definitions of the software and hardware interfaces required for the component's operation from the dynamic capability extension package. This includes software logic interfaces for data interaction (such as socket addresses, shared memory identifiers, API function pointers, etc. for inter-process communication) and physical hardware interfaces for connecting physical devices (such as GPIO pin numbers, I2C bus addresses, serial port device paths, etc.). Then, after the target logic component completes the instruction interaction link establishment and begins occupying the corresponding interface, the robot writes the component identifier or process identifier currently occupying these interfaces into the interface configuration field in real time. This updates the field content from the initial static interface type description to real-time occupancy information for the software and hardware interface, indicating which component or process is currently occupying it. This dynamic update mechanism not only provides an accurate view of the interface busy status for subsequent tasks when retrieving the global capability mapping table, effectively avoiding interface conflicts, but also provides a clear basis for accurately releasing interface occupancy and resources during the on-demand unloading process in step 4. In this way, the interface configuration fields remain consistent with the actual occupancy status throughout the entire capability lifecycle, providing reliable data support for the refined management of robot resources and the stable operation of the command interaction link.

[0035] Optionally, before obtaining the dynamic capability extension pack in step 1, the method further includes: The robot's current functions are monitored and summarized in real time to form a set of functional features. The set of functional features is then compared with a task target model that represents the capabilities required to complete the task, either parsed from the task instructions or preset locally, in order to identify whether the robot currently lacks local capabilities. If a local capability deficiency is determined, the computing resources are driven to search for capability items that match the local capability deficiency in the preset cloud capability warehouse, and after the search is successful, a configuration request information containing the capability item identifier is sent to the management terminal corresponding to the user terminal or management backend. In response to the configuration request being approved by the management terminal and the corresponding dynamic capability extension package being successfully downloaded from the cloud capability warehouse and stored in the local storage space, hardware discovery and storage processing for the hardware corresponding to the dynamic capability extension package are automatically triggered so that the robot can perceive the new hardware access and thus proceed to step 1.

[0036] Preferably, after completing the on-demand installation process in step 2 for entries with the type field being of the local type, and after the running entity of the target logical component is successfully loaded into the runtime environment, the robot immediately performs a tagging update operation on the installation status field. First, the lifecycle management strategy metadata of the target logical component is parsed from the dynamic capability extension package associated with it. This metadata clearly identifies whether the component is allowed to be dynamically recycled after the task ends. For example, temporary functional components are usually marked as recyclable, while robot basic service components are marked as persistent. Subsequently, based on the parsed attribute identifiers, corresponding uninstallable or non-uninstallable tags are appended to the installation status field. The uninstallable tag indicates that the component can be recycled by the on-demand uninstallation process in step 4 after the corresponding task is completed, so as to release the occupied resources; the non-uninstallable tag indicates that the component is a persistent service and must remain loaded even after the task ends, so as to be quickly reused by subsequent tasks or provide continuous service. Through this tagging process, the installation status field not only records the loaded status of the component, but also carries clear uninstallation strategy information, providing a direct basis for the on-demand uninstallation decision in the subsequent step 4, enabling resource recycling to be performed differently based on the different attributes of the component.

[0037] Preferably, after the target logic component successfully activates and establishes an instruction interaction link occupying the software and hardware interfaces, the robot synchronously performs a dynamic update operation on the interface configuration field. First, the software and hardware interface definitions required for the target logic component's operation are extracted from the dynamic capability extension package associated with it. These interfaces include software logic interfaces for inter-process or inter-component data interaction (e.g., socket addresses, shared memory identifiers, application programming interface function pointers), and physical hardware interfaces for connecting physical devices (e.g., general purpose input / output pin numbers, integrated circuit bus addresses, serial port device paths). Then, during the establishment of the instruction interaction link, real-time information on the software and hardware interfaces actually occupied by the target logic component is captured, including the component identifier or process identifier currently occupying these interfaces. Next, this real-time occupation information is written to the interface configuration field to overwrite the static interface type description initially recorded in the field, thereby generating real-time occupation information for the software and hardware interfaces, indicating which component or process is currently occupying them. Through this dynamic update, the interface configuration field remains consistent with the actual occupancy status throughout the entire capability lifecycle. This not only provides an accurate view of the interface busy status for subsequent tasks when retrieving the global capability mapping table, effectively avoiding interface conflicts, but also provides a clear basis for accurately releasing interface occupancy and resources when performing on-demand unloading in step 4.

[0038] Optionally, the service registration process in step 1 includes the following steps: The component resolver is used to parse the dynamic capability extension package and extract capability metadata, which includes the capability activation status (whether the capability can be activated at present) and logical component attributes describing its functional attributes. The extracted capability metadata is written into the global capability mapping table, which records the online capability sub-table for currently schedulable services, and the logical component reserve sub-table for storing components to be installed, based on the capability activation status and the logical component attributes, thereby completing the service registration of the capability corresponding to the newly connected hardware.

[0039] Preferably, during the service registration process in step 1, the acquired dynamic capability extension package is first sent as input data to a pre-deployed component resolver. This component resolver maintains a parsing template for the dynamic capability extension package structure, enabling it to identify and locate the metadata areas encapsulated within the extension package. Based on this parsing template, the component resolver extracts logical component attributes from the dynamic capability extension package that describe the capability's current activation status (whether it can be directly invoked), as well as essential characteristics such as the capability's functional category, dependencies, and version information. These extracted information are then combined and encapsulated into a structured data unit, namely the capability metadata. Through this parsing and extraction operation, the originally statically stored capability description information in the dynamic capability extension package is transformed into a standardized data format that can be subsequently identified and classified by the robot.

[0040] Preferably, after obtaining the capability metadata, the robot further performs a categorized writing operation based on the capability activation status and logical component attributes contained therein. Specifically, the robot first reads the capability activation status field in the capability metadata: if the status indicates that it is activatable, it means that the capability is ready to run directly locally, and the entire capability metadata is written into the global capability mapping table, specifically for recording online capabilities that can be currently scheduled and invoked by tasks; if the status indicates that it is temporarily inactivatable, or the logical component attributes indicate that the capability requires additional hardware access or installation steps to be enabled, the capability metadata is written into the global capability mapping table, specifically for storing components to be installed, to be installed later when the conditions are met. Through the above differentiated writing operation based on capability activation status and logical component attributes, the robot completes the service registration of the capabilities corresponding to the newly accessed hardware, enabling the global capability mapping table to accurately distinguish between currently directly serviceable online capabilities and reserve capabilities that need to be installed, providing a clear status view for capability retrieval and on-demand installation in subsequent steps.

[0041] Optionally, step 2, performing the on-demand installation process, includes the following steps: Extract the set of environment variables containing environment variables from the dynamic capability extension package to define the software running parameters, and inject the set of environment variables into an isolated sandboxed running environment to configure the various runtime parameters required for the operation of the target logic component in the sandboxed running environment; Using a virtual environment management engine, based on the resource requirements of the target logical component, the computing power quota of the processor computing resources and the allocation of memory space are performed for the target logical component in the sandboxed running environment, thereby completing the installation action of allocating exclusive physical hardware resources to the target logical component.

[0042] Preferably, during the on-demand installation process in step 2, the dynamic capability extension package associated with the target logical component is first used as the processing object, and a pre-encapsulated set of environment variables for defining software runtime parameters is extracted from it. This set of environment variables contains various configuration information required by the target logical component during runtime, such as file robot paths, log output levels, and network addresses of dependent services. After extraction, the set of environment variables is injected into a pre-created, isolated, sandboxed runtime environment. This sandboxed runtime environment is a runtime container isolated from the host operating robot, designed to provide the target logical component with an independent and secure execution space. By injecting the set of environment variables into this sandboxed runtime environment, the necessary runtime parameters for the target logical component are configured, thus laying the environmental foundation for the component's subsequent operation.

[0043] Preferably, the sandboxed runtime environment is created and managed by a virtual environment management engine. This engine includes a sandbox lifecycle manager, which dynamically generates isolated runtime containers based on the attributes of the target logical component. The sandbox lifecycle manager first invokes the namespace and control group mechanism of the operating robot kernel to create an independent process space, file robot mount point, and network protocol stack for the target logical component, ensuring complete isolation from the host and other component runtime environments. After sandbox creation, the extracted set of environment variables is injected into it through the sandbox's initialization interface. These environment variables are persistently stored in the sandbox's configuration store for subsequent runtime access.

[0044] Preferably, after completing the runtime parameter configuration, the virtual environment management engine further performs resource allocation operations based on the resource requirements of the target logical component. The virtual environment management engine internally includes a resource requirement parser, which reads predefined resource requirement descriptions from the dynamic capability extension package, such as processor calculation resource quotas (e.g., the proportion of CPU time slices required) and memory space size. The resource requirement parser converts these requirements into quota parameters recognizable by the underlying control group and passes them to the resource quota allocator within the engine.

[0045] Preferably, the resource quota allocator performs processor computing resource quota locking for the target logic component within the sandboxed operating environment. Specifically, the resource quota allocator sets CPU share parameters in the control group sub-robots corresponding to the sandbox through the control group interface provided by the operating robot, ensuring that the target logic component can obtain a specified processor time slice ratio during operation and avoiding competition for computing resources with other components. Simultaneously, the resource quota allocator also performs memory space allocation, setting memory usage limits and swap partition restrictions in the memory sub-robots of the control group, allocating a dedicated memory area for the target logic component to prevent it from consuming excessive memory and causing robot instability. Through these operations, the target logic component obtains defined and protected hardware resource access permissions within the sandboxed operating environment.

[0046] Preferably, through the sequential processing of the above-described environment configuration and resource locking, the installation action of allocating exclusive physical hardware resources to the target logical component is finally completed. At this point, the sandboxed runtime environment has all the conditions required for the target logical component to run: an isolated execution environment, correct runtime parameter configuration, and exclusive computing and memory resources. The running entity of the target logical component is loaded into the sandbox and is in a pending activation state, waiting for the service reconfiguration process in step 3 to establish an instruction interaction link and formally activate it. The entire installation process ensures resource isolation and fair scheduling between components, avoids mutual interference, and provides a guarantee for subsequent stable operation.

[0047] Optionally, the service reconfiguration process in step 3 includes the following steps: Extract the predefined component communication configuration from the dynamic capability extension package associated with the retrieved already loaded capability set; The dynamic loading engine parses the extracted component communication configuration and, based on the parsed component communication configuration information, establishes a data acquisition path for obtaining data from the target logical component and an instruction delivery path for sending control instructions to the target logical component locally. Based on the interface mapping relationship between the target logical component and the physical world determined by the interface configuration field in the global capability mapping table, the mapping and binding operation of the physical hardware interface and the software logical interface in the software and hardware interfaces is performed, thereby fully activating the instruction interaction link used for interaction between components and between components and hardware.

[0048] Preferably, during the service reconfiguration process in step 3, the associated dynamic capability extension package is first located and accessed using the retrieved set of already loaded capabilities as an index. From the predefined configuration area of ​​this dynamic capability extension package, the component communication configuration specifically describing the interaction methods between components is extracted. This component communication configuration contains all the communication protocol definitions required for the target logical component to exchange data with the outside world, such as data transmission format specifications, interaction endpoint identifiers, communication timeout thresholds, and retry strategies. After extraction, this raw configuration data is used as input, ready to be passed to the subsequent dynamic loading engine for in-depth processing.

[0049] Preferably, the dynamic loading engine includes a communication configuration parser, which is responsible for performing structured parsing of the extracted component communication configuration. The communication configuration parser first identifies the protocol type field in the configuration data and calls the corresponding parsing template based on the different protocol types (such as message queue-based communication, remote procedure calls, or shared memory interaction). Subsequently, the parser extracts the endpoint information required for data acquisition from the configuration, such as topic name, queue identifier, or service method signature, and also extracts the target address and call interface description required for instruction issuance. Through this parsing process, the original component communication configuration is converted into structured component communication configuration information that can be directly used by the robot, including explicit data source locators and instruction target locators.

[0050] Preferably, the dynamic loading engine, based on the parsed component communication configuration information, invokes its internal path builder to perform a communication path establishment operation. The path builder first creates or binds to a specified data acquisition endpoint in the local operating robot based on the data source locator. This can be done by creating a consumer instance of a message queue, subscribing to a specific data topic, or establishing a shared memory read mapping, thereby constructing a data acquisition path for continuously acquiring data from the target logic component. Simultaneously, the path builder establishes an instruction delivery path for sending control instructions to the target logic component based on the instruction target locator. This can be done by initializing a remote procedure call client stub, opening a producer channel for the instruction message queue, or establishing a dedicated instruction socket connection. The establishment of these two paths lays the foundation for bidirectional communication between the target logic component and other parts of the robot.

[0051] Preferably, after the communication path is established, the dynamic loading engine further performs an interface binding operation based on the interface mapping relationship between the target logical component and the physical world, as determined by the interface configuration field in the global capability mapping table. The interface binding manager inside the dynamic loading engine reads the real-time occupancy information from the interface configuration field to obtain the physical hardware interface identifier (e.g., specific general-purpose input / output pin numbers, integrated circuit bus device addresses) required by the target logical component, and the corresponding software logic interface identifier (e.g., device file path, hardware abstraction layer interface function). The interface binding manager performs a mapping binding operation between the software logic interface and the physical hardware interface by operating the device access interface provided by the robot. For example, it associates application programming interface calls with the level read / write operations of underlying pins, or redirects file read / write operations to the input / output buffer of a serial port device. Through this mapping binding, software-level data interaction commands can accurately act on physical hardware devices.

[0052] Preferably, through the establishment of the aforementioned data acquisition path, command issuance path, and mapping and binding operations between the physical hardware interface and the software logic interface, the dynamic loading engine fully activates the command interaction link used for interaction between components and between components and hardware. At this point, the target logic component is in a fully ready state: on the one hand, it can receive input data from the robot or other components through the data acquisition path; on the other hand, it can send status information and control results to the robot or other components through the command issuance path; simultaneously, it can also directly interact with hardware devices in the physical world through the bound software and hardware interfaces. The entire service reconfiguration process is thus completed, and the target logic component is successfully activated, awaiting the execution of specific task instructions.

[0053] Optionally, step 4, performing the on-demand uninstallation process, includes the following steps: During and after the task execution, the skill reference count is monitored in real time to quantify how many active tasks or processes use the target logic component, and it is continuously determined whether the skill reference count has returned to zero. If the skill reference count is determined to be zero and the task instruction that triggered this uninstallation process has been executed, then the cancellation operation of all software handles of the target logic component is immediately executed, and the occupation state of the target logic component on the software and hardware interface is released simultaneously to close the instruction interaction link, thereby releasing the software and hardware interface and hardware resources occupied by the instruction interaction link back to the preset local capability repository.

[0054] Preferably, during the on-demand unloading process in step 4, the reference counting monitor built into the dynamic loading engine first initiates real-time monitoring of the target logical component. This reference counting monitor continuously collects call handles of all active tasks or processes to the target logical component through the inter-process communication interface provided by the robot, and accumulates the number of these call handles as a skill reference count. Each increase in the skill reference count corresponds to a new task or process starting to use the component, and each decrease corresponds to a caller releasing a reference to the component. The monitor samples the skill reference count at fixed time intervals (e.g., every second or every hundred milliseconds) and compares the sampled values ​​with historical records to determine its trend. Through this continuous monitoring mechanism, the robot can grasp the current dependency status of the target logical component in real time, providing accurate quantitative basis for subsequent unloading decisions.

[0055] Preferably, the unloading decision unit within the dynamic loading engine continuously receives skill reference count samples from the reference count monitor and compares them with a preset zeroing threshold. Simultaneously, the unloading decision unit maintains the execution status of the task instruction that triggered this unloading process, obtaining a flag indicating whether the instruction has been completed through the task scheduler interface. When the unloading decision unit determines that the skill reference count has dropped to zero and the task instruction's execution status flag is complete, it confirms that the unloading trigger condition is met. At this point, the unloading decision unit immediately generates an unloading execution signal and sends this signal, along with the identifier of the target logical component, to the resource recycling manager in the dynamic loading engine, thereby initiating the formal unloading process.

[0056] Preferably, after receiving the unload execution signal, the resource recycling manager first performs a cancellation operation on all software handles of the target logical component. Specifically, the resource recycling manager traverses all software handles registered by the component in the dynamic loading engine, including socket descriptors used for inter-process communication, file handles, shared memory mapping identifiers, and remote procedure call client stubs, and closes or releases these handles one by one by operating the robot kernel interface. After completing the cancellation of the software handles, the resource recycling manager simultaneously performs a release operation on the occupancy status of the software and hardware interfaces: it reads the real-time occupancy information recorded in the interface configuration field of the global capability mapping table, locates the physical hardware interfaces and software logic interfaces currently occupied by the target logical component, and then calls the interface release function provided by the device driver to update the occupancy status of these interfaces from "occupied" to "free" and clear the corresponding mapping relationship. Through the above operations, the instruction interaction link is completely closed, and all software and hardware interfaces it occupies are released.

[0057] Preferably, after the hardware and software interfaces are released from their occupied state, the resource recycling manager further releases the hardware resources occupied by the instruction interaction link back to the preset local capability warehouse. Specifically, the resource recycling manager identifies the physical hardware resources allocated by the component from the local capability warehouse during the installation phase, such as processor computing power quotas, memory space, and dedicated hardware acceleration units, and revokes the previously executed computing power quota locks and memory space allocations through the control group interface of the virtual environment management engine, making these resources available again as allocable free resources. The resource recycling manager then updates the resource pool record of the local capability warehouse, marking the status of these hardware resources as "available". At this point, the on-demand unloading process of the target logic component is completed, and all its occupied resources are recycled to the local capability warehouse for reallocation by other components or subsequent tasks, realizing dynamic recycling and efficient utilization of resources.

[0058] Optionally, the method further includes: Throughout the entire lifecycle of the target logical component from loading to unloading, the events and states generated during the runtime of the target logical component are continuously recorded to form a runtime log. After the task is completed, all relevant runtime logs are encapsulated into an execution audit payload containing metadata, which can be parsed externally and has self-interpretation capabilities. The encapsulated execution audit payload is synchronized to the remote audit server via a secure link, so that the remote audit server can trace and supervise the entire process of the target logic component from hardware access, installation, configuration to uninstallation based on the execution audit payload.

[0059] Preferably, the audit logger integrated within the dynamic loading engine is continuously activated throughout the entire lifecycle of the target logical component, from loading to unloading. This audit logger captures events at key execution points during the target logical component's runtime via a hook function mechanism, including component initialization, each service call, read / write operations on the data acquisition path, instruction transmission on the instruction delivery path, and the occupation and release of software and hardware interfaces. Each captured event is formatted into a structured log entry, containing the event type, timestamp, execution result status, and a summary of the relevant parameters. Simultaneously, the audit logger periodically collects runtime status information of the target logical component through the operation robot interface, such as processor utilization, memory usage, and handle count, and associates this status information with the event entries, forming a continuously accumulating runtime log. This runtime log is persistently stored in a local secure storage area, ensuring it is not lost even in the event of an abnormal power outage.

[0060] Preferably, after the task instruction that triggered this uninstallation process has been executed and the target logic component has completed the on-demand uninstallation process, the audit payload encapsulator inside the dynamic loading engine is activated. This encapsulator first retrieves all runtime log entries associated with this task from the local storage area. These entries fully cover the entire process from hardware access in step 1, through on-demand installation in step 2, service configuration in step 3, to on-demand uninstallation in step 4. The audit payload encapsulator sorts and aggregates these runtime log entries in chronological order, forming a continuous event sequence. Subsequently, the encapsulator appends a set of descriptive metadata to this event sequence, including task identifier, component identifier, time range, total number of log entries, and checksum information. Through this encapsulation operation, the original runtime log is transformed into a structured, self-interpreting execution audit payload containing metadata that can be independently parsed by external robots. This payload design allows the remote server to fully reconstruct the entire lifecycle event flow based solely on the payload content, without relying on local context information.

[0061] Preferably, after the execution audit payload is encapsulated, the dynamic loading engine immediately invokes the secure transmission module to synchronize it to the remote audit server via a pre-established encrypted secure link. This secure link employs two-way authentication and transport layer encryption technology to ensure that the execution audit payload is not stolen or tampered with during transmission. Upon receiving the execution audit payload, the remote audit server first verifies its integrity checksum and stores it in the audit database after confirming its correctness. Subsequently, based on the metadata and event sequence contained in the payload, the remote audit server performs automated traceability analysis on the entire process of the target logical component from hardware access, installation, configuration to uninstallation. For example, it checks whether the event sequence conforms to the expected specifications, whether the time consumed at each stage is within the allowable range, and whether there are any abnormal status records. Through this supervision mechanism, the remote audit server can achieve compliance supervision of the entire lifecycle of the component, providing a complete and reliable data foundation for robot operation and maintenance, fault diagnosis, and security auditing.

[0062] like Figure 2 As shown, a loading device for dynamically configuring the capabilities of a home-based embodied intelligent robot includes: The hardware access processing module is used to respond to new hardware access signals and perform local hardware pairing and service registration processing. The capability extension package acquisition module is used to acquire, after the pairing process and the service registration process are successful, a dynamic capability extension package corresponding to the access hardware, containing capability execution logic and interface configuration requirements, from a preset capability repository; The mapping table generation module is used to generate a global capability mapping table based on the dynamic capability extension package, which records the component installation status and software and hardware interface occupancy information. The task response module is used to perform a capability retrieval in the global capability mapping table in response to a received task instruction, so as to determine the hardware readiness status and installation status of the target logical components required for the task to be executed. The on-demand installation module is used to perform on-demand installation and data loading processes on hardware that meets preset criteria, so as to produce a set of loaded capabilities containing the target logic component running entity. The service configuration module is used to retrieve the already loaded capability set and, based on the dynamic capability extension package associated with the already loaded capability set, perform service reconfiguration processing and service loading processing for the target logical component, so as to activate the target logical component and establish an instruction interaction link that occupies the software and hardware interfaces according to the interface configuration requirements. The monitoring and unloading module is used to monitor the execution status of the target logic component in real time. In response to the task end signal, it performs on-demand unloading processing on the service, the hardware, and the software and hardware interfaces to close the instruction interaction link, release the software and hardware interfaces and hardware resources occupied by the instruction interaction link, and reclaim the released resources to the preset local capability repository.

[0063] like Figure 3 The image shows an electronic device that includes a processor and a memory. The memory is used to store computer programs; When the processor executes the program stored in the memory, it implements the steps of the loading method for dynamic capability configuration of a home-based embodied intelligent robot as described in any one of the claims of this application.

[0064] Figures 2-3 The exemplary explanation is similar to that described above for... Figure 1 The exemplary descriptions are not repeated here.

Claims

1. A method for loading dynamic capability configurations for a home-based embodied intelligent robot, characterized in that, include: Step 1: In response to the new hardware access signal, perform local hardware pairing and service registration processing; After the pairing process and the service registration process are successful, a dynamic capability extension package corresponding to the access hardware and containing capability execution logic and interface configuration requirements is obtained from the preset capability repository, and a global capability mapping table recording component installation status and software and hardware interface occupancy information is generated based on the dynamic capability extension package. Step 2: In response to the received task instruction, perform a capability retrieval in the global capability mapping table to determine the hardware readiness status and installation status of the target logic component required for the task to be executed. Then, perform on-demand installation and data loading processing on the hardware that meets the preset criteria to produce a set of loaded capabilities containing the running entity of the target logic component. Step 3: Retrieve the already loaded capability set, and based on the dynamic capability extension package associated with the already loaded capability set, perform service reconfiguration processing and service loading processing for the target logical component, so as to activate the target logical component and establish an instruction interaction link occupying the software and hardware interfaces according to the interface configuration requirements; Step 4: Monitor the execution status of the target logic component in real time, and in response to the task end signal, perform on-demand unloading processing for the service, the hardware, and the software and hardware interfaces to close the instruction interaction link, release the software and hardware interfaces and hardware resources occupied by the instruction interaction link, and reclaim the released resources to the preset local capability repository.

2. The method according to claim 1, characterized in that, The global capability mapping table generated in step 1 includes a type field for distinguishing the source of capability or the location of hardware deployment, a hardware ready field for recording the physical connection status of hardware, an installation status field for recording the loading process of logical components, and an interface configuration field corresponding to the interface configuration requirements; wherein, the type field is specifically divided into cloud type, which represents that the capability is stored in the cloud, and local type, which represents that the capability depends on local hardware.

3. The method according to claim 2, characterized in that, For entries whose type field is marked as cloud-based, which do not depend on local physical hardware, the hardware ready field is uniformly recorded as an unlisted state indicating that the hardware is not connected, the installation status field is recorded as not installed, and the interface configuration field records the interface type required for communication with the cloud service. For entries whose type field is marked as local, if the hardware ready field is recorded as an inbound entry indicating that the corresponding hardware has been connected and paired, then the installation status field is recorded as an uninstalled entry indicating that the logical components have not yet been loaded.

4. The method according to claim 3, characterized in that, For entries where the type field is of the local type, if the installation status field records "installed" indicating that the logical component has been loaded, then the installation status field further includes an uninstallable tag or a non-uninstallable tag to identify whether the component can be dynamically recycled after the task ends; at the same time, the content recorded in the interface configuration field is also updated from static interface type to real-time occupancy information for the software and hardware interfaces, indicating which component or process is currently occupying them, wherein the software and hardware interfaces include software logical interfaces for data interaction and physical hardware interfaces for connecting physical devices.

5. The method according to claim 1, characterized in that, Before obtaining the dynamic capability extension pack in step 1, the following steps are also included: The robot's current functions are monitored and summarized in real time to form a set of functional features. The set of functional features is then compared with a task target model that represents the capabilities required to complete the task, either parsed from the task instructions or preset locally, to identify whether the robot currently lacks local capabilities. If a local capability deficiency is determined, the computing resources are driven to search for capability items that match the local capability deficiency in the preset cloud capability warehouse, and after the search is successful, a configuration request information containing the capability item identifier is sent to the management terminal corresponding to the user terminal or management backend. In response to the configuration request being approved by the management terminal and the corresponding dynamic capability extension package being successfully downloaded from the cloud capability warehouse and stored in the local storage space, hardware discovery and storage processing for the hardware corresponding to the dynamic capability extension package are automatically triggered so that the robot can perceive the new hardware access and thus proceed to step 1.

6. The method according to claim 1, characterized in that, Step 1, which involves performing the service registration process, includes the following steps: The component resolver is used to parse the dynamic capability extension package and extract capability metadata, which includes the capability activation status (whether the service capability is currently active) and logical component attributes describing its functional attributes. The extracted capability metadata is written into the global capability mapping table, which records the online capability sub-table for currently schedulable services, and the logical component reserve sub-table for storing components to be installed, based on the capability activation status and the logical component attributes, thereby completing the service registration of the capability corresponding to the newly connected hardware.

7. The method according to claim 1, characterized in that, Step 2, which involves performing on-demand installation, includes the following steps: Extract the set of environment variables containing environment variables from the dynamic capability extension package to define the software running parameters, and inject the set of environment variables into an isolated sandboxed running environment to configure the various runtime parameters required for the operation of the target logic component in the sandboxed running environment; Using a virtual environment management engine, based on the resource requirements of the target logical component, the computing power quota of the processor computing resources and the allocation of memory space are performed for the target logical component in the sandboxed running environment, thereby completing the installation action of allocating exclusive physical hardware resources to the target logical component.

8. The method according to claim 1, characterized in that, Step 3, which involves performing service reconfiguration, includes the following steps: Extract the predefined component communication configuration from the dynamic capability extension package associated with the retrieved already loaded capability set; The dynamic loading engine parses the extracted component communication configuration and, based on the parsed component communication configuration information, establishes a data acquisition path for obtaining data from the target logical component and an instruction delivery path for sending control instructions to the target logical component locally. Based on the interface mapping relationship between the target logical component and the physical world determined by the interface configuration field in the global capability mapping table, the mapping and binding operation of the physical hardware interface and the software logical interface in the software and hardware interfaces is performed, thereby fully activating the instruction interaction link used for interaction between components and between components and hardware.

9. The method according to claim 1, characterized in that, Step 4, which involves performing on-demand uninstallation, includes the following steps: During and after the task execution, the skill reference count is monitored in real time to quantify how many active tasks or processes use the target logic component, and it is continuously determined whether the skill reference count has returned to zero. If the skill reference count is determined to be zero and the task instruction that triggered this uninstallation process has been executed, then the cancellation operation of all software handles of the target logic component is immediately executed, and the occupation state of the target logic component on the software and hardware interface is released simultaneously to close the instruction interaction link, thereby releasing the software and hardware interface and hardware resources occupied by the instruction interaction link back to the preset local capability repository.

Images