A robot control method, device, and storage medium

Abstract

The application discloses a robot control method, device and storage medium, wherein a key command mapping dictionary is preconfigured, key information of a wireless input device is parsed into a semantic command string, the string is published to a pre-defined topic by a wireless input device node, a target node which has subscribed to the topic can receive the string and convert it into a robot bottom layer control instruction according to another pre-configured command instruction mapping dictionary, and finally a final actuator is triggered to complete a target action. The design of the double-layer mapping and topic communication combination makes the corresponding relationship between the keys and the functions completely defined by an editable configuration file, and is decoupled from the robot bottom layer firmware and hardware driver. Therefore, an operator can complete various control tasks by using a portable laser pen with a small number of keys.

Description

Technical Field

[0001] This invention relates to the field of equipment control technology, and in particular to a robot control method, device, and storage medium. Background Technology

[0002] Existing robot control methods mostly rely on dedicated remote controllers or teach pendants, sending commands via physical buttons. However, these methods involve a large number of buttons with mappings fixed in firmware, requiring operators to memorize numerous button combinations, resulting in high learning costs. Furthermore, different robot models often require different control devices, leading to poor versatility. When adjusting control logic or adding new functions, firmware modifications or even hardware replacements are often necessary, limiting scalability. Therefore, providing a robot control method that is easy to operate, has flexible configurable mappings, and is easily expandable across platforms is a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0003] This application provides a robot control method, device, and storage medium, which solves the technical problems in the prior art where robot control relies on a dedicated remote control or teach pendant, has a large number of buttons, mapping relationships are fixed in firmware, poor versatility, and is difficult to expand flexibly. It achieves the technical effects of simple operation, online configuration of button command mapping, decoupling of control nodes from hardware, and support for cross-platform portability and dynamic functional expansion.

[0004] In a first aspect, this application provides a robot control method, wherein the robot is connected to a wireless input device, the method comprising: Receive key information sent by the wireless input device, the key information being generated by triggering at least one key of the wireless input device; Based on a pre-configured key command mapping dictionary, the key information is parsed into corresponding command strings; the key command mapping dictionary defines a unique correspondence between key information and command strings. The command string is published to a predefined topic by a wireless input device node pre-created in the robot, so that the target node in the robot that has subscribed to the predefined topic receives the command string. Based on a pre-configured command instruction mapping dictionary, the command string is parsed into the corresponding robot control instruction, and the actuator corresponding to the robot control instruction is triggered to perform the target action corresponding to the robot control instruction.

[0005] Secondly, this application provides a robot control method, the method comprising: The host computer writes a first software function package into the workspace of the first robot to be controlled. The first software function package originates from the workspace of the second robot and is encapsulated based on a robot control method as provided in the first aspect. The second robot is controlled by a connected first wireless input device and the first software function package. The host computer identifies the device code of the first robot and updates the device code into the first software function package written into the first robot, thereby obtaining the second software function package; Establish a connection between the first robot and the second wireless input device, and control the first robot through the second wireless input device and the second software package.

[0006] Thirdly, this application provides an electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute a robot control method as provided in the first aspect.

[0007] Fourthly, this application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform a robot control method as provided in the first aspect.

[0008] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: This application embodiment pre-configures a key command mapping dictionary to parse key information from wireless input devices (such as laser pointers) into semantic command strings. The wireless input device node then publishes this string to a predefined topic, allowing target nodes subscribed to that topic to receive the string and convert it into underlying robot control commands based on another pre-configured command instruction mapping dictionary. This ultimately triggers the actuator to complete the target action. This two-layer mapping combined with topic communication design ensures that the correspondence between keys and functions is entirely defined by an editable configuration file, decoupling it from the robot's underlying firmware and hardware drivers. Therefore, operators do not need to memorize complex physical button layouts; they can complete various control tasks using only a portable laser pointer with a very small number of keys.

[0009] This application embodiment enables rapid reuse and seamless migration of control functions between different robots. Specifically, since the first software function package fully encapsulates core control logic such as key monitoring, command mapping, topic publishing, and status feedback, and these logics are independent of the robot's underlying hardware and specific model, relying only on the communication framework and interface (such as the ROS2 communication framework and the Linux input subsystem standard interface), no redevelopment of any code is required when copying this function package from a debugged second robot to the first robot. By identifying the device code of the first robot (e.g., the input event number corresponding to the laser pointer receiver) by the host computer and updating the code in the function package's parameter configuration file, the adaptation to the first robot's hardware environment can be completed. In this process, the user only needs to modify the device path parameters in the configuration file, without modifying any node source code or recompiling the underlying firmware, to generate a second software function package specifically for the first robot. Subsequently, by connecting the second wireless input device (such as a laser pointer) to the first robot, complete key control of the first robot can be implemented through the device and the second software function package, including a series of operations such as power on, navigation, pause, resume, and power off. Therefore, the embodiments of this application realize the cross-platform portability of "one-time packaging, multi-machine deployment", which greatly reduces the time cost and programming threshold of repeatedly configuring control functions on multiple robots. Even if the robot models are different or the input device numbers change, only a few parameters in the configuration file need to be modified to complete the adaptation, which significantly improves the universality and scalability of the control system, while avoiding the repetitive labor and maintenance burden caused by "one remote control for one machine and one firmware for one process" in the traditional solution. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a robot control method provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of the control flow of a navigation robot. Figure 3 A flowchart illustrating another robot control method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] This application provides a robot control method, device, and storage medium, which solves the technical problems in the prior art where robot control relies on a dedicated remote control or teach pendant, has a large number of buttons, mapping relationships are fixed in firmware, poor versatility, and is difficult to expand flexibly. It achieves the technical effects of simple operation, online configuration of button command mapping, decoupling of control nodes from hardware, and support for cross-platform portability and dynamic functional expansion.

[0013] The technical solution of this application embodiment is to solve the above-mentioned technical problems, and the general idea is as follows: This application embodiment pre-configures a key command mapping dictionary to parse key information from wireless input devices (such as laser pointers) into semantic command strings. The wireless input device node then publishes this string to a predefined topic, allowing target nodes subscribed to that topic to receive the string and convert it into underlying robot control commands based on another pre-configured command instruction mapping dictionary. This ultimately triggers the actuator to complete the target action. This two-layer mapping combined with topic communication design ensures that the correspondence between keys and functions is entirely defined by an editable configuration file, decoupling it from the robot's underlying firmware and hardware drivers. Therefore, operators do not need to memorize complex physical button layouts; they can complete various control tasks using only a portable laser pointer with a very small number of keys.

[0014] This application embodiment enables rapid reuse and seamless migration of control functions between different robots. Specifically, since the first software function package fully encapsulates core control logic such as key monitoring, command mapping, topic publishing, and status feedback, and these logics are independent of the robot's underlying hardware and specific model, relying only on the communication framework and interface (such as the ROS2 communication framework and the Linux input subsystem standard interface), no redevelopment of any code is required when copying this function package from a debugged second robot to the first robot. By identifying the device code of the first robot (e.g., the input event number corresponding to the laser pointer receiver) by the host computer and updating the code in the function package's parameter configuration file, the adaptation to the first robot's hardware environment can be completed. In this process, the user only needs to modify the device path parameters in the configuration file, without modifying any node source code or recompiling the underlying firmware, to generate a second software function package specifically for the first robot. Subsequently, by connecting the second wireless input device (such as a laser pointer) to the first robot, complete key control of the first robot can be implemented through the device and the second software function package, including a series of operations such as power on, navigation, pause, resume, and power off. Therefore, the embodiments of this application realize the cross-platform portability of "one-time packaging, multi-machine deployment", which greatly reduces the time cost and programming threshold of repeatedly configuring control functions on multiple robots. Even if the robot models are different or the input device numbers change, only a few parameters in the configuration file need to be modified to complete the adaptation, which significantly improves the universality and scalability of the control system, while avoiding the repetitive labor and maintenance burden caused by "one remote control for one machine and one firmware for one process" in the traditional solution.

[0015] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0016] First, it should be clarified that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0017] This application provides a robot control method, wherein the robot is connected to a wireless input device, and the method includes steps S11-S13, which can be referred to in detail. Figure 1 As shown.

[0018] Step S11: Receive key information sent by the wireless input device, wherein the key information is generated by triggering at least one key of the wireless input device; Step S12: Based on the pre-configured key command mapping dictionary, the key information is parsed into the corresponding command string; the key command mapping dictionary defines the unique correspondence between key information and command string. Step S13: The pre-created wireless input device node in the robot publishes the command string to a predefined topic, so that the target node in the robot that has subscribed to the predefined topic receives the command string. Based on the pre-configured command instruction mapping dictionary, the command string is parsed into the corresponding robot control instruction, and the actuator corresponding to the robot control instruction is triggered to perform the target action corresponding to the robot control instruction.

[0019] The robot control method provided in this application can be executed by the robot itself, which has data processing capabilities, i.e., by the robot's built-in controller, industrial computer, or embedded processor running the corresponding control program; or it can be executed by an external control platform that communicates with the robot, such as a host computer, edge computing device, cloud server, or dedicated control terminal. This control platform must be able to receive button signals from wireless input devices and interact with the robot to send control commands. This application embodiment only illustrates the control method executed by the robot itself as an example.

[0020] The wireless input device can be any handheld, portable wireless signal transmitter, including but not limited to laser devices (such as laser pointers), PPT page turners, mini wireless keyboards, single-button or multi-button remote controls, etc. It connects to the device performing the method via Bluetooth, 2.4GHz wireless, or infrared, and typically has 2 to 6 buttons to maintain operational simplicity. This application embodiment only uses a laser pointer and its corresponding laser receiver as an example of a wireless input device. The laser receiver is plugged into the corresponding interface on the robot to enable communication between the laser pointer and the robot via the laser receiver.

[0021] It is important to note that the robot control method provided in this application can be implemented on various types of robots, such as autonomous mobile robots, humanoid robots, robotic arms, service robots, and inspection robots. Taking a navigation robot as an example, this method can map key actions during its operation, such as pose repositioning, task pause and resume, emergency stop, and power on / off, to a few buttons on a wireless input device, thereby replacing traditional remote controls or teach pendants and achieving convenient "point-and-control" intervention. Regardless of whether the robot chassis adopts a wheeled, tracked, or legged structure, and regardless of whether it operates in indoor warehouses, industrial production lines, or outdoor environments, as long as the robot has a secondary development-enabled software interface (such as ROS2) and can receive external wireless button signals, this method can be directly deployed without modifying the underlying firmware.

[0022] For example, the robot control logic (including key monitoring, command mapping, topic posting, etc., such as steps S11-S13) can be encapsulated into a software package written in Python and based on the ROS2 communication framework, and used with a commercially available standard laser pointer (connected via a USB receiver) as the human-machine interaction terminal. The core advantage of this architecture lies in its high portability: since ROS2 itself provides a standardized communication interface across robot platforms, and the Linux system has universal driver support for USBHID devices (such as laser pointer receivers), as long as the target robot meets two basic conditions: first, it can run ROS2 (or at least has the ROS2 client library); second, its main control system is a Linux kernel and supports the recognition of USB input devices, the software package can be directly copied to the robot without modifying any underlying firmware or driver code for a specific robot model.

[0023] For example, a differential navigation robot using ROS2 Humble and a quadruped inspection robot using ROS2 Foxy can completely reuse the same software package by simply configuring the device path ( / dev / input / eventX) for the laser pointer receiver. This allows for intervention controls such as pause, resume, repositioning, and power on / off. This design completely breaks free from the constraints of traditional solutions that require "one robot, one remote control; one process, one firmware," truly enabling rapid deployment of control methods across platforms and models.

[0024] This application uses a laser pointer and its corresponding laser receiver as examples of wireless input devices. The wireless receiver is plugged into the corresponding interface on the robot to enable the laser pointer to communicate with the robot via the wireless receiver.

[0025] Specifically, before a robot implements the robot control method provided in this application embodiment, the following software and hardware preparations need to be completed: First, physically insert the laser pointer's wireless receiver into the robot's USB or Type-C port, ensuring the operating system recognizes the input device. Second, establish a remote connection (e.g., SSH) with the robot via a personal computer or host computer. Execute a query command on the robot (e.g., `cat / proc / bus / input / devices` or `sudo evtest`) to determine the input event number corresponding to the laser pointer receiver. This number is the numerical part of the device path, such as `event0` or `event24`. Finally, create a new software package for the laser pointer in the robot's ROS2 workspace and write the found device number into its parameter configuration file (e.g., `config / params.yaml`), i.e., set `device_path: / dev / input / event0` (replacing it with the actual number). After completing the above configuration, the robot can capture the laser pointer's button information by reading the ` / dev / input / eventX` file, providing a foundation for subsequent control processes.

[0026] Assuming the software package for the laser pointer has been created and configured on robot A, when migrating this control method to robot B, simply copy the entire laser pointer software package (function folder) from robot A to the ROS2 workspace of robot B. Then, follow the same steps to re-query the event number corresponding to the laser pointer receiver on robot B (e.g., event3 on robot B), and modify the device_path value in the parameter configuration file on robot B accordingly (from / dev / input / event0 to / dev / input / event3). Apart from this, no other source code modification or firmware recompilation is required. This is because the key monitoring, command mapping, and topic publishing logic in the software package are independent of the underlying hardware of the specific robot platform, relying only on the ROS2 communication framework and the Linux input subsystem standard interface. Therefore, rapid reuse across robot models and hardware platforms can be achieved through simple parameter replacement, truly realizing "package once, run anywhere."

[0027] After the robot is configured with the corresponding software function package, that is, after the configuration and deployment of the laser pointer's software function package are completed, the robot's startup process is as follows: First, the robot communication node (usually provided by the robot manufacturer for interaction with the underlying hardware) is started. This node is the foundation for all subsequent control commands and robot status interactions. Second, at least two custom nodes are started in the laser pointer's software function package, which may include a laser pointer button node (key_node) and an automatic power on / off node (auto_power_mgr_node). The key_node is responsible for continuously listening to the laser pointer's button input events (corresponding to subsequent step S11), converting the button information into a command string, and forwarding it to the ROS2 topic. The auto_power_mgr_node subscribes to this topic and, when it receives a power on / off related command, calls the service interface of the robot communication node to control the robot to perform power-on or power-off operations. At the same time, a control topic named / laserpen_command is defined in ROS2 to carry the command string parsed from the button, thereby achieving decoupled communication between key_node, auto_power_mgr_node, and other potential subscribers. The aforementioned nodes and topics together constitute the complete operating environment for laser pointer button control.

[0028] The process of implementing a robot control method for a specific robot is explained below: Regarding step S11, receiving key information sent by the wireless input device, the key information being generated by triggering at least one key of the wireless input device.

[0029] In this embodiment, the key information refers to a data set containing key attributes and temporal characteristics generated when one or more keys on a wireless input device (e.g., a laser pointer) are triggered by a user. Specifically, the key information includes at least two sub-information items: key identifier and duration. The key identifier is used to uniquely distinguish different physical keys on the wireless input device, such as KEY_TAB, KEY_ENTER, KEY_DOWN, KEY_UP, etc., with each identifier corresponding to an independent key on the device. The duration refers to the time interval between pressing and releasing the key, typically in milliseconds or seconds. By recording the duration, the control terminal can distinguish between short-duration taps (e.g., less than 2 seconds) and long-duration presses (e.g., 2 seconds or more), thereby assigning different control semantics to the same physical key (e.g., short press for "continue," long press for "power off"). It should be noted that if the wireless input device supports simultaneous pressing of multiple keys (combination keys), the key information may also include multiple key identifiers and their respective durations.

[0030] Regarding step S12, the key information is parsed into the corresponding command string according to the pre-configured key command mapping dictionary; the key command mapping dictionary defines the unique correspondence between key information and command string.

[0031] In this embodiment, the pre-configured key command mapping dictionary is a data structure (e.g., YAML file, JSON object, or Python dictionary) stored in the robot or control platform, used to define the unique correspondence between the key information (including key identifiers and optional long / short press states) of the wireless input device and the command string.

[0032] Command strings are human-readable, semantic text identifiers used to abstractly represent the operations expected of the robot, such as "RELOCATE" for relocation, "STOP" for stopping, "CONTINUE" for continuing, and "POWER_OFF" for shutting down.

[0033] The mapping dictionary is generated as follows: During the development phase, the developer writes a readable parameter file (such as config / params.yaml) using a text editor or configuration tool, based on the physical button layout of the wireless input device (such as a laser pointer) and the list of functions supported by the robot. In this file, the developer defines the mapping entries "button identifier = command string" or "button identifier_long press = command string" line by line. When the robot starts, the control node dynamically loads this file and builds the mapping table in memory.

[0034] For example, a specific mapping dictionary entry might be: "KEY_ENTER_SHORT":"CONTINUE", indicating that a short press of the Enter key corresponds to the continue command; and "KEY_TAB_LONG":"POWER_OFF", indicating that a long press of the Tab key corresponds to the power off command. This pre-configuration method allows users to adjust key functions without modifying any source code, greatly enhancing the system's flexibility and customizability.

[0035] It should be noted that, when the robot is connected to the host computer, it can receive a first preset requirement input from the host computer to update the pre-configured key command mapping dictionary.

[0036] In this embodiment, when the robot is connected to a host computer (e.g., a personal computer, tablet, or cloud management platform), the user or developer can send a first preset request to the robot via the host computer to dynamically update the pre-configured key command mapping dictionary. The first preset request refers to an instruction or configuration file containing mapping entries to be modified, added, or deleted; its format can be JSON, YAML, or simple key-value pair text. Upon receiving the request, the robot parses its contents and replaces or merges them into the current key command mapping dictionary, thereby achieving online reconfiguration of key functions without restarting the node or recompiling the code.

[0037] For example, suppose that in the current mapping dictionary, short-pressing the KEY_UP key corresponds to "NULL" (i.e., no function), and the user wants to change it to control the robot to take a picture. The user can write an update command on the host computer: {"action":"update","mapping":"KEY_UP_SHORT=CAMERA"}, and send it to the robot via ROS2 service or HTTP interface. After the robot receives and processes it, the new mapping relationship takes effect immediately; thereafter, short-pressing the KEY_UP key will output the command string "CAMERA", thereby triggering the picture-taking action. Similarly, the user can also delete or modify existing mappings, such as changing KEY_ENTER_SHORT from "CONTINUE" to "START_ALL" to adapt to different process scenarios. This design allows the control method of this application to flexibly adapt to different operating habits or task requirements without interrupting robot operation.

[0038] The core function of step S12 is to convert the raw, low-level key information into command strings that the upper-level control logic can understand. Specifically, when a wireless input device node (such as key_node) captures a key event (e.g., the key identifier is KEY_ENTER, and it is determined to be a short press by calculating the time difference between pressing and releasing, lasting 0.3 seconds), the node will use the key information (which can be expressed as "KEY_ENTER_SHORT") as the lookup key to query the pre-loaded key command mapping dictionary. If a matching entry is found in the dictionary, the corresponding command string (e.g., "CONTINUE") is retrieved; if no matching entry is found (e.g., the key or the long / short press mode is not defined in the dictionary), the event is discarded and optionally logged. The parsed command string will be used for subsequent topic publishing and robot control command conversion.

[0039] For example, suppose a user briefly presses the Enter key on a laser pointer. The system generates key information as {identifier: KEY_ENTER, duration: 0.3 seconds}. Based on the configuration of "KEY_ENTER_SHORT":"CONTINUE" in the mapping dictionary, step S12 will output the command string "CONTINUE". If the user presses and holds the same key for 2.5 seconds, the duration in the key information will be 2.5 seconds, the mapped key will change to "KEY_ENTER_LONG", and if the dictionary corresponds to "POWER_OFF", then "POWER_OFF" will be output. In this way, the same physical key can achieve multiple functions by distinguishing durations, without the need to add an extra key.

[0040] Regarding step S13, the pre-created wireless input device node in the robot publishes the command string to a predefined topic, so that the target node in the robot that has subscribed to the predefined topic receives the command string, parses the command string into the corresponding robot control instruction based on the pre-configured command instruction mapping dictionary, and triggers the actuator corresponding to the robot control instruction to perform the target action corresponding to the robot control instruction.

[0041] Pre-created wireless input device node: This refers to a dedicated node (e.g., named key_node) that is pre-written and started in the robot's ROS2 software package. This node is responsible for reading raw key events from the wireless input device (such as a laser pointer receiver) from the operating system and converting them into a data format that can be processed by subsequent processes. For example, key_node opens the device file / dev / input / event0 during initialization and enters a loop listening state.

[0042] Predefined topic: In the ROS2 communication framework, a topic with a pre-agreed name is used to carry the command string parsed from keystrokes. The topic name is usually a string identifier, such as / laserpen_command. Publishers and subscribers communicate decoupledly using this name.

[0043] Target nodes that have subscribed to the predefined topic: These are nodes that declare to the ROS2 host at startup that they "want to receive messages on the / laserpen_command topic". These nodes may be automatic power-on / off nodes (auto_power_mgr_node), motion control nodes, dance intervention nodes, etc. Each target node decides whether to process the received command string based on its own responsibilities. For example, if auto_power_mgr_node subscribes to / laserpen_command, it only cares about the strings "POWER_ON" and "POWER_OFF".

[0044] A pre-configured command mapping dictionary: This is a data structure (e.g., a YAML file or Python dictionary) stored in the robot or control platform, used to define the unique correspondence between command strings and the robot's underlying control instructions. Robot control instructions are binary commands or service call parameters that the robot drive system can directly execute, such as calling `SetPower(1)` to power on or `StopMotion()` to stop. For example, a command mapping dictionary entry might be: "CONTINUE":{"service":" / robot / resume","params":{}}, indicating that the command string "CONTINUE" is mapped to calling the ` / robot / resume` service; "POWER_OFF":{"function":"SetPower","arg":0} indicates that it is mapped to calling the underlying `SetPower(0)` function.

[0045] When the robot is connected to the host computer, it can receive a second preset requirement input from the host computer to update the pre-configured command instruction mapping dictionary.

[0046] In this embodiment, when the robot maintains a communication connection with a host computer (such as a personal computer, debugging terminal, or cloud-based operation and maintenance platform), the user can input a second preset requirement into the host computer to dynamically update the pre-configured command instruction mapping dictionary. The command instruction mapping dictionary defines the correspondence between semantic command strings (such as "CONTINUE", "POWER_OFF") and the robot's underlying executable control instructions (such as calling a specific ROS2 service, writing to the driver register, sending serial port commands, etc.). The second preset requirement can be a text containing modification instructions, a configuration file, or a piece of structured data (such as JSON format). After receiving it, the robot will parse and update the mapping table in memory, causing the original command string to trigger a new underlying action, or adding control logic corresponding to the new command string.

[0047] For example, suppose the command string "STOP" in the current dictionary is mapped to calling the emergency stop service / emergency_stop; the user wants to change the semantics of this string to "gentle stop" (i.e., a gradual stop rather than an instantaneous stop). The user can send a second preset request on the host computer: {"action": "update", "command": "STOP", "new_target": " / gentle_stop"}. After receiving this, the robot changes the mapping target of "STOP" from the emergency stop service to the gentle stop service. Afterward, when the user presses the stop button on the stylus, the system still outputs the command string "STOP", but the underlying action becomes a gentle stop. In this way, the robot's response behavior can be flexibly adjusted without modifying any button mappings or upper-level logic, which is especially suitable for scenarios where the same button requires different control precision under different working conditions.

[0048] Step S13 realizes the conversion and execution from semantic command strings to actual robot actions. The specific process is divided into three sub-stages: publishing, receiving and parsing, and execution.

[0049] In step S13, the wireless input device node (e.g., key_node) acquires, converts, and publishes the command string through the following sub-steps.

[0050] Regarding the handling of wireless input device nodes: First, after the node starts, it enters an infinite loop, continuously listening to the input device file (e.g., / dev / / input / event0) by calling dev.read_loop(), capturing the raw event stream of wireless input devices such as laser pointers in real time; second, the event stream is filtered to only select events of type "key" (event.type== The node first uses `ecodes.EV_KEY` to discard other irrelevant events (such as mouse movement and touch). Then, it performs a command mapping operation. Internally, the node has a pre-built key command mapping dictionary (`key_command_map`) that establishes a one-to-one correspondence between physical key codes (e.g., `KEY_ENTER`, `KEY_DOWN`, `KEY_TAB`) and their corresponding standardized command strings (e.g., "CONTINUE", "STOP", "RELOCATE"). The node uses the captured key code as the key to query this dictionary. If a match is found, the corresponding command string is obtained; otherwise, the key is ignored. Finally, the node encapsulates the obtained command string into a ROS2 standard message (`std_msgs / msg.String`) and broadcasts it as a publisher through a predefined topic (e.g., ` / laserpen_command`). Through this process, the raw, hardware-dependent key signals are successfully converted into platform-independent, semantically clear control command strings, laying the data foundation for subsequent subscription and execution by target nodes.

[0051] Once the above command string is published to the / laserpen_command topic, all target nodes in the system that have subscribed to this topic will receive the message and enter the target node's receiving, parsing, and execution process.

[0052] Regarding the reception, parsing, and execution of target nodes: Each target node (e.g., auto_power_mgr_node, navigation_control_node), upon receiving a command string, queries its local pre-configured command instruction mapping dictionary. This dictionary defines the mapping relationship between the command string and the robot's underlying control instructions. For example, for auto_power_mgr_node, its dictionary might contain: "CONTINUE" mapped to calling the navigation service / resume_navigation, "STOP" mapped to calling the emergency stop service / emergency_stop, and "POWER_OFF" mapped to calling the power service / set_power 0. The node parses the string (e.g., "CONTINUE") into the corresponding underlying instruction (e.g., a service request / resume_navigation with empty parameters) based on the dictionary. Finally, the target node triggers the actuator corresponding to the robot control instruction to perform the target action. For example, a client calling the navigation service sends a request to resume the robot's chassis motor controller from paused path tracking; or the power management module is invoked to power down the joint motors. Actuators include, but are not limited to, motor drivers, power relays, and audible alarms.

[0053] Taking a specific scenario as an example: The user briefly presses the KEY_ENTER key on the laser pointer, and in step S12, the command string "CONTINUE" is obtained. The key_node publishes this string to / laserpen_command. After subscribing to this string, the auto_power_mgr_node queries the command mapping dictionary and obtains "call / robot / navigation / resume service," then sends a request to that service. The robot then resumes its movement from the pause point. This completes one button control cycle.

[0054] Further, triggering the actuator corresponding to the robot control command to perform the target action corresponding to the robot control command includes: Obtain the robot's first actual state from a pre-created robot state node; If the first actual state satisfies the preconditions for executing the robot control command, the actuator corresponding to the robot control command is triggered to execute the target action corresponding to the robot control command.

[0055] Pre-created robot status node: This refers to a dedicated ROS2 node (e.g., robot_status_node) that runs pre-built within the robot software system. This node subscribes to underlying driver or sensor data to maintain and provide other nodes with the robot's current status information in real time, such as power status, operating mode, position coordinates, and error codes. This node typically provides a query interface (e.g., service / get_robot_state or shared topic / robot_state) for other nodes to retrieve the latest status as needed.

[0056] First Actual State: This refers to the robot's current actual state value obtained from the robot state node before executing a certain control command. For example, the query result may show the power status as POWER_OFF (power off), the motion status as RUNNING (moving) or STOPPED (stopped), and the mode status as MANUAL (manual mode).

[0057] The preconditions for executing robot control commands refer to a series of state requirements that the robot must meet before executing a specific robot control command. Only if these conditions are met is the command allowed to be executed; otherwise, it should be rejected or delayed. For example, the precondition for executing the "Power On" command could be "the robot is currently in a power-off state (POWER_OFF) and not connected to a charger"; the precondition for executing the "Continue Navigation" command could be "the robot is currently in a paused state (PAUSED) and its positioning is reliable".

[0058] Actuators: These refer to the hardware components in a robot that directly perform specific physical actions, including but not limited to motor drivers, servo motors, electromagnetic relays, hydraulic cylinders, pneumatic valves, speakers, indicator lights, etc. For example, the chassis motor drives the wheels to rotate, and the power relay controls the power on / off of the joints.

[0059] Target action: refers to the physical behavior or state transition that the robot is expected to complete, such as "move forward 1 meter", "power on the joints", "stop all movement", "sound an alarm", etc. Specific example: when the control command is "POWER_ON", the target action is "to close the robot's main power relay and provide power to the joint motors".

[0060] This application's embodiments define a state check mechanism before executing control commands. Specifically, before triggering the actuator to execute the target action, the system first obtains the robot's first actual state (i.e., the current real state) through a pre-created robot state node, and then determines whether the state meets the preconditions required by the command. Only when the conditions are met (e.g., confirming that the robot is indeed in a "paused" state before executing the "continue" command) is the actuator action allowed to be triggered; if the conditions are not met (e.g., the robot is already running but receives a "continue" command again), the command will not be executed. This design can effectively avoid malfunctions caused by inconsistent states. For example, sending a "stop" command when the robot is already powered off will not produce any invalid operation, or rejecting a "forward" command when the robot is in fault protection mode to prevent danger. At the same time, this mechanism also makes the control logic more complete: different commands can define their own reasonable preconditions. For example, the "power on" command can only be executed in the powered-off state, and the "power off" command can only be executed in the powered-on and stationary state. Through this state pre-check, the system can automatically filter out untimely or redundant control requests, thereby ensuring that the robot always operates in a safe and controllable process.

[0061] Furthermore, if the first actual state does not meet the preconditions for executing the robot control command, a feedback signal indicating that the robot control command execution has failed is generated.

[0062] Specifically, upon receiving a control command (such as "power on"), the system first obtains the current state (such as "power on") from the robot's state node. If the state does not meet the prerequisites required by the command (such as the "power on" command requiring the robot to be "power off"), the system will not blindly attempt to execute the command, but will immediately generate a feedback signal indicating execution failure.

[0063] The feedback signal can be an error code, a log message, a ROS2 status message, or a pop-up notification on the host computer interface. It informs the operator or upper-level controller that the command failed to execute, along with the reason for the failure (e.g., "The robot is already powered on; no need to power it on again"). The benefits of this mechanism are twofold: firstly, it avoids logical confusion or hardware conflicts caused by repeatedly sending invalid commands or forcibly executing commands in inappropriate states (e.g., resending a power-on command when the robot is already powered on may trigger a power module malfunction); secondly, through proactive feedback, the operator can promptly learn the reason why the command was not executed, thus taking the correct subsequent actions (e.g., checking the robot's status or sending other commands), instead of repeatedly pressing buttons or blindly waiting in the absence of a response. Furthermore, this feedback signal can be recorded for fault diagnosis or log analysis, providing a basis for system debugging and maintenance.

[0064] Furthermore, after triggering the actuator corresponding to the robot control command to perform the target action corresponding to the robot control command, the method further includes: Obtain the second actual state of the robot from a pre-created robot state node; If the second actual state meets the expected conditions after the robot control command is executed, a feedback signal indicating that the robot control command has been successfully executed is generated.

[0065] The second actual state refers to the robot's true state obtained by querying the pre-created robot state node again after the system has executed robot control commands (such as power on, stop, continue, etc.). This state is used to verify whether the command was successfully executed. For example, after sending the "joint power on" command, if the queried power status is POWER_ON (powered on), then the second actual state is POWER_ON.

[0066] The expected conditions after the execution of the robot control command refer to the state characteristics that the robot should exhibit after the successful execution of a specific control command. This condition is used to determine whether the execution result meets expectations. For example, for the "power on" command, the expected condition could be "the robot's power status is POWER_ON and the joint enable signal is normal"; for the "stop" command, the expected condition could be "the motion state is STOPPED and both linear velocity and angular velocity are 0"; for the "repositioning" command, the expected condition could be "the positioning initialization flag is true and the coordinate accuracy is within the specified range".

[0067] For example, when a user sends a "power off" command (command string "POWER_OFF") via a laser pointer, the target node invokes the underlying power-off service, and the system immediately obtains the second actual state from the robot's state node. If the query result is POWER_OFF, and the expected condition after power-off is "power state equals POWER_OFF", then the condition is met; if the query result is still POWER_ON, it indicates that power-off has failed and the expected condition has not been met.

[0068] In this embodiment, after triggering the actuator to complete the target action (e.g., calling the motor stop service, power-on service, etc.), the system does not immediately consider the instruction successful. Instead, it retrieves the robot's second actual state from a pre-created robot state node and compares this state with the expected conditions that should be achieved after the instruction is executed. Only when the second actual state meets the expected conditions (e.g., the robot's linear velocity is confirmed to be 0 after the "stop" instruction) does the system generate a "successfully executed" feedback signal; if the conditions are not met, no success signal should be generated, or a failure signal may be generated optionally. This design ensures the integrity of the control closed loop: it is not merely "issuing an instruction and assuming it is effective," but objectively confirming whether the action has truly been completed through actual state readback.

[0069] For example, in complex industrial environments, anomalies such as communication packet loss, motor driver response delays, mechanical jamming, or power relay contact sticking may occur, causing commands to be sent but the actuators not to actually change their state. Without post-execution state verification, the upper-level control logic may mistakenly assume the robot is in the desired state, thus sending subsequent erroneous commands (e.g., continuing to send path planning commands before the robot has truly stopped). By introducing a second actual state check, execution anomalies can be detected promptly, and remedial measures (such as retrying, alarms, or switching to a safe mode) can be taken, significantly improving the reliability of the control system and its robustness to abnormal operating conditions. Simultaneously, the generated "successful execution" feedback signal can serve as a reliable basis for higher-level task scheduling or log recording, facilitating operator confirmation that each key press command has truly translated into the expected robot action.

[0070] In summary, this application embodiment pre-configures a key command mapping dictionary to parse the key information of wireless input devices (such as laser pointers) into semantic command strings. The wireless input device node then publishes this string to a predefined topic, allowing target nodes subscribed to that topic to receive the string and convert it into underlying robot control commands based on another pre-configured command instruction mapping dictionary, ultimately triggering the actuator to complete the target action. This two-layer mapping combined with topic communication design ensures that the correspondence between keys and functions is entirely defined by an editable configuration file, decoupling it from the robot's underlying firmware and hardware drivers. Therefore, operators do not need to memorize complex physical key layouts; they can complete various control tasks using a portable laser pointer with a very small number of keys. Furthermore, when adjusting key functions or adapting to different robots, only the configuration file needs to be modified, without recompiling or replacing the firmware, significantly improving the flexibility and cross-platform portability of the control system.

[0071] Furthermore, before executing control commands, the system first acquires the robot's first actual state. The actuator is only triggered if this state meets the preconditions required by the command; otherwise, a failure feedback signal is generated. After the command is executed, the system acquires the second actual state again and compares it with the expected conditions. A success feedback signal is generated only if the expectations are met. This closed-loop mechanism of pre-execution checking and post-execution confirmation effectively prevents malfunctions or resource conflicts caused by inconsistent states (such as repeatedly sending power-on commands or the robot not truly stopping). Simultaneously, real-time feedback allows the operator to clearly understand whether the command has been adopted and the reason. In addition, when the robot is connected to a host computer, the user can input preset requirements to dynamically update the key command mapping dictionary or command instruction mapping dictionary. This allows for adjustments to the control logic or response behavior as needed without interrupting robot operation, greatly reducing the difficulty of on-site debugging and functional expansion. If the wireless input device uses a laser pointer with 2 to 6 buttons and records the button identifiers and durations, the same physical button can be used to distinguish different commands by long and short presses. This further enriches the controllable command set while maintaining the device's lightweight and portable nature, making operation more intuitive and efficient.

[0072] The embodiments of this application are based on Figure 2 The control flowchart of the navigation robot shown provides a relatively complete example corresponding to the aforementioned robot control method.

[0073] Imagine an indoor navigation robot equipped with ROS2 and a laser pointer with five buttons (TAB, ENTER, DOWN, UP, and B) as a wireless input device. The robot is initially powered off. The operator wants the robot to start from the initial point, traverse multiple navigation points sequentially, and then automatically return to the starting point and power off.

[0074] Power-on phase: The operator presses the TAB key twice consecutively at any position (each press lasting ≥2 seconds). The first long press triggers "Power-on confirmation," and the system outputs the message "POWER_ON_CONFIRM," confirming that the robot is currently powered off. If a second long press is detected within 5 seconds, the laser pen button node (key_node) parses the two long press events into the command string "LONG_TAB" according to the pre-configured button command mapping dictionary and publishes it to the / laserpen_command topic. After the automatic power-on node (auto_power_mgr_node) subscribes to this command, it calls the robot's underlying power-on service SetPower(1), powering on the robot joints and automatically switching to zero-torque mode. At the same time, it publishes the status / robot_control_status: "POWER_ON," indicating that power-on is complete. If there is no second long press within 5 seconds, power-on is canceled.

[0075] Navigation Initiation: With the robot at the navigation starting point and powered on, the operator briefly presses the ENTER key (duration < 2 seconds). The key_node parses the command string "RELOCATE" (or maps it to "CONTINUE") and publishes it to the topic. The navigation control node subscribed to this topic receives the command, calls the relocation service to initialize the robot's position and attitude, and then the robot enters path planning mode, beginning autonomous navigation to the first point and executing the point procedures sequentially.

[0076] Mid-course intervention: If an obstacle is encountered during navigation, an emergency pause is required. The operator briefly presses the DOWN key, and the system generates and issues the command string "STOP". Upon receiving this command, the motion control node stops the robot within one second. After the obstacle is cleared, the operator briefly presses the ENTER key again, and the robot receives the "CONTINUE" command, resuming execution of the remaining points from the pause point.

[0077] Endpoint Judgment and Return: The laser pointer button node constantly listens to the trajectory point topics posted by the robot to determine whether it is currently at the last point in the navigation trajectory. If the robot has not yet reached the last point, it continues to execute the point-point process normally; once it detects that it has reached the last point, the system waits for a continuation command. If the operator briefly presses the ENTER key again, the robot interprets it as a "CONTINUE" command, but since it is in the endpoint state, the control logic interprets it as "return to the initial point," so the robot autonomously navigates back to the starting position (equivalent to a reset).

[0078] Shutdown Phase: The robot returns to its initial position and is powered on. The operator presses the TAB key twice consecutively (each time for ≥2 seconds). The auto_power_mgr_node calls the power-down service SetPower(0), de-energizing the robot joints. However, the onboard computer continues to run, and the ROS2 node continues to work, publishing the status / robot_control_status: "POWER_OFF". All nodes subscribed to this topic are aware that the robot has been powered off. Throughout the process, the UP key remains empty and has no function. The B key can be reserved for other extended commands (such as taking photos, switching modes, etc.). Through the above operations, the operator only needs to use three keys: TAB (long press for power on / off), ENTER (short press for relocation / continue / reset), and DOWN (short press for emergency stop) to complete the entire process of robot control from power-on, navigation, pause, resumption, endpoint reset to shutdown.

[0079] Based on the same inventive concept, the embodiments of this application provide, as follows: Figure 3 A robot control method is shown, the method comprising: Step S31: Write a first software function package into the workspace of the first robot to be controlled via the host computer. The first software function package originates from the workspace of the second robot and is encapsulated based on a robot control method as described above. The second robot is controlled by the connected first wireless input device and the first software function package. Step S32: The host computer identifies the device code of the first robot and updates the device code into the first software function package written to the first robot, thereby obtaining the second software function package; Step S33: Establish a connection between the first robot and the second wireless input device, and control the first robot through the second wireless input device and the second software function package.

[0080] It should be noted that the first robot and the second robot can be the same type of robot or different types of robots.

[0081] This application provides a specific process for the rapid reuse and deployment of robot control methods across different robot platforms. First, a first software function package is written into the workspace (e.g., ROS2 space) of the first robot to be controlled via a host computer (e.g., a personal computer or debugging terminal). This function package is copied from the workspace of the already deployed second robot (i.e., the source robot), and it is encapsulated based on the aforementioned control method. On the second robot, this function package, in conjunction with its connected first wireless input device (e.g., a laser pointer), enables button control.

[0082] Subsequently, the host computer identifies the device code of the first robot (e.g., the USB input event number corresponding to the laser pointer receiver, such as / dev / input / event0 or / dev / input / event3), and updates the device code to the parameter configuration file written in the first software function package of the first robot, thereby generating a second software function package adapted to the hardware configuration of the first robot.

[0083] Finally, a wireless connection is established between the first robot and a second wireless input device (which can be the same model as the first wireless input device, in which case no adjustment to the function package is needed; or it can be a different model laser pointer, in which case the relevant content of the function package may need to be adjusted according to the button of the laser pointer). The first robot is then controlled by buttons through the second wireless input device and the updated second software function package. This process achieves cross-platform portability capability of "one-time packaging, multiple reuse": users do not need to rewrite control code for each robot, but only need to copy the function package and modify the device number to allow the new robot to quickly obtain the same button control capability as the source robot, significantly reducing the deployment time and programming threshold of multiple robots.

[0084] Suppose there is a fully debugged robot A (the second robot) in the laboratory. This robot runs a laser pen control function package `laserpen_control_pkg` based on the method described in this application, and the input device number corresponding to the laser pen receiver connected to robot A is ` / dev / input / event0`. The operator can perform all operations such as powering on, navigating, pausing, resuming, and powering off using the laser pen on robot A. Now, it is necessary to deploy the same button control capabilities to another field operation robot B of the same model (the first robot).

[0085] The operator first logs into the ROS2 workspace of robot B via SSH using a host computer (laptop), and copies the entire laserpen_control_pkg folder from robot A to the src directory of robot B. Then, the operator inserts the laser pointer's wireless receiver into robot B's USB port and executes the command `cat / proc / bus / input / devices` on robot B, finding that the input device event number corresponding to the receiver is event3 (i.e., the device path is / dev / input / event3). Next, the operator opens the configuration file `config / params.yaml` in the copied package, modifies the `device_path` parameter from ` / dev / input / event0` to ` / dev / input / event3`, and saves the file. Simultaneously, based on on-site operational habits, the operator changes the default blank `KEY_UP` setting in the key mapping dictionary to "TOGGLE_LED" (to control the flashing of the on-site warning light). After saving, recompile the function package (colconbuild--packages-selectlaserpen_control_pkg) on ​​robot B and refresh the environment variables to generate the second software function package adapted for robot B.

[0086] Finally, the operator pairs the same laser pointer (or another laser pointer of the same model) with the receiver of robot B, activating the laser pointer control node of robot B. When the operator briefly presses the KEY_ENTER key on the laser pointer, robot B successfully completes repositioning and begins navigation; a brief press of the KEY_DOWN key stops robot B's movement within one second; and two consecutive long presses of the TAB key successfully power on or off robot B. Thus, by copying the function package, modifying the device number, and mapping configuration, robot B gains the exact same laser pointer button control capability as robot A without rewriting any control code.

[0087] In summary, the embodiments of this application enable rapid reuse and seamless migration of control functions between different robots. Specifically, since the first software function package fully encapsulates core control logic such as key monitoring, command mapping, topic publishing, and status feedback, and these logics are independent of the robot's underlying hardware and specific model, relying only on the communication framework and interface (such as the ROS2 communication framework and the Linux input subsystem standard interface), no redevelopment of any code is required when copying this function package from a debugged second robot to the first robot. By identifying the device code of the first robot (e.g., the input event number corresponding to the laser pointer receiver) by the host computer and updating the code in the function package's parameter configuration file, the adaptation to the first robot's hardware environment can be completed. In this process, the user only needs to modify the device path parameters in the configuration file, without modifying any node source code or recompiling the underlying firmware, to generate a second software function package specifically for the first robot. Subsequently, by connecting the second wireless input device (such as a laser pointer) to the first robot, complete key control of the first robot can be implemented through the device and the second software function package, including a series of operations such as power on, navigation, pause, resume, and power off. Therefore, the embodiments of this application realize the cross-platform portability of "one-time packaging, multi-machine deployment", which greatly reduces the time cost and programming threshold of repeatedly configuring control functions on multiple robots. Even if the robot models are different or the input device numbers change, only a few parameters in the configuration file need to be modified to complete the adaptation, which significantly improves the universality and scalability of the control system, while avoiding the repetitive labor and maintenance burden caused by "one remote control for one machine and one firmware for one process" in the traditional solution.

[0088] Based on the same inventive concept, the embodiments of this application provide, as follows: Figure 4 An electronic device shown includes: Processor 41; Memory 42 is used to store executable instructions of the processor 41; The processor 41 is configured to execute a robot control method as described above.

[0089] Based on the same inventive concept, embodiments of this application provide a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform a robot control method as described above.

[0090] Since the electronic device described in this embodiment is an electronic device used to implement the information processing method in the embodiments of this application, those skilled in the art can understand the specific implementation methods and various variations of the electronic device in this embodiment based on the information processing method described in the embodiments of this application. Therefore, how the electronic device implements the method in the embodiments of this application will not be described in detail here. Any electronic device used by those skilled in the art to implement the information processing method in the embodiments of this application falls within the scope of protection of this application.

[0091] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0092] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0093] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0095] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0096] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A robot control method, characterized in that, The robot is connected to a wireless input device, and the method includes: Receive key information sent by the wireless input device, the key information being generated by triggering at least one key of the wireless input device; Based on a pre-configured key command mapping dictionary, the key information is parsed into corresponding command strings; the key command mapping dictionary defines a unique correspondence between key information and command strings. The command string is published to a predefined topic by a wireless input device node pre-created in the robot, so that the target node in the robot that has subscribed to the predefined topic receives the command string. Based on a pre-configured command instruction mapping dictionary, the command string is parsed into the corresponding robot control instruction, and the actuator corresponding to the robot control instruction is triggered to perform the target action corresponding to the robot control instruction.

2. The robot control method as described in claim 1, characterized in that, Triggering the actuator corresponding to the robot control command to perform the target action corresponding to the robot control command includes: Obtain the robot's first actual state from a pre-created robot state node; If the first actual state satisfies the preconditions for executing the robot control command, the actuator corresponding to the robot control command is triggered to execute the target action corresponding to the robot control command.

3. The robot control method as described in claim 2, characterized in that, If the first actual state does not meet the preconditions for executing the robot control command, the method further includes: Generate a feedback signal indicating that the robot control command failed to execute.

4. The robot control method as described in claim 1, characterized in that, After triggering the actuator corresponding to the robot control command to perform the target action corresponding to the robot control command, the method further includes: Obtain the second actual state of the robot from a pre-created robot state node; If the second actual state meets the expected conditions after the robot control command is executed, a feedback signal indicating that the robot control command has been successfully executed is generated.

5. The robot control method as described in claim 1, characterized in that, The robot is connected to a host computer, and the method further includes: Receive the first preset requirement input from the host computer to update the pre-configured key command mapping dictionary; and / or, The system receives a second preset requirement from the host computer to update the pre-configured command and instruction mapping dictionary.

6. The robot control method as described in claim 1, characterized in that, The wireless input device is a laser device, and the laser device has 2 to 6 buttons.

7. The robot control method as described in claim 1, characterized in that, The key information includes at least the key identifier and the duration.

8. A robot control method, characterized in that, The method includes: The host computer writes a first software function package into the workspace of the first robot to be controlled. The first software function package originates from the workspace of the second robot and is encapsulated based on a robot control method as described in any one of claims 1 to 7. The second robot is controlled by a connected first wireless input device and the first software function package. The host computer identifies the device code of the first robot and updates the device code into the first software function package written into the first robot, thereby obtaining the second software function package; Establish a connection between the first robot and the second wireless input device, and control the first robot through the second wireless input device and the second software package.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute a robot control method as described in any one of claims 1 to 8.

10. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform a robot control method as described in any one of claims 1 to 8.

Images