A remote diagnosis method, a robot, and a storage medium

Abstract

The application discloses a remote diagnosis method, a robot and a computer readable storage medium. The remote diagnosis method is applied to a robot comprising two or more modules, the two or more modules comprising one main module and one or more sub-modules, and the main module being provided with a networking function. The method comprises the following steps: the main module receives a diagnosis instruction sent by a preset client; the main module determines a to-be-diagnosed module indicated by the diagnosis instruction; if the to-be-diagnosed module is the main module, the main module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result; if the to-be-diagnosed module is a target sub-module, the main module forwards the diagnosis instruction to the target sub-module, the target sub-module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result and sends the diagnosis result to the main module, wherein the target sub-module is any one of the one or more sub-modules; and the main module feeds back the obtained diagnosis result to the client. Through the application, the diagnosis of any module of the robot can be realized remotely.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of device diagnosis, and particularly relates to a remote diagnosis method, a robot and a computer readable storage medium. BACKGROUND

[0002] Service-type or sports-type robots usually contain multiple modules of hardware. Generally, only one module of a robot can access a network. When other modules that cannot access the network appear abnormal, it is difficult to perform remote diagnosis on the module because the module cannot be connected to the network. SUMMARY

[0003] The present application provides a remote diagnosis method, a robot and a computer readable storage medium, which can realize remote diagnosis on any module of a robot.

[0004] In a first aspect, the present application provides a remote diagnosis method, which is applied to a robot, the robot includes two or more modules, the two or more modules include one master module and one or more sub-modules, the master module has a networking function, and the remote diagnosis method includes the following steps.

[0005] The master module receives a diagnosis instruction sent by a preset client;

[0006] The master module determines a to-be-diagnosed module indicated by the diagnosis instruction;

[0007] If the to-be-diagnosed module is the master module, the master module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result;

[0008] If the to-be-diagnosed module is a target sub-module, the master module forwards the diagnosis instruction to the target sub-module, the target sub-module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result and sends the diagnosis result to the master module, and the target sub-module is any sub-module in the one or more sub-modules;

[0009] The master module feeds back the obtained diagnosis result to the client.

[0010] In a second aspect, the present application provides a robot, which includes two or more modules, the two or more modules include one master module and one or more sub-modules, and the master module has a networking function.

[0011] The master module is configured to receive a diagnosis instruction sent by a preset client and determine a to-be-diagnosed module indicated by the diagnosis instruction.

[0012] The main module is further configured to perform a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result when the module to be diagnosed is the main module.

[0013] The main module is further configured to forward the diagnosis instruction to a target sub-module when the module to be diagnosed is the target sub-module, wherein the target sub-module is any one of the one or more sub-modules.

[0014] The target sub-module is configured to perform a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result, and send the diagnosis result to the main module.

[0015] The main module is further configured to feed back the obtained diagnosis result to the client.

[0016] In a third aspect, the present application provides a robot, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method of the first aspect when executing the computer program.

[0017] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program, wherein the computer program is executable by a processor to implement the steps of the method of the first aspect.

[0018] In a fifth aspect, the present application provides a computer program product, which comprises a computer program, wherein the computer program is executable by one or more processors to implement the steps of the method of the first aspect.

[0019] The present application has the beneficial effects that: considering that only one module of the robot can be connected to a network, the module is defined as a main module, and other modules are defined as sub-modules. After receiving a diagnosis instruction from a client, the main module can first determine a module to be diagnosed indicated by the diagnosis instruction. Since the modules of the robot can communicate with each other, when the module to be diagnosed is a sub-module, the main module can send the diagnosis instruction to the sub-module, so that the sub-module can perform a corresponding diagnosis operation, and the sub-module will send the obtained diagnosis result back to the main module after the diagnosis operation is completed; when the module to be diagnosed is the main module itself, the main module can also immediately perform a corresponding diagnosis operation to obtain a diagnosis result. Finally, the main module can feed back the diagnosis result to the client. Through the above process, the limitation of the networking capability of the module on remote diagnosis is resolved, so that the robot can perform remote diagnosis for the main module and remote diagnosis for the sub-module without obstacles.

[0020] It can be understood that the beneficial effects of the second aspect to the fifth aspect can be understood with reference to the related description in the first aspect, which will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram illustrating the implementation process of the remote diagnostic method provided in the embodiments of this application;

[0023] Figure 2 This is an example architecture diagram of the remote diagnostic system provided in the embodiments of this application;

[0024] Figure 3 This is a structural block diagram of the robot provided in the embodiments of this application;

[0025] Figure 4 This is a schematic diagram of the robot provided in the embodiments of this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0027] To facilitate understanding of the remote diagnostic method provided in the embodiments of this application, the robot is first described below: The robot includes two or more modules, which are typically divided by processor hardware, such as a Central Processing Unit (CPU). Each module's processor carries a corresponding operating system (OS). That is, each module has a processor, which can execute a series of computer programs through its onboard system to achieve one or more functions. It can be understood that, in the embodiments of this application, from a hardware perspective, each module performs its corresponding operations; from a software perspective, the system onboard each module performs its corresponding operations. In other words, the operations of each module shown in the embodiments of this application can also be understood as the operations of the system onboard each module; the two are essentially equivalent.

[0028] For example only, the display module of the robot uses an Android system; the motion control module uses a real-time operating system; and the navigation module (and other algorithm modules) uses a Linux system.

[0029] It should be noted that the processors of different modules can be equipped with the same operating system or different operating systems, which is determined by the function of the module and is not limited here.

[0030] Internally, the modules of the robot can communicate with each other. That is, any two modules can directly exchange data.

[0031] Externally, only one module of all the modules of the robot has a networking function. That is, the module can access the network and exchange data with other devices. In the embodiments of the present application, the module with the networking function is set as a master module, and the remaining modules are set as sub-modules, and the master module and the sub-modules can be set by the user.

[0032] Based on the robot proposed above, the remote diagnosis method provided by the embodiments of the present application is described below. Please refer to Figure 1 The remote diagnosis method comprises:

[0033] In step 101, the master module receives a diagnosis instruction sent by a preset client.

[0034] The user can usually log in to the client of the robot to be diagnosed on his device, and then realize remote diagnosis of the robot through the client. After the client determines the module to be diagnosed, i.e., the module to be diagnosed, it generates a diagnosis instruction based on the module to be diagnosed, and sends the diagnosis instruction to the robot through the network. It can be understood that the client does not know and does not need to know the master module of the robot.

[0035] Since only the master module of all the modules of the robot is connected to the network, it can be considered that the robot receives the diagnosis instruction sent by the client from a macro perspective, and it can be considered that the master module of the robot receives the diagnosis instruction sent by the client from a micro perspective. That is, the receiver of the data is the master module of the robot.

[0036] In step 102, the master module determines the module to be diagnosed indicated by the diagnosis instruction.

[0037] After receiving the diagnosis instruction, the master module will first perform preliminary preprocessing on the diagnosis instruction to determine which module is the diagnosis object of this diagnosis operation. That is, the master module can analyze the diagnosis instruction to determine which module the client indicates for diagnosis operation this time, and the module is the module to be diagnosed.

[0038] If the module to be diagnosed is the main module, the main module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result.

[0039] If the module to be diagnosed is a target sub-module, the main module forwards the diagnosis instruction to the target sub-module, the target sub-module performs a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result and sends the diagnosis result to the main module.

[0040] Based on the determined module to be diagnosed, there are two cases: one is that the module to be diagnosed is the main module itself, and the other is that the module to be diagnosed is a sub-module.

[0041] For the case that the module to be diagnosed is the main module itself, the main module can directly perform a corresponding diagnosis operation based on the diagnosis instruction. After the diagnosis operation of the main module is completed, the main module can directly obtain its own diagnosis result.

[0042] For the case that the module to be diagnosed is a sub-module, for the sake of description, the sub-module is recorded as a target sub-module. Obviously, in this case, the performer of the diagnosis operation should not be the main module, but the target sub-module. Since the modules work independently and can communicate with each other, the main module will first forward the diagnosis instruction to the target sub-module, so that the target sub-module can obtain the diagnosis instruction. Subsequently, the target sub-module can perform a corresponding diagnosis operation based on the diagnosis instruction. After the diagnosis operation of the target sub-module is completed, the target sub-module obtains a diagnosis result. Since only the main module can be connected to the network, the target sub-module will send the diagnosis result back to the main module. At this point, the main module obtains the diagnosis result of the target sub-module.

[0043] In step 105, the main module feeds back the obtained diagnosis result to the client.

[0044] No matter whether the module to be diagnosed is the main module itself or a target sub-module, the main module can ultimately obtain a corresponding diagnosis result. The main module can feed back the diagnosis result to the client through the network, so that the client can debug the module to be diagnosed based on the diagnosis result. It can be understood that the client can not only initiate a diagnosis request to any module of the robot, but also can initiate other types of requests, and the implementation manners are similar to steps 101-105, which will not be described herein.

[0045] In some embodiments, considering that different modules of the robot can be equipped with the same system, to achieve distinction, the user can predefine the system name of the system equipped by each module. That is, for modules equipped with the same system, different system names can be set for the system of these modules. Thus, the unique correspondence between the module and the system name is achieved, so that one module corresponds to one system name, and the system names corresponding to different modules are different, avoiding system confusion caused by different modules equipped with the same system. As an example, the unique correspondence between the module and the system name can be shown in Table 1 as follows:

[0046] Module System name M1 linux1 M2 linux2 M3 android1 …… ……

[0047] Table 1

[0048] In this example, although modules M1 and M2 both run linux systems, in order to distinguish, the system run by module M1 is called linux1, and the system run by module M2 is called linux2. It can be understood that the system name in this example uses a serial number as a distinction; in actual application, the module function can also be used as a distinction, for example, the system name of module M1 is navigation, and the system name of module M2 is motion, as long as each system name is globally unique, which is not limited here.

[0049] In some embodiments, the user can specifically configure the main module and the sub-module in the form of a file, which is as follows: for each diagnosable module, the user can add a corresponding configuration file to the module. The file content in the configuration file is as follows:

[0050] <platform product-id="xxx-robot">

[0051] <os-info os-name="linux-xx1" master-os-name="linux-xx2" / >

[0052]

[0053] Wherein, product-id is the name of the robot, os-name is the system type and corresponding system name of the system equipped by the module, and master-os-name is the system type and corresponding system name of the system equipped by the main module set by the user.

[0054] As an example, based on Table 1, assuming that the name of the robot is A-robot, the user sets module M1 as the main module, and modules M2 and M3 as sub-modules, the file content of the configuration file of module M1 is as follows:

[0055] <platform product-id="A-robot">

[0056] <os-info os-name="linux-linux1" master-os-name="linux-linux1" / >

[0057]

[0058] The file content of the configuration file of the module M2 is as follows:

[0059] <platform product-id="A-robot">

[0060] <os-info os-name="linux-linux2" master-os-name="linux-linux1" / >

[0061]

[0062] The file content of the configuration file of the module M3 is as follows:

[0063] <platform product-id="A-robot">

[0064] <os-info os-name="android-android1" master-os-name="linux-linux1" / >

[0065]

[0066] In some embodiments, the diagnosis service should be started after the robot is powered on, but before this, each module does not know whether it is configured by the user as a master module or a child module. At this time, each module needs to determine its identity, which depends on the configuration file. That is, after the robot is powered on, each module can be determined by the preset configuration file of each module to determine which module is the master module and which modules are the child modules. Since the process of identity determination of each module is the same, for ease of understanding, the process of identity determination is described below by taking any module in the robot as an example:

[0067] The module reads the system name corresponding to the module (i.e., the module system name) and the system name corresponding to the master module stored in the corresponding configuration file. Since the system name is unique, and the system name uniquely corresponds to a module, when the system name corresponding to the module is the same as the system name corresponding to the master module, it can be quickly determined that the module is the master module; otherwise, when the system name corresponding to the module is different from the system name corresponding to the master module, it can be quickly determined that the module is not the master module, i.e., the module is a child module.

[0068] For example, module M1 can determine that it is the master module after reading the corresponding configuration file, because the system name corresponding to module M1 is linux1, and the system name corresponding to the master module is also linux1. For module M2, the system name corresponding to module M2 is linux2, and the system name corresponding to the master module is linux1. Therefore, module M2 can determine that it is a slave module. Similarly, module M3 can also determine that it is a slave module in the same way.

[0069] In some embodiments, after each module determines its identity, the diagnostic service is started, and each module can perform diagnostic preparation work accordingly. Specifically, for the master module, it will access the network and wait for diagnostic instructions sent by the client. For each slave module, it will start a local service and enter a listening state. It can be understood that in the listening state, each slave module will listen to instructions sent by the master module.

[0070] In addition, for each slave module, it already knows which system the master module corresponds to. Therefore, each slave module can report the system name corresponding to itself to the master module based on the system name corresponding to the master module. For example, module M2 will report the system name linux2 to the master module, and module M3 will report the system name android1 to the master module. It can be understood that for a slave module, the process of reporting to the master module is actually the process of reporting to the system corresponding to the master module, that is, modules M1 and M2 actually report the system names linux and android1 to the system linux1 corresponding to the master module.

[0071] In this way, the main module can receive all the system names corresponding to the respective sub-modules. Of course, the main module also knows its own system name. For the client, it does not know which modules of the robot to be diagnosed at the beginning. Therefore, in response to the operation of the client entering the diagnosis page, the client automatically sends an information request instruction to the robot, which is used to request the robot to feed back the information of each diagnosable module. Since the module is uniquely corresponding to the system name, and the diagnosis operation is actually an operation on the software level, when the robot receives the information request instruction, it can feed back the system names corresponding to all modules (including the main module and all sub-modules) to the client. In this way, the client knows the system names corresponding to all diagnosable modules, which can be displayed as selectable items on the diagnosis page of the client. It can be understood that since the main module has collected the system names corresponding to all modules after starting up, the client can obtain the feedback of the robot to the information request instruction in a short time. For the user, it is perceived that after entering the diagnosis page of the robot on the client, the page is refreshed, and then the diagnosis page displays the system names of each diagnosable module in the form of selectable items. The user can subsequently check the system name of the module (i.e. the module to be diagnosed) to be diagnosed on the diagnosis page, so that the client generates a diagnosis instruction.

[0072] In some embodiments, the main module can determine the module to be diagnosed by analyzing the diagnosis instruction to obtain the system name corresponding to the module to be diagnosed carried by the diagnosis instruction. Since the system name is unique, and the system name uniquely corresponds to a module, the module to be diagnosed corresponding to the system name can be determined based on the system name.

[0073] In some embodiments, the robot (specifically the main module of the robot) actually interacts with the client through a preset cloud server. It can be understood that the robot, the cloud server and the client form a remote diagnosis system, and the cloud server plays the role of a data bridge in the remote diagnosis system: when the client sends data (such as a diagnosis instruction or an information request instruction) to the robot, the cloud server actually receives the data first, and then forwards the data to the robot, which is received by the main module of the robot. Conversely, when the main module sends data (such as a diagnosis result or a system name) to the client, the cloud server actually receives the data first, and then forwards the data to the client. Please refer to Figure 2 , Figure 2 An architecture example of the remote diagnosis system is given. In Figure 2 , the robot includes three modules, M1, M2 and M3. M1 is connected to the network, specifically connected to the cloud server. Moreover, M2 and M3 can interact with M1.

[0074] As can be seen from the above, in the embodiment of the present application, considering that the robot has only one module capable of networking, the module is defined as a master module, and the other modules are defined as sub-modules. After receiving a diagnosis instruction of a client, the master module can first determine a module to be diagnosed indicated by the diagnosis instruction. Since the modules of the robot can communicate with each other, when the module to be diagnosed is a certain sub-module, the master module can send the diagnosis instruction to the sub-module, so that the sub-module can perform a corresponding diagnosis operation, and the sub-module will send the obtained diagnosis result back to the master module after the diagnosis operation is completed; when the module to be diagnosed is the master module itself, the master module can also immediately perform a corresponding diagnosis operation to obtain a diagnosis result. Finally, the master module can feed back the diagnosis result to the client. Through the above process, the limitation of the networking capability of the module on remote diagnosis is resolved, so that the robot can perform remote diagnosis for the master module and remote diagnosis for the sub-module without obstacles.

[0075] Corresponding to the remote diagnosis method applied to the robot provided in the above, the embodiment of the present application further provides a robot. Please refer to Figure 3 The above robot 300 includes two or more modules, the two or more modules include one master module 301 and one or more sub-modules 302 (three are shown in the figure), the master module 301 has a networking function; Figure 3

[0076] The master module 301 is configured to receive a diagnosis instruction sent by a preset client, and determine a module to be diagnosed indicated by the diagnosis instruction.

[0077] The master module 301 is further configured to, when the module to be diagnosed is the master module, perform a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result.

[0078] The master module 301 is further configured to, when the module to be diagnosed is a target sub-module, forward the diagnosis instruction to the target sub-module, wherein the target sub-module is any one of the one or more sub-modules 302.

[0079] The target sub-module is configured to perform a diagnosis operation based on the diagnosis instruction to obtain a diagnosis result, and send the diagnosis result to the master module 301.

[0080] The master module 301 is further configured to feed back the obtained diagnosis result to the client.

[0081] Optionally, after the robot is powered on, for each module, the module is further configured to perform identity determination through a preset configuration file.

[0082] ​Optionally, for each module, the module is specifically configured to read a module system name stored in a configuration file of the module and a system name corresponding to the main module 301, the module system name being a system name corresponding to the module; if the module system name is the same as the system name corresponding to the main module 301, the module is determined to be the main module 301; if the module system name is different from the system name corresponding to the main module 301, the module is determined to be the sub-module 302.

[0083] Optionally, each sub-module 302 is further configured to enter a listening state after determining the identity, the listening state being used to listen to an instruction sent by the main module 301.

[0084] The main module 301 is further configured to access a network after determining the identity.

[0085] Optionally, each sub-module 302 is further configured to report a system name corresponding to the sub-module 302 to the main module 301 after determining the identity.

[0086] The main module 301 is further configured to, after determining the identity, if receiving an information request instruction sent by the client, feed back, to the client, a system name corresponding to the main module 301 and all system names corresponding to the sub-modules 302 received.

[0087] Optionally, the main module 301 is specifically configured to parse the diagnosis instruction to obtain a system name corresponding to a to-be-diagnosed module carried by the diagnosis instruction; and determine the to-be-diagnosed module based on the system name corresponding to the to-be-diagnosed module.

[0088] Optionally, the main module 301 is specifically configured to perform data interaction with the client through a preset cloud server.

[0089] As can be seen from the above, in the embodiments of the present application, considering that only one module of the robot can be connected to a network, the module is defined as a main module, and other modules are defined as sub-modules. After receiving a diagnosis instruction of a client, the main module can first determine a to-be-diagnosed module indicated by the diagnosis instruction. Since the modules of the robot can communicate with each other, when the to-be-diagnosed module is a certain sub-module, the main module can send the diagnosis instruction to the sub-module, so that the sub-module can perform a corresponding diagnosis operation, and the sub-module will send a diagnosis result obtained after the diagnosis operation to the main module; when the to-be-diagnosed module is the main module itself, the main module can also immediately perform a corresponding diagnosis operation to obtain a diagnosis result. Finally, the main module can feed back the diagnosis result to the client. Through the above process, the limitation of the networking capability of the module on remote diagnosis is resolved, so that the robot can perform remote diagnosis for the main module and remote diagnosis for the sub-module without obstacles.

[0090] Corresponding to the remote diagnostic method for robots provided above, this application also provides a robot. Please refer to... Figure 4 The robot 4 in this embodiment includes: a memory 401, and one or more processors 402. Figure 4 Only one is shown in the image, along with a computer program stored in memory 401 and executable on the processor. Memory 401 stores software programs and units. The processor 402 executes various functional applications and data processing by running the software programs and units stored in memory 401 to obtain resources corresponding to preset events. Specifically, the processor 402 implements the following by running the aforementioned computer program stored in memory 401: Figure 1 The remote diagnostic method in the corresponding embodiment.

[0091] It should be understood that, in the embodiments of this application, the processor 402 may be a CPU, but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor, or any conventional processor, etc.

[0092] Memory 401 may include read-only memory and random access memory, and provides instructions and data to processor 402. Some or all of memory 401 may also include non-volatile random access memory. For example, memory 401 may also store device category information.

[0093] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is taken as an example, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the above device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or software functional unit. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0094] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the related description of other embodiments.

[0095] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.

[0096] In the embodiments provided in the present application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the system embodiments described above are only schematic, for example, the division of the above modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0097] The units described above as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0098] The integrated units described above, if implemented in the form of software function units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be implemented by a computer program instructing associated hardware, and the above-mentioned computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms, etc. The computer readable storage medium can include any entity or device capable of carrying the above-mentioned computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer readable memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the above-mentioned computer readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable storage medium does not include electrical carrier signals and telecommunication signals.

[0099] The above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A remote diagnostic method, characterized in that, The remote diagnostic method is applied to a robot, which includes two or more modules, each module having a processor. The two or more modules include a main module and one or more sub-modules dynamically configured by the user through a preset configuration file. The main module has network connectivity. The remote diagnostic method includes: The main module receives a pre-set diagnostic command sent by a client, wherein the diagnostic command carries the system name corresponding to the module to be diagnosed; The main module determines the module to be diagnosed indicated by the diagnostic command based on the unique correspondence between the system name and the module. If the module to be diagnosed is the main module, then the main module performs a diagnostic operation based on the diagnostic instruction to obtain a diagnostic result; If the module to be diagnosed is a target sub-module, the main module forwards the diagnostic instruction to the target sub-module, and the target sub-module performs a diagnostic operation based on the diagnostic instruction to obtain a diagnostic result and sends the diagnostic result to the main module. The target sub-module is any one of the more than one sub-modules. The main module will then send the diagnostic results back to the client.

2. The remote diagnostic method as described in claim 1, characterized in that, The remote diagnostic method also includes: After the robot is powered on, the identity of each module is determined through a preset configuration file to identify the main module and sub-modules in the robot.

3. The remote diagnostic method as described in claim 2, characterized in that, The process of determining the identity of each module through a preset configuration file includes: For each module, read the module system name and the system name corresponding to the main module stored in the module's configuration file, where the module system name is the system name corresponding to the module; If the system name of the module is the same as the system name corresponding to the main module, then the module is determined to be the main module; If the system name of the module is different from the system name corresponding to the main module, then the module is determined to be the sub-module.

4. The remote diagnostic method as described in claim 3, characterized in that, After verifying the identity of each module using a preset configuration file, the remote diagnostic method further includes: Each of the submodules enters a listening state, which is used to listen for instructions sent by the main module; The main module is connected to the network.

5. The remote diagnostic method as described in claim 3, characterized in that, After verifying the identity of each module using a preset configuration file, the remote diagnostic method further includes: Each submodule reports the system name corresponding to the submodule to the main module; If the main module receives an information request instruction sent by the client, it will send back the system name corresponding to the main module and the system names corresponding to all the sub-modules it received to the client.

6. The remote diagnostic method as described in claim 3, characterized in that, The main module determines the module to be diagnosed indicated by the diagnostic command based on the unique correspondence between the system name and the module, including: The main module parses the diagnostic command to obtain the system name corresponding to the module to be diagnosed carried by the diagnostic command; The main module determines the module to be diagnosed based on the system name corresponding to the module to be diagnosed.

7. The remote diagnostic method according to any one of claims 1 to 6, characterized in that, The main module interacts with the client via a pre-set cloud server.

8. A robot, characterized in that, The robot includes two or more modules, each module having a processor. The two or more modules include a main module and one or more sub-modules dynamically set by the user through a preset configuration file. The main module has network connectivity. The main module is used to receive diagnostic instructions sent by a preset client. The diagnostic instructions carry the system name corresponding to the module to be diagnosed, and the module to be diagnosed indicated by the diagnostic instructions is determined based on the unique correspondence between the system name and the module. The main module is also used to perform diagnostic operations based on the diagnostic instructions to obtain diagnostic results when the module to be diagnosed is the main module. The main module is also configured to forward the diagnostic instruction to the target submodule when the module to be diagnosed is the target submodule, wherein the target submodule is any one of the more than one submodules; The target submodule is used to perform diagnostic operations based on the diagnostic instructions to obtain diagnostic results, and to send the diagnostic results to the main module. The main module is also used to feed back the obtained diagnostic results to the client.

9. A robot comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images