Foot type robot battle system and battle control method thereof

By introducing a main control device and a vibration module into the legged robot combat system, the system achieves accurate hit identification and macro-management, solving the problems of latency and packet loss in traditional systems and improving the system's availability and deployment efficiency.

CN122044035APending Publication Date: 2026-05-15HANGZHOU WANGXINGREN TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HANGZHOU WANGXINGREN TECHNOLOGY CO LTD
Filing Date
2026-02-05
Publication Date
2026-05-15

AI Technical Summary

Technical Problem

Traditional legged robot combat systems suffer from problems such as high latency and packet loss probability, lengthy control links, high deployment and maintenance costs, untimely status feedback, insufficient reliability of networking and configuration, and disordered combat order. In particular, they affect system availability and deployment efficiency when there is a need for temporary network replacement.

Method used

The system employs a two-sided legged robot, with combat guns and a separate main control unit mounted on its mobile shell. The main control unit includes a processor, a target vibration module, a reference vibration module, and an execution module. It adaptively identifies the vibration frequency of the hit, performs filtering, and achieves accurate identification of hit events. It also performs real-time control and status feedback via user datagram protocol, supporting rapid network switching and stable status feedback.

Benefits of technology

It achieves rapid trigger response, accurate scoring, and status synchronization, improving system availability and deployment efficiency, ensuring the stability and reliability of the battle system, and avoiding misjudgments caused by movement and vibration.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122044035A_ABST
    Figure CN122044035A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of robots, in particular to a foot-type robot battle system and a battle control method thereof.The foot-type robot battle system comprises foot-type robots camping by two parties, each foot-type robot comprises a movable shell, battle guns are arranged on the movable shells, and a main control device separated from the battle shooting guns is further arranged on the movable shells; the main control device comprises a processor, a target vibration module, a reference vibration module and an execution module, in the battle process, a battle gun of one foot type robot launches a water bomb to the other foot type robot, and the battle gun hits the moving shell and the main control device to obtain a response; the main control device adaptively recognizes hit vibration frequency and performs band-pass filtering, extremely-low-frequency attitude drift suppression and ultrahigh-frequency noise suppression processing, the processor is in communication connection with an interaction control terminal, and the interaction control terminal sends a control instruction to any foot type robot through a user datagram protocol. And receiving returned real-time state data for displaying and judging whether the hit event is true or not.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of robotics, specifically to a legged robot combat system and its combat control method. Background Technology

[0002] Traditional solutions often employ a multi-level architecture of "legged robot Linux main controller + peripheral microcontroller + mobile APP". Peripheral control requires relaying through the Linux side, resulting in long links and high coupling. Multi-level forwarding and multi-protocol bridging increase latency and packet loss probability, easily leading to problems such as delayed trigger response, missed hit scoring, and asynchronous status display. At the same time, the complexity of the software stack increases deployment and maintenance costs, makes it difficult to scale and replicate, and the redundant system architecture and excessively long control links result in latency / command loss.

[0003] Network parameters cannot be reliably saved after power outages, cannot automatically recover to the last available network after a restart, and the automatic reconnection logic is unstable. In the event of battery replacements, temporary power outages, or hotspot switching during matches, manual reconfiguration may be required; running multiple devices in parallel significantly lengthens pre-match preparation time, impacting match organization and refereeing pace. Insufficient network topology and configuration reliability affects system availability and deployment efficiency.

[0004] Interference between network configuration interaction and real-time control links can lead to "write failures," lag, and misjudgments. In similar solutions, time-consuming operations such as WiFi scanning and connection are often performed directly in the BLE write callback, causing the mobile device to perceive "write failure" or unstable connection, and the user to mistakenly judge that the network configuration is invalid. When the network configuration / scanning process and real-time UDP control are not isolated from each other, macro-control problems such as command delay, packet loss, and untimely status feedback may occur.

[0005] The lack of stable status feedback and macro-level controllability in multi-device battlefields necessitates that the battle referee system continuously monitor the key status of each device (health, firing status, network status, device IP, etc.) to support referee judgment, scoring statistics, and battlefield situation display. Existing solutions suffer from inconsistent or untimely status reporting structures, leading to potential issues on the referee's end such as "uncertain device online status," "inconsistent firing status with actual conditions," and "asynchronous damage reduction upon being hit," impacting the fairness of the battle and the system's credibility.

[0006] Once connected to the network, it is difficult to quickly switch networks or restore service, affecting continuous operations. Temporary network switching needs are common in real-world environments (site changes, AP restarts, hotspot switching, etc.). Existing solutions often bind network configuration capabilities to network connectivity, resulting in a lack of a nearby entry point for quick network switching after connection, causing equipment to "fall behind in certain areas" and impacting overall availability.

[0007] In the current battle system, water bullets fired by the battle gun are only considered a hit if they strike the sensor area of ​​the opponent's legged robot. The sensor area is too small, and during the process of sensing a hit, the robot's movement vibration and the vibration of the battle gun itself are mistakenly identified as hit events, causing the battle system to become disordered. Summary of the Invention

[0008] The purpose of this invention is to provide a legged robot combat system and its combat control method to solve the problems mentioned in the background art. This invention fires water bullets from one legged robot's combat gun at another legged robot. The bullets hit the moving shell and the main control device, and both the moving shell and the main control device are considered to have been hit. The system is not affected by the movement and vibration of the combat gun and the moving shell. The hit event is accurately identified. The main control device interacts with the interactive control terminal in real time, achieving the advantages of unified analysis and macro-management of the combat system.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a legged robot combat system, comprising legged robots of two opposing camps, each legged robot including a movable shell, a combat gun mounted on the movable shell, and a main control device separately mounted on the movable shell from the combat gun, the main control device including a processor, a target vibration module, a reference vibration module, and an execution module; during combat, one legged robot fires water bullets at the other legged robot with its combat gun, and the water bullets hit the movable shell and the main control device to elicit a response. The main control unit adaptively identifies the vibration frequency of the impact, performs bandpass filtering, suppresses extremely low-frequency attitude drift, and suppresses ultra-high-frequency noise. The processor is connected to an interactive control terminal, which sends control commands to any legged robot via the User Datagram Protocol (UDP) and receives real-time status data for display and determination of whether a hit event has occurred. As long as both the moving shell and the main control unit are hit, the impact is not affected by the vibration of the gun or the moving shell. The hit event is accurately identified, and the main control unit interacts with the interactive control terminal in real time to achieve unified analysis and macro-management of the combat system.

[0010] As a further embodiment of the present invention, the interactive control terminal is equipped with an ADC sampling and timing interrupt module, a WiFi module, and a low-power Bluetooth communication module. The WiFi module uses the User Datagram Protocol (UDP) to enable real-time command issuance and status feedback during gameplay. The low-power Bluetooth communication module is set up in parallel to handle commands and feedback for near-end network configuration or switching, and provides input for commands such as scanning, configuring, clearing and switching networks.

[0011] As a further embodiment of the present invention, the interactive control terminal also includes a touch-screen user interface, which includes firing control, scoring statistics, referee judgment, device status list, battlefield situation display, and network and Bluetooth connection interface.

[0012] As a further embodiment of the present invention, the target vibration module is disposed near the moving shell, outputs an analog signal and samples it to obtain the target signal, and the reference vibration module is disposed at the combat gun, outputs an analog signal and samples it to obtain the reference signal.

[0013] As a further embodiment of the present invention, the execution module includes a light bar display, a health display for executing health deduction logic, and a communication interface thereof.

[0014] As a further embodiment of the present invention, the processor is an embedded microcontroller with WiFi and BLE communication capabilities, used to undertake device-side communication and control logic.

[0015] As a further embodiment of the present invention, a combat control method for a legged robot combat system includes the following steps: Step 1: System Initialization: The system powers on and starts up, initializing the hardware (GPIO / serial port) for baseline calibration of the pressure sensor; Step 2: Power-off Preservation and Automatic Reconnection: The service set identifier (WiFi SSID), password, and configuration completion flag are written to Flash (NVS) through persistent storage (Preferences). The Flash (NVS) is read and WiFi configuration and marking are performed to ensure that the data is not lost when power is off and to determine whether the configuration is valid. Persistent storage is used to save SSID / password / configuration completion flag information when power is off. When the network configuration / scanning process and real-time UDP control are not state isolated, macro-control problems such as command delay, packet loss, and untimely status feedback are avoided.

[0016] Step 3: Effective configuration failure: Entering BLE configuration network as a fallback, entering non-main loop mode; strong on-site operation and maintenance capabilities, rapid network switching / recovery after reconnection, ensuring continuous operation, common temporary network switching needs in real-world environments (site change, AP restart, hotspot switching, etc.). With a nearby BLE configuration network as a fallback after reconnection, it effectively prevents equipment from "partially falling behind".

[0017] Step 4: Complete effective configuration: After the device is powered on, it first reads the saved parameters and then enters the main loop to perform automatic connection and limited retries; Step 5: The main loop enters the decoupling mechanism of BLE instruction "receive-buffer-main loop processing": The BLE callback instruction does not execute time-consuming logic such as WiFi scanning / connection within the callback; it only writes the instruction to the buffer and sets it to be processed. In the main loop function, the marker to be processed is detected, the unified instruction processing function is called to perform scanning / connection, and the result is returned via notify; Step Six: Distribution Network State Machine and Mutual Exclusion Control: Use distribution network stage variables to form a clear state machine. During distribution network interaction, pause the background automatic reconnection / heartbeat refresh behavior to reduce link interference; when idle, output heartbeat / status prompts at a fixed rhythm. Step 7: Real-time control of relay debounce and timeout release: The relay action adopts a debounce time window to avoid accidental triggering due to jitter. If no continuous firing command is received within a certain period of time, the relay is automatically released, reducing the risk of "trigger jamming / long press without release"; high reliability of networking and distribution, high system availability and deployment efficiency.

[0018] Network parameters cannot be reliably saved after power outages, cannot automatically recover to the last available network after a restart, and the automatic reconnection logic is unstable. In the event of a battery change, temporary power outage, or hotspot switching during a match, manual reconfiguration may be required; running multiple devices simultaneously significantly lengthens pre-match preparation time, impacting match organization and refereeing pace.

[0019] Step 8: Impact detection, baseline calibration and filtering sampling: After power-on, the pressure sensor is baseline calibrated. During operation, the target signal and reference signal are sampled through the target vibration module and reference vibration module. The sampling window value and threshold are used to determine whether the impact hit event is valid, thereby reducing the probability of false judgment. Upon being hit, the execution module updates the health bar and the LED strip display, and transmits the status back via the user datagram protocol. Step Nine: Standardized Status Return: The processor returns key fields in a standardized status return structure (JSON), and the interactive control terminal completes unified parsing and macro-level management. It possesses the stable status return and macro-level controllability required for multi-device battle referee systems.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: The present invention includes two legged robots from two opposing camps. Each legged robot includes a movable shell, on which a combat gun is mounted. The movable shell also has a main control device that is separately mounted from the combat gun. The main control device includes a processor, a target vibration module, a reference vibration module, and an execution module. During the battle, the combat gun of one legged robot fires water bullets at the other legged robot, which hit the movable shell and the main control device to trigger a response. The main control unit adaptively identifies the vibration frequency of the impact, performs bandpass filtering, suppresses extremely low-frequency attitude drift, and suppresses ultra-high-frequency noise. The processor is connected to an interactive control terminal, which sends control commands to any legged robot via the User Datagram Protocol (UDP) and receives real-time status data for display and determination of whether a hit event has occurred. As long as both the moving shell and the main control unit are hit, the impact is not affected by the vibration of the gun or the moving shell. The hit event is accurately identified, and the main control unit interacts with the interactive control terminal in real time to achieve unified analysis and macro-management of the combat system.

[0021] The combat control method of the legged robot combat system has the advantages of simple system architecture, control link end, avoiding delay and packet loss probability, rapid trigger response, accurate hit scoring, synchronized display status, and high reliability of networking and distribution, as well as high system availability and deployment efficiency.

[0022] The distribution network interaction and real-time control links do not interfere with each other, and the data is written and saved in real time. It is designed for stable status feedback and macro-controllability in multi-device battlefields, meets the requirements of the battle referee system, and has strong on-site operation and maintenance capabilities. Attached Figure Description

[0023] Figure 1 This is a three-dimensional schematic diagram of the combat gun and main control device of the present invention. Figure 2 A front view of the combat gun and main control device of the present invention. Figure 3 This is a schematic diagram illustrating the execution steps of the battle system of the present invention.

[0024] In the diagram: 1-Main control unit, 2-Battle gun, 101-Light bar display, 102-Health display. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1

[0026] See appendix Figure 1 -Appendix Figure 3A legged robot combat system includes legged robots from two opposing teams. Each legged robot comprises a mobile outer shell, which serves as the hardware body of the robot. The system includes a mechanical structure and its drive and execution system, along with a control system, power supply, and communication auxiliary modules. The system can be bipedal, quadrupedal, hexapedal, or octagonal. During combat, the legged robots move autonomously as independent locomotion systems.

[0027] The mobile housing is equipped with a combat gun 2, and the mobile housing is also equipped with a main control device 1 that is set separately from the combat gun. The main control device includes a processor, a target vibration module, a reference vibration module, and an execution module. The processor is an embedded microcontroller with WiFi and BLE communication capabilities. The microcontroller model is ESP32-C3, which is used to handle the device-side communication and control logic.

[0028] The target vibration module is located near the moving shell, outputs an analog signal and samples it to obtain the target signal, and the reference vibration module is located at the combat gun, outputs an analog signal and samples it to obtain the reference signal.

[0029] The execution module includes a light bar display 101, a health display 102 that executes the health deduction logic, and its communication interface.

[0030] During the battle, one legged robot's combat gun fired water bullets at the other legged robot, hitting the moving shell and the main control device, which triggered a response. The main control unit adaptively identifies the impact vibration frequency, performs bandpass filtering, suppresses extremely low frequency attitude drift, and suppresses ultra-high frequency noise. The target signal and reference signal are respectively protected against DC de-DC and amplitude limiting. Bandpass filtering can be optionally performed to suppress extremely low frequency attitude drift and ultra-high frequency noise. The selectable bandpass range is 20Hz to 800Hz, preferably 80Hz to 600Hz (based on the actual structural frequency response).

[0031] The processor is connected to an interactive control terminal, which is equipped with an ADC sampling and timer interrupt module, a WiFi module, and a low-power Bluetooth communication module. Among them, ADC sampling, or Analog-to-Digital Converter (ADC) sampling, is the process of converting continuously changing analog electrical signals (such as voltage and current) into discrete binary digital signals that can be recognized by digital devices through hardware circuits. It is the core interactive bridge between the analog world and the digital world.

[0032] The WiFi module uses the User Datagram Protocol (UDP) to send commands and transmit status during gameplay in real time; the WiFi STA mode of the WiFi module allows the site to access the designated wireless network.

[0033] The low-power Bluetooth communication module is set up in parallel to handle commands and feedback for near-end network configuration or switching, and provides input for commands such as scanning, configuring, clearing and switching networks.

[0034] The interactive control terminal also includes a touch-screen user interface, which includes firing control, scoring statistics, referee judgment, equipment status list, battlefield situation display, and network and Bluetooth connection interfaces.

[0035] The interactive control terminal sends control commands to any legged robot via the User Datagram Protocol (UDP) and receives real-time status data for display and determination of whether a hit event has occurred. UDP is a connectionless, low-latency transmission protocol that sends battle control commands and returns battle status in real time. Example 2

[0036] The battle control method for a legged robot battle system includes the following steps: Step 1: System Initialization: The system powers on and starts up, initializing the hardware (GPIO / serial port) for baseline calibration of the pressure sensor; Step 2: Power-off Preservation and Automatic Reconnection: The service set identifier (WiFi SSID), password, and configuration completion flag are written to Flash (NVS) through persistent storage (Preferences). The Flash (NVS) is read and WiFi configuration and marking are performed to ensure that the data is not lost when power is off and to determine whether the configuration is valid. Flash (NVS) is a core technology combination for non-volatile storage in embedded systems. Flash is a hardware storage medium, and NVS (Non-Volatile Storage) is a lightweight non-volatile storage architecture / software module based on Flash. Together, they enable persistent data storage after the device loses power and serve as the core carrier for embedded device storage preferences, configuration parameters, operation logs, and sensor data.

[0037] Step 3: Valid configuration fails: Enter BLE network configuration fallback mode, enter non-main loop mode; automatic connection, reducing manual intervention.

[0038] Step 4: Complete effective configuration: After the device is powered on, it first reads the saved parameters and then enters the main loop to perform automatic connection and limited retries; Step 5: The main loop enters the decoupling mechanism of BLE instruction "receive-buffer-main loop processing": The BLE callback instruction does not execute time-consuming logic such as WiFi scanning / connection within the callback; it only writes the instruction to the buffer and sets it to be processed. In the main loop function, the marker to be processed is detected, the unified instruction processing function is called to perform scanning / connection, and the result is returned via notify; Step Six: Distribution Network State Machine and Mutual Exclusion Control: Use distribution network stage variables to form a clear state machine. During distribution network interaction, pause the background automatic reconnection / heartbeat refresh behavior to reduce link interference; when idle, output heartbeat / status prompts at a fixed rhythm. Step 7: Real-time control of relay anti-shake and timeout release: The relay action adopts an anti-shake time window to avoid accidental triggering due to shaking. If no continuous firing command is received within a certain period of time, the relay is automatically released to reduce the risk of "trigger jamming / long press without release". Step 8: Impact detection, baseline calibration and filtering sampling: After power-on, the pressure sensor is baseline calibrated. During operation, the target signal and reference signal are sampled through the target vibration module and reference vibration module. The sampling window value and threshold are used to determine whether the impact hit event is valid, thereby reducing the probability of false judgment. Upon being hit, the execution module updates the health bar and the LED strip display, and transmits the status back via the user datagram protocol; it accurately determines whether the hit event has occurred, and through settings, the LED strip display updates accordingly for each hit when the health bar drops by one or two units.

[0039] Step Nine: Standardized Status Return: The processor returns key fields in a standardized status return structure (JSON), and the interactive control terminal completes unified parsing and macro-management.

[0040] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the scope of the invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0041] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A legged robot combat system, characterized in that: The system includes legged robots from both sides. Each legged robot includes a mobile shell with a combat gun (2) on it. The mobile shell also has a main control device (1) that is separate from the combat gun. The main control device includes a processor, a target vibration module, a reference vibration module, and an execution module. During the battle, the combat gun of one side's legged robot fires water bullets at the other side's legged robot. The water bullets hit the mobile shell and the main control device and receive a response. The main control device (1) adaptively identifies the vibration frequency of the impact, performs bandpass filtering, suppresses extremely low frequency attitude drift and suppresses ultra-high frequency noise. The processor is connected to an interactive control terminal. The interactive control terminal sends control commands to any legged robot through the user data packet protocol and receives real-time status data for display and to determine whether the impact event is established.

2. The legged robot combat system according to claim 1, characterized in that: The interactive control terminal is equipped with an ADC sampling and timing interrupt module, a WiFi module, and a low-power Bluetooth communication module. The WiFi module uses the User Datagram Protocol (UDP) to enable real-time command issuance and status feedback during gameplay. The low-power Bluetooth communication module is set up in parallel to handle commands and feedback for near-end network configuration or switching, and provides input for commands such as scanning, configuring, clearing and switching networks.

3. The legged robot combat system according to claim 2, characterized in that: The interactive control terminal also includes a touch-screen user interface, which includes firing control, scoring statistics, referee judgment, equipment status list, battlefield situation display, and network and Bluetooth connection interfaces.

4. The legged robot combat system according to claim 2, characterized in that: The target vibration module is located near the moving shell, outputs an analog signal and samples it to obtain the target signal, and the reference vibration module is located at the combat gun, outputs an analog signal and samples it to obtain the reference signal.

5. The legged robot combat system according to claim 4, characterized in that: The execution module includes a light bar display (101), a health display (102) that executes the health deduction logic, and their communication interface.

6. The legged robot combat system according to claim 5, characterized in that: The processor is an embedded microcontroller with WiFi and BLE communication capabilities, used to handle device-side communication and control logic.

7. A battle control method for a legged robot battle system as described in claim 6, characterized in that: Includes the following steps: Step 1: System Initialization: The system powers on and starts up, initializing the hardware (GPIO / serial port) for baseline calibration of the pressure sensor; Step 2: Power-off Preservation and Automatic Reconnection: The service set identifier (WiFiSSID), password, and configuration completion flag are written to Flash (NVS) through persistent storage (Preferences). The Flash (NVS) is read and WiFi configuration and marking are performed to ensure that the data is not lost when power is off and to determine whether the configuration is valid. Step 3: Valid configuration failed: Enter BLE network configuration fallback mode, enter non-main loop mode; Step 4: Complete effective configuration: After the device is powered on, it first reads the saved parameters and then enters the main loop to perform automatic connection and limited retries; Step 5: The main loop enters the BLE instruction's decoupling mechanism of "receive-buffer-main loop processing": The BLE callback instruction does not execute time-consuming logic such as WiFi scanning / connection within the callback; it only writes the instruction to the buffer and sets it to be processed. In the main loop function, the marker to be processed is detected, the unified instruction processing function is called to perform scanning / connection, and the result is returned via notify; Step Six: Distribution Network State Machine and Mutual Exclusion Control: Use distribution network stage variables to form a clear state machine. During distribution network interaction, pause the background automatic reconnection / heartbeat refresh behavior to reduce link interference; when idle, output heartbeat / status prompts at a fixed rhythm. Step 7: Real-time control of relay anti-shake and timeout release: The relay action adopts an anti-shake time window to avoid accidental triggering due to jitter. If no continuous firing command is received within a certain period of time, the relay is automatically released to reduce the risk of "trigger jamming / long press without release"; Step 8: Impact detection, baseline calibration and filtering sampling: After power-on, the pressure sensor is baseline calibrated. During operation, the target signal and reference signal are sampled through the target vibration module and reference vibration module. The sampling window value and threshold are used to determine whether the impact hit event is valid, thereby reducing the probability of false judgment. Upon being hit, the execution module updates the health bar and the LED strip display, and transmits the status back via the user datagram protocol. Step Nine: Standardized Status Return: The processor returns key fields in a standardized status return structure (JSON), and the interactive control terminal completes unified parsing and macro-management.