A robot data acquisition and remote control method based on command queue polling

Abstract

This invention relates to the field of IoT security technology and discloses a method for robot data acquisition and remote control based on command queue polling. By deploying an intermediate forwarding server, the data reporting address of the target robot is redirected to the intermediate server. The server adopts a hybrid protocol architecture of receiving uplink data via HTTP and broadcasting to monitoring clients via WebSocket, enabling real-time forwarding of robot video streams and other data. Simultaneously, a command queue and status marking mechanism are initialized on the server side. The control terminal submits control commands to the queue via HTTP, and the robot retrieves unexecuted commands from the command queue in a polling manner and executes the actions. This invention achieves remote control and data acquisition of IoT robots solely through traffic redirection, overcoming access restrictions in intranet and NAT environments, and unifying the processing of uplink data streams and downlink control streams, providing technical support for the design of IoT security detection and protection solutions.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security technology, and in particular to a method for robot data acquisition and remote control based on command queue polling. Background Technology

[0002] With the rapid development of IoT technology and the intelligent robot industry, intelligent robots, represented by quadrupedal robot dogs, are widely used in industrial inspection, security monitoring, and logistics transportation. These robots are typically equipped with cameras, sensors, and other devices, and transmit data and interact with monitoring clients via networks. However, security vulnerabilities in robot control systems are becoming increasingly prominent. Attackers may use various means to obtain sensor data from robots or control them to perform unauthorized operations, posing a significant threat to the information security of enterprises and users.

[0003] In robot safety testing, remote control and data theft are among the core challenges facing IoT robots. Remote control of robots involves the integrity and confidentiality of command transmission, while the transmission of sensor data (such as video streams and location information) concerns user privacy and trade secrets. If attackers can hijack control channels or steal data streams, they can not only obtain sensitive information but also potentially remotely control robots to perform malicious actions. Therefore, in-depth research into the security mechanisms of remote control and data forwarding is crucial for discovering potential vulnerabilities and improving protective measures.

[0004] However, existing technologies still have shortcomings in the security detection research of remote control and data forwarding of IoT robots, mainly facing the following challenges:

[0005] Limitations of intranet devices: IoT robots are typically deployed in intranet environments, protected by NAT (Network Address Translation), making it difficult for security researchers to conduct penetration tests on these devices from the outside. Existing security testing frameworks mostly rely on direct network connections and lack effective testing methods for isolated intranet scenarios.

[0006] Protocol compatibility issues: Embedded devices such as robots typically only support the basic HTTP protocol, while real-time data acquisition and command injection in security testing require low-latency communication support. Existing testing tools struggle to achieve real-time interaction while ensuring compatibility, limiting the depth of security assessments.

[0007] Unified processing of bidirectional data streams: Existing security testing solutions often only focus on a single data channel and lack the ability to comprehensively evaluate uplink data streams (such as the risk of video stream leakage) and downlink control streams (such as the risk of command injection), making it difficult to fully reveal the security vulnerabilities of the system.

[0008] Command transmission reliability: During security testing, it is difficult to confirm whether test commands are correctly received and executed by the target device. The lack of an effective state tracking mechanism leads to insufficient reliability and repeatability of test results.

[0009] By studying remote control and data acquisition methods for IoT robots, potential security vulnerabilities in robot control systems can be discovered, aiding in the systematic identification and effective remediation of these vulnerabilities. This approach can not only be used to test and verify the effectiveness of existing protection mechanisms but also further promote the development of IoT security technologies. Summary of the Invention

[0010] To address the aforementioned problems in existing technologies, this invention aims to provide a robot data acquisition and remote control method based on command queue polling. This method aims to discover potential security vulnerabilities in IoT robot systems, promote the development of IoT security defense technologies, and enhance the detection and defense capabilities against new attack methods. The technical solution is as follows:

[0011] A method for robot data acquisition and remote control based on command queue polling includes the following steps:

[0012] S1: Deploy the intermediate forwarding server and configure the data receiving endpoint, real-time communication endpoint, command receiving endpoint, and command polling endpoint;

[0013] S2: Initialize the command queue in the intermediate forwarding server and establish a command storage and status marking mechanism;

[0014] S3: Configure the target robot's data reporting address as the data receiving endpoint of the intermediate forwarding server, so that the data stream reported by the robot is redirected to the intermediate forwarding server;

[0015] S4: The intermediate forwarding server receives the data reported by the robot through the data receiving endpoint, performs protocol conversion, and then broadcasts it to at least one monitoring client in real time through the real-time communication endpoint.

[0016] S5: The intermediate forwarding server receives control commands from the monitoring client through the command receiving endpoint, verifies them, writes the control commands as new commands into the command queue, and marks them as pending execution.

[0017] S6: The robot initiates a polling request to the intermediate forwarding server through the command polling endpoint. In response to the polling request, the intermediate forwarding server searches for and returns a command in the pending execution state from the command queue to the robot, and updates the status of the command at the same time.

[0018] S7: The monitoring client repeatedly sends control commands through the data channel that has already established a connection with the intermediate forwarding server to complete the polling.

[0019] The technical solution provided by this invention has the following technical effects:

[0020] 1. By using a command queue polling mechanism, the robot can actively obtain commands without requiring the device to have a public IP address, effectively solving the NAT traversal problem;

[0021] 2. The HTTP-WebSocket hybrid protocol architecture is adopted, and the robot only needs to support the basic HTTP protocol, which reduces the requirements for device capabilities and improves the compatibility of the solution;

[0022] 3. By tracking the command fetching status through a status marking mechanism, the reliability of command transmission is improved, ensuring that each command is executed only once.

[0023] 4. Uplink data flow and downlink control flow are processed uniformly on the same server, realizing complete bidirectional data forwarding;

[0024] 5. Remote control and data acquisition can be achieved through traffic redirection without modifying the robot firmware or installing additional software, making it non-intrusive.

[0025] The technical solution of this invention can effectively reveal the security risks in the Internet of Things (IoT) robot control system, promote the development of IoT security defense technology, and thus enhance the overall defense capability. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the framework of a robot data acquisition and remote control method based on command queue polling provided by the present invention.

[0027] Figure 2 The flowchart illustrates the protocol conversion and data broadcasting process provided by this invention.

[0028] Figure 3 The flowchart illustrates the command queue polling mechanism provided by this invention. Detailed Implementation

[0029] The technical method of the present invention will be further described below with reference to the embodiments and accompanying drawings.

[0030] To reveal potential security vulnerabilities in IoT robot control systems and further enhance the security level of IoT devices, this invention demonstrates how to achieve remote control and data forwarding of IoT robots through a command queue polling-based technical solution, thereby revealing the potential risks of unauthorized control and data leakage.

[0031] like Figure 1 As shown, the method includes the following steps:

[0032] S1: Deploy an intermediate forwarding server and configure data receiving endpoints, real-time communication endpoints, command receiving endpoints, and command polling endpoints. Specifically, this includes:

[0033] S11: Use the FastAPI framework to create a web service application and configure CORS middleware to allow cross-domain access.

[0034] S12: Configure the HTTP endpoint as a data receiving endpoint to receive data reported by the robot via the HTTP protocol.

[0035] S13: Configure the WebSocket endpoint as a real-time communication endpoint to establish and maintain a real-time bidirectional communication connection with the monitoring client.

[0036] S14: Configure the HTTP endpoint as a command receiving endpoint to receive control commands sent by the monitoring client or the monitoring client via the HTTP protocol.

[0037] S15: Configure the HTTP endpoint as a command polling endpoint to respond to polling requests initiated by the robot via the HTTP protocol.

[0038] S2: Initialize the command queue and establish a mechanism for storing and marking the status of commands. Specifically, this includes:

[0039] S21: Initialize a global list of command queues.

[0040] Initialize the global command queue and define the command data structure as follows:

[0041] id: Unique identifier for the command;

[0042] command: Command name;

[0043] name: Command description in Chinese;

[0044] api_id: API identifier;

[0045] js_code: The code to be executed;

[0046] timestamp: Creates a timestamp;

[0047] pulled: Pulled state, initialized to False;

[0048] pulled_at: Pulls the timestamp, with an initial value of None.

[0049] S22: Define the data structure of the command, which includes the command identifier, command content, creation timestamp, and fetch status field.

[0050] The pull status field is used to mark whether the corresponding command has been retrieved by the robot. Its initial status is marked as not retrieved, and it is updated to retrieved status after the command is successfully returned to the robot.

[0051] S23: Define a command mapping table, which stores predefined available command identifiers and their corresponding execution codes.

[0052] The command mapping table predefines available commands, including motion control commands for controlling robot movement, and their corresponding execution codes. In this embodiment, the command mapping table includes control commands such as stand, lie down, shake hands, dance, and stop, along with their corresponding execution codes.

[0053] S3: Configure the target robot's data reporting address. Configure the target robot's data reporting address as the data receiving endpoint of the intermediate forwarding server, so that the data stream reported by the robot is redirected to the intermediate forwarding server.

[0054] By configuring the network, the robot's data reporting address is changed to the intermediate server address. The robot then sends Base64 encoded image data to the data receiving endpoint via HTTP POST at the set frame rate (e.g., 15 frames per second).

[0055] S4: Protocol Conversion and Data Broadcasting. The intermediate forwarding server receives data reported by the robot through the data receiving endpoint, performs protocol conversion, and then broadcasts it in real time to at least one monitoring client through the real-time communication endpoint. Specifically, this includes:

[0056] S41: The intermediate forwarding server parses the encoded data reported by the robot from the HTTP request received from the data receiving endpoint.

[0057] S42: Decode or convert the parsed encoded data to extract valid data content.

[0058] S43: Encapsulate valid data content into a frame format suitable for real-time communication. The frame format includes event type, data content, format identifier, and timestamp.

[0059] S44: Iterate through all monitoring clients connected via real-time communication endpoints and push encapsulated data frames to each client.

[0060] S45: During the data frame push process, detect the client's connection status and remove disconnected clients from the connection list.

[0061] like Figure 2 As shown, when data reported by the robot is received:

[0062] First, parse the JSON data in the HTTP request body and extract the Base64 encoded image content;

[0063] Then, the data is encapsulated into a WebSocket frame format, containing event type fields and data fields;

[0064] Finally, iterate through the collection of connected WebSocket clients, call the asynchronous send method to push data frames one by one, and catch any sending exceptions, removing disconnected clients from the collection.

[0065] S5: Command Writing. The intermediate forwarding server receives control commands from the monitoring client through the command receiving endpoint. After verification, it writes the control command as a new command to the command queue and marks it as pending execution. Specifically, this includes:

[0066] S51: The intermediate forwarding server receives control command requests through the command receiving endpoint.

[0067] S52: Verify that the command identifier in the control command request exists in the predefined command mapping table.

[0068] S53: If the verification passes, create a new command record according to the control command request, set its pull status to not pull, and record the creation timestamp.

[0069] S54: Add the new command record to the end of the command queue.

[0070] S55: Returns a successful command reception response to the monitoring client.

[0071] In this embodiment, the monitoring client sends control commands to the command receiving endpoint via HTTP POST. The server processing flow is as follows:

[0072] First, verify the validity of the command by checking if it exists in the predefined command mapping table;

[0073] Then, create a command information object, set the pulled state to False, and record the current timestamp;

[0074] Finally, the command is appended to the end of the command queue, and a confirmation of command receipt is returned.

[0075] S6: Command Polling Retrieval. The robot initiates a polling request to the intermediate forwarding server through the command polling endpoint. The intermediate forwarding server responds to the polling request by retrieving a command from the command queue and returning it to the robot in a pending execution state, while simultaneously updating the command's status. Specifically, this includes:

[0076] S61: The intermediate forwarding server receives polling requests from the robot through the command polling endpoint.

[0077] S62: Traverse the command queue and find the first command record whose pull status is not pulled.

[0078] S63: If a command record that meets the conditions is found, update the pull status of the command record to "pulled", record the pull timestamp, and return the command content in the command record to the robot.

[0079] S64: If no matching command record is found, return a response to the robot that no command is pending execution.

[0080] Among these features, the method of actively polling and pulling commands by the robot does not require the robot to have a public IP address, thus solving the NAT traversal problem of internal network devices; and the status marking mechanism ensures that each command is retrieved only once, guaranteeing the reliability of command execution.

[0081] like Figure 3 As shown, the robot periodically sends GET requests to the command polling endpoint, and the server processing flow is as follows:

[0082] First, traverse the command queue and find the first command with a pulled status of False;

[0083] If a command to be executed is found, the pulled status is updated to True, the current timestamp is recorded in the pulled_at field, and the command details are returned, including the command name, API identifier, and execution code.

[0084] If no command is found to be executed, a response indicating no command is to be executed is returned.

[0085] S7: The monitoring client repeatedly sends control commands through the data channel that has already established a connection with the intermediate forwarding server to complete the polling.

[0086] The monitoring client connects to the real-time communication endpoint via WebSocket;

[0087] Receive data frames pushed by the server, decode Base64 image data, and render and display it;

[0088] Count the number of received frames, calculate the real-time frame rate and transmission latency;

[0089] Commands are sent by triggering control buttons on the interface, and control commands are submitted by calling the command receiving endpoint.

[0090] In summary, this invention achieves remote control and data forwarding of IoT robots through a command queue polling mechanism. By having the robot actively poll for commands, the NAT traversal problem for internal network devices is solved; the HTTP-WebSocket hybrid protocol architecture balances device compatibility and data real-time performance; and the status marking mechanism ensures the reliability of command transmission. This technical solution reveals the potential security risks in IoT robot control systems and provides an important reference for the development of IoT security defense technologies.

Claims

1. A method for robot data acquisition and remote control based on command queue polling, characterized in that, Includes the following steps: S1: Deploy the intermediate forwarding server and configure the data receiving endpoint, real-time communication endpoint, command receiving endpoint, and command polling endpoint; S2: Initialize the command queue in the intermediate forwarding server and establish a command storage and status marking mechanism; S3: Configure the target robot's data reporting address as the data receiving endpoint of the intermediate forwarding server, so that the data stream reported by the robot is redirected to the intermediate forwarding server; S4: The intermediate forwarding server receives the data reported by the robot through the data receiving endpoint, performs protocol conversion, and then broadcasts it to at least one monitoring client in real time through the real-time communication endpoint. S5: The intermediate forwarding server receives control commands from the monitoring client through the command receiving endpoint, verifies them, writes the control commands as new commands into the command queue, and marks them as pending execution. S6: The robot initiates a polling request to the intermediate forwarding server through the command polling endpoint. In response to the polling request, the intermediate forwarding server searches for and returns a command in the pending execution state from the command queue to the robot, and updates the status of the command at the same time. S7: The monitoring client repeatedly sends control commands through the data channel that has already established a connection with the intermediate forwarding server to complete the polling.

2. The robot data acquisition and remote control method based on command queue polling according to claim 1, characterized in that, Step S1, deploying the intermediate forwarding server specifically includes: S11: Create a web service application and configure cross-domain access middleware; S12: Configure the HTTP endpoint as a data receiving endpoint to receive data reported by the robot via the HTTP protocol; S13: Configure the WebSocket endpoint as a real-time communication endpoint to establish and maintain a real-time bidirectional communication connection with the monitoring client; S14: Configure the HTTP endpoint as a command receiving endpoint to receive control commands sent by the monitoring client via the HTTP protocol; S15: Configure the HTTP endpoint as a command polling endpoint to respond to polling requests initiated by the robot via the HTTP protocol.

3. The robot data acquisition and remote control method based on command queue polling according to claim 1, characterized in that, Step S2, which initializes the command queue and establishes a command storage and status marking mechanism, specifically includes: S21: Initialize a global list of command queues; S22: Define the data structure of the command, which includes a command identifier, command content, creation timestamp, and fetch status field; S23: Define a command mapping table, which stores predefined available command identifiers and their corresponding execution codes.

4. The robot data acquisition and remote control method based on command queue polling according to claim 3, characterized in that, In step S22, the pull status field is used to mark whether the corresponding command has been acquired by the robot. Its initial status is marked as not pulled, and it is updated to the pulled status after the command is successfully returned to the robot. In S23, the predefined available commands in the command mapping table include motion control commands for controlling the robot's movement, and their corresponding execution codes.

5. The robot data acquisition and remote control method based on command queue polling according to claim 1, characterized in that, In step S4, the real-time broadcasting after protocol conversion specifically includes: S41: The intermediate forwarding server parses the encoded data reported by the robot from the HTTP request received from the data receiving endpoint; S42: Decode or convert the parsed encoded data to extract valid data content; S43: Encapsulate the valid data content into a frame format suitable for real-time communication, wherein the frame format includes event type, data content, format identifier, and timestamp; S44: Iterate through all monitoring clients connected via real-time communication endpoints and push encapsulated data frames to each client.

6. The robot data acquisition and remote control method based on command queue polling according to claim 5, characterized in that, In step S43, the frame format suitable for real-time communication is the WebSocket data frame format.

7. The robot data acquisition and remote control method based on command queue polling according to claim 5 or 6, characterized in that, Step S44 is followed by: S45: During the data frame push process, detect the client's connection status and remove disconnected clients from the connection list.

8. The robot data acquisition and remote control method based on command queue polling according to claim 1, characterized in that, Step S5 specifically includes: S51: The intermediate forwarding server receives control command requests through the command receiving endpoint; S52: Verify whether the command identifier in the control command request exists in the predefined command mapping table; S53: If the verification is successful, a new command record is created according to the control command request, its pull status is set to not pulled, and the creation timestamp is recorded; S54: Add the new command record to the end of the command queue; S55: Return a successful command reception response to the monitoring client.

9. The robot data acquisition and remote control method based on command queue polling according to claim 1, characterized in that, Step S6 specifically includes: S61: The intermediate forwarding server receives polling requests from the robot through the command polling endpoint; S62: Traverse the command queue and find the first command record whose pull status is not pulled; S63: If a command record that meets the conditions is found, update the pull status of the command record to "pulled", record the pull timestamp, and return the command content in the command record to the robot. S64: If no matching command record is found, return a response to the robot that no command is pending execution.

10. The robot data acquisition and remote control method based on command queue polling according to claim 6, characterized in that, In step S63, when the pull status of the update command record is "pulled", the timestamp of the command being pulled is also recorded.

Images