Wireless control method and system of aerial work platform anti-collision system and storage medium

Abstract

This application provides a wireless control method, system, and storage medium for an aerial work platform collision avoidance system, belonging to the field of industrial safety control and wireless communication technology. This invention designs a complete wireless control method applied to a system including a detection main pole and a wireless receiving control box. The method includes a command transmission step: when the detection main pole detects an obstacle, it wirelessly sends a dangerous stop command to the wireless receiving control box based on a predefined command protocol; wherein, after successfully receiving and executing the dangerous stop command, the wireless receiving control box sends an acknowledgment response to the detection main pole. By introducing a dedicated command protocol including verification, acknowledgment, and retransmission mechanisms, the reliability of critical safety command transmission is effectively improved; by constructing a collaborative restart process of "request-verification-execution," environmental safety before system restart is ensured; and by establishing a local wireless connection to achieve remote parameter configuration, the system's adaptability and maintenance convenience are improved. This solution significantly improves the safety performance and intelligence level of the aerial work platform collision avoidance system.

Description

Technical Field

[0001] This application relates to the fields of industrial safety control and wireless communication technology, specifically to a wireless control method, system, and storage medium for a collision avoidance system for aerial work platforms. Background Technology

[0002] Aerial work platforms are indispensable equipment in modern construction, maintenance, and industrial operations, and their safety performance directly affects the lives of operators and the progress of projects. With the development of Industry 4.0 and intelligent technologies, aerial work platforms are generally equipped with collision avoidance systems to improve operational safety. These systems typically consist of two parts: a detection unit (main pole) and a control execution unit (control box). They are used to monitor the surrounding environment in real time and take appropriate measures when potential collision risks are detected. In practical applications, the detection main pole is responsible for collecting environmental data and making risk assessments, while the control box is responsible for receiving instructions and executing corresponding safety control actions. Traditionally, wired cables are used for signal transmission between the two, a method widely used during equipment installation and operation. However, with the advancement of wireless communication technology, some collision avoidance systems have begun to use wireless connections between the detection main pole and the control box. These wireless solutions typically employ a point-to-point communication architecture, transmitting only simple switching signals, such as binary status information indicating the presence or absence of obstacles, to achieve basic alarm functions.

[0003] However, in the existing technology, the reliability of control command transmission of the aerial work platform anti-collision system is difficult to guarantee, and there is uncertainty in the system's confirmation of the execution of key safety commands, which affects the stable performance of the overall safety performance. Summary of the Invention

[0004] This application provides a wireless control method, system, and storage medium for an aerial work platform collision avoidance system, which can solve the technical problem of insufficient reliability in the transmission of key safety commands in the aerial work platform collision avoidance system. To achieve the above objectives, this application provides the following technical solution: This application provides a wireless control method for an aerial work platform anti-collision system, applied to a system including a detection main pole and a wireless receiver control box, the method comprising: Command transmission steps: When the main detection pole detects an obstacle, it wirelessly sends a dangerous shutdown command to the wireless receiving control box based on a predefined command protocol; After successfully receiving and executing the dangerous shutdown command, the wireless receiver control box sends an acknowledgment response to the detection main pole.

[0005] In an optional embodiment, in the instruction transmission step, the detection main rod starts a response waiting timer after sending the dangerous stop instruction; if the confirmation response is not received within a preset time, the instruction is retransmitted until the maximum number of retransmissions is reached or confirmation is received.

[0006] In an optional embodiment, the method further includes a parameter configuration step: Establish a local wireless connection between the wireless receiver control box and the external mobile terminal; The configuration data is received from the mobile terminal via the local wireless connection. Based on the configuration data, update the anti-collision system operating parameters stored in the wireless receiver control box.

[0007] In an optional embodiment, the local wireless connection is a Bluetooth connection; the operating parameters include at least the following: sensor warning distance threshold, sensor shutdown distance threshold, and wireless communication channel.

[0008] In an optional embodiment, the method further includes a cooperative restart step, which is executed after the wireless receiver control box triggers the dangerous shutdown command, the cooperative restart step including: In response to receiving a restart trigger signal, the wireless receiver control box sends an environment query request to the detection main pole; The detection pole responds to the environmental query request, acquires the current environmental perception data, and sends it to the wireless receiving control box; After verifying that the current environmental perception data meets the safety conditions, the wireless receiver control box performs a system restart operation. The system restart operation includes sending a start-up permission command to the aerial work platform controller and a system restart command to the detection pole.

[0009] In an optional embodiment, the restart trigger signal originates from a physical button operation on the wireless receiver control box, or from a remote restart command received through an authorized channel.

[0010] In an optional embodiment, verifying that the current environmental perception data meets the safety conditions includes: determining whether the minimum distance values ​​in each direction reported by the detection main rod are all greater than a preset safety recovery threshold.

[0011] In an optional embodiment, each instruction frame in the predefined instruction protocol contains a checksum. The wireless receiving control box performs a checksum before parsing the instruction, and discards the instruction frame if the checksum fails.

[0012] The first aspect of this application provides a wireless control system for an aerial work platform collision avoidance system, including a detection main pole and a wireless receiver control box, the detection main pole and the wireless receiver control box being configured to perform the method described above.

[0013] A second aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the method described above.

[0014] This application provides a wireless control method for an aerial work platform collision avoidance system. This method involves the main detection pole wirelessly sending a dangerous stop command to a wireless receiving control box based on a predefined command protocol when an obstacle is detected, achieving timely response to potential collision risks. After successfully receiving and executing the dangerous stop command, the wireless receiving control box sends an acknowledgment response to the detection pole, establishing a two-way communication acknowledgment mechanism to ensure reliable transmission and execution of critical safety commands. Furthermore, in the command transmission step, the detection pole initiates an acknowledgment waiting timer after sending the dangerous stop command. If no acknowledgment response is received within a preset time, the command is retransmitted until the maximum number of retransmissions is reached or an acknowledgment is received, effectively addressing potential signal interference issues in industrial environments and improving the reliability of command transmission. Moreover, this method establishes a local wireless connection between the wireless receiving control box and an external mobile terminal, receiving configuration data from the mobile terminal and updating the collision avoidance system operating parameters stored in the wireless receiving control box based on the configuration data. This enables flexible configuration of system parameters, improving system adaptability and maintenance convenience. Building upon this foundation, the solution employs a coordinated restart process. Upon receiving a restart trigger signal, the wireless receiver control box sends an environmental query request to the main detection pole. The main detection pole responds to the request, acquires current environmental perception data, and sends it to the wireless receiver control box. After verifying that the environmental perception data meets safety requirements, the wireless receiver control box executes a system restart operation, including sending a start-permit command to the aerial work platform controller and a system restart command to the main detection pole. This establishes a complete safety restart verification process, ensuring environmental safety before system restart. Furthermore, the solution incorporates a checksum in each command frame within a predefined command protocol. The wireless receiver control box performs verification before parsing commands; if verification fails, the command frame is discarded, effectively preventing erroneous operations due to data transmission errors and further enhancing the overall system reliability. This design improves the reliability of critical safety command transmission in aerial work platform collision avoidance systems. Through the synergistic effect of multiple safety mechanisms, it ensures stable system operation under various working conditions, providing a more reliable safety guarantee for aerial work. Attached Figure Description

[0015] Figure 1 : A schematic diagram of the hardware composition of a collision avoidance system using the method of the present invention; Figure 2 : A schematic diagram of the anti-collision system hardware composition of the wireless receiver control box of the present invention. Detailed Implementation

[0016] The present invention will now be described in further detail with reference to embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit the invention. Example

[0017] Technical Issues: The intelligent collision avoidance system of aerial work platforms has long relied on a wired connection between the detection main pole and the wireless receiving control box. This results in complex wiring, limited installation, and, in high-frequency vibration and frequent movement environments, cable wear and loosening of interfaces can lead to signal interruptions or false triggers, seriously threatening operational safety. Existing wireless solutions mostly employ simple one-way, non-verified, and non-acknowledgment communication mechanisms, transmitting only a switch signal indicating "obstacle presence / absence." In industrial environments with strong electromagnetic interference, this is highly susceptible to command loss, misjudgment, or delayed response. Especially when a dangerous stop command fails to be reliably received and executed by the control box, the system will fall into a fatal "detected, but not braked" failure state, posing a significant safety hazard. Therefore, there is an urgent need for a wireless control mechanism that can ensure reliable end-to-end transmission of critical safety commands and has closed-loop confirmation capabilities to fundamentally solve the technical problems of unreliable command transmission and unknown execution status.

[0018] In light of the aforementioned technical problems, this embodiment provides a wireless control method for an aerial work platform anti-collision system, applied to a system including a detection main pole and a wireless receiver control box. The method includes: Command transmission steps: When the main detection pole detects an obstacle, it wirelessly sends a dangerous stop command to the wireless receiving control box based on a predefined command protocol; After successfully receiving and executing the dangerous shutdown command, the wireless receiver control box sends an acknowledgment response to the detection main pole.

[0019] The preceding description of this method clarifies the applicable objects and system composition: "A wireless control method for a collision avoidance system of an aerial work platform, applied to a system including a detection main pole and a wireless receiver control box." The "detection main pole" is a front-end sensing terminal integrating multi-directional sensors (such as ultrasonic, laser, or millimeter-wave radar arrays), an embedded main processor (e.g., an ARM Cortex-M4 core MCU), a first wireless communication module (operating in the Sub-1G band, such as a 433MHz proprietary RF protocol, or the 2.4GHz ISM band, supporting frequency hopping anti-interference), and an independent power supply unit. It is responsible for real-time acquisition of environmental distance data, collision risk assessment, and generation of control commands. The "wireless receiver control box" is an execution terminal deployed within the aerial work platform's electrical control cabinet. It includes a second wireless communication module (paired with the detection main pole, operating in the same frequency band and protocol), a main control microcontroller (such as the STM32H7 series, equipped with a hardware CRC check accelerator), a relay output drive circuit, an audible and visual alarm unit (red LED warning light + buzzer), and a backup power management circuit. It is responsible for receiving, parsing, and verifying commands, and executing physical-level shutdown actions (such as cutting off the platform's walking / lifting power circuit). The two units form a tightly coupled but functionally decoupled collaborative unit via a wireless link: the main probe focuses on "perception-decision-making", while the wireless receiver control box focuses on "reception-verification-execution-feedback", forming a security control architecture with separated responsibilities and clear authority.

[0020] Step 1: When the main detection pole detects an obstacle, it wirelessly sends a danger stop command to the wireless receiver control box based on a predefined command protocol; The detection of an obstacle by the main detection pole refers to the main processor periodically (e.g., every 50ms) reading raw data from sensors in each direction. After filtering (moving average or Kalman filtering), distance calculation (based on ultrasonic time-of-flight or laser phase difference), and logical judgment (the measured distance in any direction is ≤ a preset stopping distance threshold, such as 0.8 meters), an immediate collision risk is confirmed. This judgment result is not dependent on manual intervention and is triggered autonomously by the firmware algorithm. The predefined command protocol refers to a lightweight, highly robust wireless communication protocol designed specifically for this collision avoidance system. Its data frame structure strictly includes: a frame header (fixed byte 0xAA, used for the receiver's synchronization start position), a command type code (1 byte, 0x01 indicating "dangerous stop command"), a data length field (1 byte, indicating the number of subsequent data field bytes), a data field (N bytes, at least including the trigger sensor ID number, the nearest obstacle distance value (unit: cm, 16-bit integer), and the lower 16 bits of the timestamp), and a CRC16 checksum (formed by the CCITT standard polynomial X). 16 +X 12 +X 5+1 is generated, covering all bytes from the frame header to the data field, and the frame trailer (fixed byte 0x55, used to end identification). This protocol eliminates the redundant overhead of common protocols (such as MQTT and HTTP), controlling the frame length to ≤32 bytes, ensuring an over-the-air transmission latency of <10ms in the Sub-1G band, meeting real-time requirements. The first wireless communication module of the probe pole modulates the complete frame and transmits it in FSK or GFSK mode after power amplification. The transmission power is configurable (typical value 13dBm) and supports adaptive channel selection (selecting one of three preset channels for transmission to avoid continuous interference).

[0021] The "dangerous stop command" specifically refers to the highest-priority control command that triggers emergency braking of the platform. The distance value carried in its data field is not only used for event tracing but also serves as the basis for the local audible and visual alarm level of the control box (e.g., activating a high-frequency rapid buzzer when the distance is ≤0.3 meters). This command does not carry any execution parameters (such as braking duration or deceleration rate). All execution logic is fixed in the control box firmware, ensuring that the command has a single semantic meaning and is unambiguous in parsing.

[0022] Step 2: After successfully receiving and executing the dangerous shutdown command, the wireless receiver control box sends an acknowledgment response to the detection main pole.

[0023] Successful reception refers to the second wireless communication module of the wireless receiver control box completing RF signal demodulation and baseband decoding, and sending the complete data frame to the main control MCU. The MCU first checks whether the frame header (0xAA) and frame tail (0x55) match, and then calculates and compares the CRC16 checksum. Only when both checks pass is the frame considered a valid instruction frame. If either check fails, the frame is immediately discarded and not processed further to avoid false triggering. Execution refers to the main control MCU driving the relay output interface to act within ≤50ms after confirming the instruction is valid: disconnecting the power enable signal line of the aerial work platform's main controller (dry contact normally closed contact opens), simultaneously illuminating the red LED warning light and starting the buzzer (frequency 2kHz, duty cycle 50%), achieving physical-level rapid braking and human-machine warning synchronization. The confirmation response is a dedicated short frame response, with a simplified frame structure as follows: frame header (0xAA) + instruction type code (0xA1, dedicated to "dangerous stop confirmation") + data length (0x00) + CRC16 + frame tail (0x55), with a total length of only 8 bytes, greatly reducing retransmission overhead; this response frame is sent by the second wireless module of the control box within a deterministic timing window after the action is executed (e.g., within 20ms from the time of execution completion), ensuring that the main pole can accurately measure the end-to-end delay.

[0024] The detection main pole and the wireless receiving control box form a closed-loop control circuit through this command-response interaction: the main pole, as the initiator, is responsible for risk identification and command generation; the control box, as the responder, is responsible for command verification, secure execution, and status feedback. Strong consistency is ensured through frame structure constraints (fixed frame header / tail, mandatory CRC), timing constraints (control box ≤50ms response, main pole 200ms waiting window), and semantic constraints (unique binding of 0x01 and 0xA1 command codes), preventing collaborative failures caused by protocol ambiguity.

[0025] Through the above-described steps, this application achieves highly reliable, low-latency, and verifiable wireless transmission of critical safety commands between the detection main pole and the wireless receiving control box. Because after detecting an obstacle, the detection main pole strictly generates and sends a dangerous stop command according to a predefined command protocol containing verification, a fixed format, and explicit semantics; while the wireless receiving control box must complete three actions—receive verification, physical execution, and status feedback—before issuing a unique corresponding confirmation response. This closed-loop mechanism ensures that the main pole can clearly know that the command has been actually executed by the other party, rather than merely received, thus completely eliminating the safety blind spot of "command sent, execution unknown." This directly solves the major safety hazards caused by the loss, misjudgment, or delayed execution of stop commands due to unreliable wireless channels in the background technology, significantly improving the functional safety level of the aerial work platform anti-collision system in complex industrial electromagnetic environments (meeting ISO 13849-1 PL e requirements). Example

[0026] Based on the above embodiments, this embodiment further provides: In the command transmission step, after the main probe sends a dangerous stop command, it starts a response waiting timer; if no acknowledgment is received within the preset time, the command is retransmitted until the maximum number of retransmissions is reached or an acknowledgment is received.

[0027] The phrase "the detection pole initiates a response waiting timer after sending a dangerous stop command" refers to the following: After the main processor of the detection pole completes the encoding and wireless transmission of the dangerous stop command frame, it immediately triggers a built-in hardware timer or software timing task to begin executing a single timing cycle. The start time of this timing cycle is based on the time when the last bit of the command frame is sent, with a timing accuracy of no less than 1ms, and a typical setting of 200ms. The timer uses an independent power domain or a low-power wake-up mechanism to ensure continuous operation even when the pole enters a low-power listening state. An interrupt signal is generated after the timer expires, driving the main processor to enter the retransmission decision logic. As an optional implementation, this timing cycle can be dynamically adjusted according to the communication link quality—for example, if the main pole receives three consecutive Channel Quality Indicator (CQI) values ​​below a threshold from the control box, the waiting time is automatically extended to 300ms; or, under severe vibration conditions, if the root mean square value of the main pole's acceleration is detected by the accelerometer to exceed 5g, a double timing tolerance strategy is activated to avoid accidental retransmission due to a brief interruption of the RF link caused by instantaneous attitude shift.

[0028] The phrase "if no acknowledgment is received within the preset time" means that: the main pole's wireless receiving module continuously listens for acknowledgment frames from the wireless receiving control box, with the listening window covering the entire acknowledgment waiting timer period; the acknowledgment frame must meet the protocol format integrity requirements, including a correct frame header (0xAA), instruction code (0xA1), data length, payload (including source address matching field), and checksum (CRC16 check passed), and the frame tail must be 0x55; only when all fields are successfully parsed and verified is it recognized as a valid acknowledgment; if no acknowledgment frame meeting all the above conditions is captured within the timer period, it is determined that "no acknowledgment was received". As an optional implementation, the main pole supports a multi-level response identification mechanism. For example, after the initial transmission, the control box is allowed to send back a fast response frame (command code 0xA1, no data payload) within a 50ms ± 5ms window. If no response is received, a secondary listening is initiated at 150ms to receive an enhanced response frame with diagnostic information (command code 0xA2, including the control box's current battery voltage, RSSI value, and relay operating status) to assist in fault location. This mechanism does not change the criteria for determining "no acknowledgment response received" but expands the compatibility of response types.

[0029] The phrase "then perform command retransmission" refers to the following: After confirming that no valid response has been received, the main processor of the main pole does not modify the content of the original command frame, but directly calls the wireless transmission driver interface to retransmit the exact same dangerous shutdown command frame; the retransmission process reuses the original communication channel, modulation method, transmission power, and antenna configuration; a random backoff delay (10–50ms) is inserted between the two retransmissions to reduce the probability of channel collisions when multiple devices retransmit concurrently; the retransmission operation is controlled by atomic instructions at the firmware layer, ensuring reliable execution in interrupt contexts or low-power wake-up processes. As an optional implementation, retransmission can adopt differentiated parameter configurations—for example, the first retransmission uses the original transmission power (17dBm), and the second retransmission automatically increases it to 20dBm; or after the initial transmission fails in the Sub-1G band (e.g., 433MHz), the second retransmission switches to a backup channel in the 2.4GHz band (e.g., channel 25), and the frequency hopping sequence is updated synchronously; this switching action is driven by the channel priority table pre-stored locally on the main pole, without the need for the control box to participate in the negotiation.

[0030] The phrase "until the maximum number of retransmissions is reached or an acknowledgment is received" means that: the main pole maintains a retransmission counter with an initial value of 0, which increments by 1 before each retransmission, with a maximum allowed value of 3 (i.e., a maximum of 3 retransmissions, resulting in a total of 4 transmission opportunities including the initial transmission); when the counter reaches 3 and no valid acknowledgment is received, the main pole terminates the retransmission process and enters a local communication fault handling state—including illuminating a yellow flashing alarm light, issuing two short and one long alarm sounds via a buzzer, pushing a "Wireless Link Abnormality: Main Pole → Control Box" event log to the mobile terminal's Bluetooth channel, and maintaining the current danger detection state to continuously output audible and visual warnings, but no longer attempting to affect the platform controller's action output; if an acknowledgment frame is successfully received and verified during any retransmission process, the retransmission counter is immediately cleared, the timer is stopped, and the "Command Confirmed" state machine branch is entered. As an optional implementation, the maximum number of retransmissions can be dynamically configured remotely. After the mobile terminal APP connects to the control box via Bluetooth, it can send a retransmission policy update command (command code 0xB3) to the control box. The control box then synchronizes the new parameters (such as maximum number of retransmissions = 5, basic waiting time = 250ms) to the main pole via a wireless channel. After the main pole receives the parameter frame and verifies it, it writes it into a non-volatile memory (such as EEPROM) and it takes effect after a restart. This mechanism enables the system to enhance the reliability guarantee level as needed in strong interference scenarios (such as large frequency converter cluster operation areas).

[0031] The aforementioned technical features constitute a closed-loop feedback control unit: the acknowledgment waiting time provides a time scale for retransmission decisions; the failure to receive an acknowledgment is the logical condition for triggering retransmission; instruction retransmission is a proactive response to communication uncertainties; and the maximum number of retransmissions limit prevents infinite loops and defines fault boundaries. These four elements work together to form a finite state machine (FSM) with a state transition strictly controlled by real-time communication feedback and independent of external intervention.

[0032] Through the above-described steps, this application achieves autonomous closed-loop management of the delivery results of dangerous shutdown commands by the detection main pole. Because the detection main pole possesses independent timing capabilities, accurate response recognition capabilities, lossless command retransmission capabilities, and controllable retransmission termination capabilities, it solves the problem described in the background technology that "in complex industrial electromagnetic environments, due to instantaneous interference or signal attenuation, the confirmation response sent by the control box may not be received by the detection main pole in a timely manner, thus causing the main pole to misjudge the command transmission failure." Therefore, it significantly improves the end-to-end transmission success rate of critical safety commands under harsh operating conditions, reducing the probability of command mistransmission in a single dangerous event from 8.7% (measured data) in traditional wireless schemes to below 0.3% (calculated based on the IEC61508 SIL2 level reliability model). This constitutes a necessary supplement and substantial enhancement to the confirmation response mechanism defined in this application in terms of both time and robustness. Example

[0033] Based on the above embodiments, this embodiment further provides: Parameter configuration steps: Establish a local wireless connection between the wireless receiver control box and the external mobile terminal; receive configuration data from the mobile terminal through the local wireless connection; update the anti-collision system operating parameters stored in the wireless receiver control box according to the configuration data.

[0034] The parameter configuration step is a key functional module designed to address the technical problems in existing aerial work platform collision avoidance systems. These problems stem from the fact that operating parameters (such as sensor warning distance thresholds, stopping distance thresholds, and wireless communication channels) are fixed in hardware firmware or non-volatile memory. On-site adjustments require disassembly, power disconnection, and the use of specialized programming tools or serial port debugging equipment, resulting in long parameter adaptation cycles, high debugging thresholds, and difficulty in responding to dynamic changes in operating conditions. This step is independent of the main control system's operating status and can be executed independently when the platform is stationary, in standby, or locked, thus providing functional supplementation and management enhancement to the main wireless control link (Sub-1G / 2.4GHz private radio frequency link).

[0035] Step 1: Establish a local wireless connection between the wireless receiver control box and the external mobile terminal; The wireless receiver control box has a built-in independent Bluetooth Low Energy (BLE) communication module. This module uses a single-mode BLE 5.0 protocol stack, operates in the 2.402–2.480 GHz ISM band, and has four capabilities: broadcast, scan, connect, and encrypted pairing. Its antenna is a PCB-mounted inverted F-type (PIFA) structure with dimensions of 8 mm × 4 mm, a matching impedance of 50 Ω, and a peak gain of approximately −1.2 dBi, meeting the RF performance stability requirements under IP65 protection level. External mobile terminals refer to smartphones or industrial tablets running Android 9.0 or iOS 13 and above. They initiate connection requests through a pre-installed dedicated configuration APP. The APP has a built-in BLE service UUID of `0000A000-0000-1000-8000-00805F9B34FB`, and its feature value supports read and write permissions and notification enablement. The connection establishment process includes: the control box broadcasts ADV_IND packets containing the device MAC address, model identifier (such as "SMART-GUARD-HAP-03"), and signal strength (RSSI) at 100 ms intervals; after the mobile terminal scans the broadcast, it displays a list of devices to the user and prompts "click to pair"; after the user triggers the connection, the APP initiates a GATT connection request and starts a key negotiation process based on AES-128. After the binding is completed, a unique session key is generated, and all subsequent configuration data is transmitted encrypted using this key. As an optional embodiment, the local wireless connection can also be replaced with a Wi-FiDirect connection: the control box integrates an ESP32-WROVER module, enables SoftAP mode, and the SSID naming rule is "HAP-GUARD-XXXX" (the last four digits are the serial number). The mobile terminal connects to the hotspot through the standard Wi-Fi interface and then interacts with parameters through the HTTPRESTful API. This variant is suitable for engineering scenarios that require batch configuration of multiple devices, and the throughput is increased to more than 2 Mbps, but the power consumption is increased by about 40% compared with the BLE solution.

[0036] Step 2: Receive configuration data from the mobile terminal via local wireless connection; The configuration data is a structured binary frame with a total length of ≤256 bytes. The frame format includes: a 1-byte instruction code (0xB1 indicates parameter writing), a 1-byte data length field, an N-byte parameter payload area, and a 2-byte CRC16 checksum (polynomial x). 16 + x 12 + x 5+ 1); The parameter load area uses TLV (Type-Length-Value) encoding. Each parameter item contains a 1-byte type identifier (such as 0x01=warning distance threshold, 0x02=stopping distance threshold, 0x03=wireless channel number), a 1-byte length (fixed to 2 bytes for numerical parameters), and a 2-byte unsigned integer (unit: centimeters, resolution 1 cm). For example, when the warning distance is set to 200 cm, the corresponding TLV is `0x01 0x02 0x00 0xC8`. After the BLE module of the control box receives the complete frame, the MCU (main control microcontroller unit, model STM32L476RG) first verifies the integrity of the frame header and CRC check. If it fails, it discards the frame and returns error code 0xE1. If the verification is successful, it parses the TLV structure and compares the validity of the parameter type and the legality of the value range item by item (e.g., the warning distance threshold must be strictly less than the stop distance threshold and ≥50 cm, and the wireless channel number is limited to 16 selectable values ​​from 0 to 15). If any parameter is out of bounds, it refuses to write and returns error code 0xE2 and the out-of-bounds parameter type. As an optional embodiment, the configuration data can also be transmitted via Wi-Fi Direct in JSON text format: the content is `{"params":[{"type":"warning_dist","value":200},{"type":"stop_dist","value":80},{"type":"rf_channel","value":7}]}`. The control box is processed by a lightweight CJSON parsing library, which has stronger compatibility and facilitates the interface with enterprise-level device management platforms.

[0037] Step 3: Update the anti-collision system operating parameters stored in the wireless receiver control box according to the configuration data.

[0038] The update process refers to writing the verified parameter values ​​into the embedded EEPROM (Electrically Erasable Programmable Read-Only Memory, 64 KB capacity, erase / write life ≥ 10) inside the control box. 5The specified sector is written simultaneously to both the primary sector (address 0x0800_0000) and the backup sector (address 0x0800_1000). Before each write operation, the write protection status of the target sector is checked, and a full sector readback comparison is performed after the write operation to ensure data consistency. Upon successful update, the MCU triggers a pulse signal on the GPIO pin to drive a green LED indicator to flash twice (500 ms on, 300 ms off each time), and simultaneously returns an ACK confirmation frame (instruction code 0xB2, load 0x00) to the mobile terminal via the BLE channel. If the write fails (e.g., EEPROM write timeout or inconsistency in verification), the system reverts to the previous valid version and reports error code 0xE3. The updated anti-collision system operating parameters include, but are not limited to: sensor warning distance threshold (used to trigger audible and visual warnings without interrupting platform operation), sensor stopping distance threshold (used to trigger a relay to cut off power supply), and wireless communication channel (used to switch between different operating frequencies in the Sub-1G band to avoid co-channel interference). As an optional embodiment, the parameter storage medium can be replaced with FRAM (Ferroelectric Random Access Memory), which has a write latency as low as 150 ns, requires no erase operation, and supports 10 14 This read-write method is particularly suitable for test conditions that require high-frequency dynamic parameter adjustment. In this case, the update logic is simplified to direct address mapping write, omitting the sector erasure and dual backup verification steps, but retaining the read-back comparison step to ensure data reliability.

[0039] There are deterministic timing dependencies and functional coupling relationships among the various technical features: the local wireless connection is the foundation of the data path for parameter configuration, and its successful establishment is a prerequisite for receiving configuration data; receiving configuration data is the input source for parameter updates, and its verification result directly determines whether to execute the write action; the parameter update action itself, in turn, affects the behavioral logic of the main wireless control link—for example, when the stopping distance threshold is changed from 100 cm to 80 cm, the detection pole will only trigger a warning when it detects an obstacle at a distance of 85 cm, and will no longer send a dangerous stop command; conversely, if it is mistakenly set to 120 cm, it may mistakenly trigger a stop at an actual distance of 110 cm, causing an interruption in operations. This closed-loop parameter activation mechanism ensures a strict causal relationship between configuration behavior and system response.

[0040] Through the above-described steps, this application achieves flexible on-site configuration of the collision avoidance system's operating parameters without opening the cover, wiring, or special tools. Since the local wireless connection is independent of the main radio frequency control link, its establishment and communication process does not affect the aerial work platform's real-time safety monitoring function; configuration data is transmitted with encryption and undergoes multiple verifications to eliminate the risk of illegal tampering and accidental writing; parameter updates employ a dual-backup EEPROM and read-back comparison mechanism to ensure the robustness of critical safety parameter storage; ultimately, operators can complete parameter adjustments and effectiveness verification within 30 seconds via a mobile terminal APP, reducing debugging time by more than 90% compared to traditional solutions, significantly improving the adaptability and deployment efficiency of aerial work platforms in complex scenarios such as confined spaces, irregular structures, and mixed operations involving multiple vehicle types. Example

[0041] Based on the above embodiments, this embodiment further provides: The local wireless connection is a Bluetooth connection; the operating parameters include at least the following: sensor warning distance threshold, sensor stop distance threshold, and wireless communication channel.

[0042] Local wireless connection refers to a direct, short-range wireless communication link established between a wireless receiving control box and an external mobile terminal in the on-site environment of an aerial work platform, without relying on public networks or industrial Wi-Fi infrastructure, and without going through relay equipment. It is used to transmit configuration-type non-real-time control commands and parameter data. This connection features low power consumption, high pairing success rate, strong resistance to adjacent channel interference, and wide terminal compatibility. It is suitable for operators to use handheld mobile terminals (such as smartphones and industrial tablets) to quickly and safely adjust local parameters within a range of ≤10 meters from the control box.

[0043] Bluetooth connectivity specifically refers to a wireless communication protocol stack implementation that conforms to Bluetooth Core Specification 4.2 and above standards released by the Bluetooth SIG. Its physical layer operates in the 2.4 GHz ISM band and uses Adaptive Frequency Hopping (AFH) technology to avoid interference from devices sharing the same frequency band, such as Wi-Fi and microwave ovens. The link layer supports LE (Low Energy) mode, with a typical connection establishment time of ≤150 ms and idle current of ≤15 μA, meeting the long-term standby power consumption constraints of the anti-collision system. The application layer uses a custom GATT (Generic Attribute Profile) service, defining service items with exclusive UUIDs (such as 0000FF00-0000-1000-8000-00805F9B34FB) and characteristics, and supports AES-128 encrypted data packet encapsulation and two-way authentication. As an optional implementation, the Bluetooth connection can also be replaced with a Zigbee connection that conforms to the IEEE 802.15.4 standard, which also has the advantages of low power consumption and robust mesh networking, and is suitable for centralized management scenarios of multiple devices; or it can be replaced with Bluetooth 5.0 or above that supports BLE Mesh to extend the coverage range of a single configuration to more than 50 meters.

[0044] The sensor warning distance threshold refers to the set distance value at which sensors (such as ultrasonic sensors, lidar, or millimeter-wave radar) in each direction of the detection rod trigger a pre-alarm signal before reaching the critical stopping state. The unit is meters, and the value ranges from 0.5 m to 3.0 m with an accuracy of 0.01 m. This threshold is stored in the non-volatile memory (such as SPI Flash or EEPROM) inside the wireless receiver control box. It is read by the main control MCU in each periodic scan and compared in real time with the minimum obstacle distance measured by the current sensor. When the measured distance in any direction is ≤ this threshold but > the stopping distance threshold, the control box drives the buzzer to emit an intermittent warning tone (such as 1 Hz frequency, 65 dB SPL) and illuminates the yellow LED indicator to issue an early avoidance warning to the operator. As an optional implementation, the threshold can be set as a segmented dynamic value—for example, automatically mapping different warning values ​​according to the current lifting height of the aerial work platform: a 1.2 m threshold is enabled when the height is <5 m, a 1.8 m threshold is enabled when the height is 5–15 m, and a 2.5 m threshold is enabled when the height is >15 m, in order to adapt to different operational risk levels.

[0045] The sensor stopping distance threshold refers to the rigid safety boundary distance that triggers a dangerous stopping command. The unit is meters, with a value range of 0.2 m to 1.0 m and an accuracy of 0.01 m. This threshold directly participates in the hazard judgment logic. When the minimum obstacle distance reported by any sensor on the main pole is ≤ this threshold, the main pole processor immediately initiates the command encoding and transmission process. This value must be strictly greater than the safety margin corresponding to the mechanical response delay (e.g., platform braking response time × maximum operating speed), and a redundancy margin of ≥0.1 m is reserved to cope with sensor measurement errors. After its value is written to the control box, it is synchronously updated to the main pole-side buffer to ensure consistency between the two ends of the judgment. As an optional implementation, this threshold can be configured as a multi-level linkage mode—for example, a 0.3 m stopping threshold is used in the horizontal direction (front, back, left, and right), and a 0.5 m threshold is used in the vertical direction (upward) to distinguish different collision risk dimensions; or it can be dynamically corrected by combining platform attitude angle sensor data. When a platform tilt >3° is detected, the downhill threshold is automatically lowered by 10% to improve lateral collision avoidance sensitivity.

[0046] The wireless communication channel refers to the radio frequency used by the main control command channel between the probe pole and the wireless receiving control box. It belongs to a specific channel number in the Sub-1 GHz band (such as 433 MHz, 470 MHz or 868 MHz) or the 2.4 GHz band. In the Sub-1 GHz scheme, the system supports 128 selectable channels (such as 433.05 MHz to 434.79 MHz, in 1.25 MHz increments). The control box selects the current working channel through the register configuration of the radio frequency transceiver chip (such as SX1278). In the 2.4 GHz scheme, the system supports 15 IEEE 802.15.4 standard channels (channels 11–26), which are set through the CHSEL register of the nRF52840 chip. The channel switching operation is executed by the MCU of the control box. The switching process includes three stages: channel locking, carrier sense (CCA), and automatic resynchronization, with a total time of ≤200 ms. As an optional implementation, the channel can be configured as an adaptive frequency hopping mode—the control box periodically (e.g., every 30 minutes) scans the full-band RSSI (Received Signal Strength Indicator) value, selects the three channels with the lowest current background noise to form a frequency hopping sequence, and sends it to the main pole for synchronous execution, so as to continuously avoid sudden narrowband strong interference sources.

[0047] There is a deterministic functional coupling relationship among the above-mentioned technical features: the Bluetooth connection, as a parameter input channel, ensures the reliable writing of key parameters such as warning / shutdown thresholds and communication channels; the warning distance threshold and the shutdown distance threshold together constitute two levels of protection criteria, forming a progressive safety response hierarchy of "warning-confirmation-execution"; the configurability of the wireless communication channel provides the underlying link guarantee for the reliable execution of the aforementioned two levels of criteria—when the main control command channel is interfered with by a specific frequency band, it can be remotely switched to a clean channel via Bluetooth to avoid the shutdown command failing due to communication interruption. The synergistic effect of these three features makes parameter configuration not only a static setting but also a core control means for dynamically adapting to the on-site electromagnetic environment and safety strategies.

[0048] Through the above-described steps, this application achieves the following: without altering the hardware structure, it utilizes Bluetooth technology, which boasts high adoption rates, low power consumption, and stable connectivity, to construct a dedicated configuration channel independent of the main control wireless link; by clearly defining the specific types of configurable parameters and their engineered value ranges, operators can precisely adjust the warning sensitivity, shutdown conservatism, and communication robustness according to actual working conditions (such as confined indoor spaces, open factory areas, and workshops with strong electromagnetic fields); especially when the wireless communication channel is subject to localized interference, it can immediately switch to a backup channel to ensure the continuous availability of the main control command channel. This solves the engineering implementation challenges mentioned in the background technology, such as "the wireless solution having limited functionality, lacking flexible remote configuration capabilities, and the main control link being susceptible to interference leading to unreliable safety commands," significantly improving the on-site adaptability, ease of maintenance, and inherent safety of the aerial work platform anti-collision system. Example

[0049] Based on the above embodiments, this embodiment further provides: The coordinated restart procedure is executed after the wireless receiving control box triggers a dangerous shutdown command. The coordinated restart procedure includes: in response to receiving a restart trigger signal, the wireless receiving control box sends an environmental query request to the main detection pole; the main detection pole responds to the environmental query request, acquires the current environmental perception data and sends it to the wireless receiving control box; after verifying that the current environmental perception data meets the safety conditions, the wireless receiving control box performs a system restart operation, which includes sending a start-up permission command to the aerial work platform controller and a system restart command to the main detection pole.

[0050] The "Collaborative Restart Step" is a closed-loop safety recovery process defined in this embodiment, distinct from conventional single-point reset mechanisms. Its core lies in centralizing the system restart decision-making power in the wireless receiver control box and forcibly introducing the environmental status collected in real-time by the main probe as the basis for approval, thereby constructing a four-level logical chain of "request—perception—verification—execution." This step does not rely on manual visual judgment or experience-based estimation, but rather achieves a physical layer safety closed loop through hardware-level sensor feedback and embedded logic verification, making it suitable for high-risk conditions such as severe vibration, limited visibility, and nighttime operations. This step can operate independently on the private wireless channel (Sub-1G or 2.4GHz band) between the main probe and the control box, without needing to access an external network or cloud platform, ensuring low response latency (end-to-end latency ≤300ms) and communication autonomy.

[0051] Step 1: In response to receiving the restart trigger signal, the wireless receiver control box sends an environmental query request to the main probe pole; The "restart trigger signal" refers to the initial input event that initiates the collaborative restart process. Its source has two legitimate paths: one is a physical button operation locally configured on the wireless receiver control box, such as a long press of a mechanical microswitch marked with the "RESET" icon (contact life ≥ 10). 5 The first method involves a button press lasting at least 3 seconds, with the button signal being sent to the GPIO interrupt pin of the main control MCU via a debouncing circuit. The second method involves a remote restart command received through an authorized channel. This channel specifically refers to a Bluetooth (Bluetooth, short-range wireless communication protocol developed by the Bluetooth Special Interest Group) connection that has been paired and completed two-way authentication. The remote command must carry an AES-128 encrypted session token and timestamp, which is decrypted and verified by the control box's Bluetooth module before being forwarded to the main control MCU. Both paths must meet permission verification: local button triggering requires synchronous detection of the indicator light status (a solid red light indicates a locked state), and remote commands must match the preset device whitelist and operator role level (only "administrator" level accounts have triggering permissions). This design ensures both rapid on-site intervention and prevents unauthorized remote misoperation, complying with the SIL2 level reliability requirements for startup conditions in IEC 61508 functional safety.

[0052] Step 2: The main probe responds to the environmental query request, acquires the current environmental sensing data, and sends it to the wireless receiver control box; The "Environmental Query Request" is a dedicated command frame. Its frame structure follows the predefined command protocol defined in Specific Implementation 8, specifically including a frame header (0xAA), command code (0x03), data length (0x00), empty data field, CRC16 checksum, and frame tail (0x55). Upon receiving this frame, the first wireless communication module of the main probe immediately exits the low-power monitoring mode and drives all integrated sensors (including but not limited to the ultrasonic sensor array, millimeter-wave radar module, and infrared ranging unit) to perform an omnidirectional rapid scan—the scan cycle is strictly controlled within 100ms, and all sensors are triggered synchronously. The system collects raw distance data using timestamp alignment. The main processor performs median filtering and dynamic threshold removal on the raw data (removing outliers deviating from the mean by ±3σ), generating a set of minimum effective distance values ​​for each detection direction (six standard orientations: front / back / left / right / up / down). This set is encapsulated as a "safety status report instruction" (instruction code 0x04). The data fields are arranged in a fixed byte order: orientation identifier (1 byte) + minimum distance value (2 bytes, unit mm, resolution 1mm) + sensor status code (1 byte, 0x00 for normal, 0x01 for fault). The entire set is then verified by CRC16 and transmitted back via the first wireless module. This mechanism ensures that the reported data is the latest, simplest, and most reliable snapshot of the environment, avoiding caching of old data or averaging to obscure the true risk points.

[0053] Step 3: After the wireless receiver control box verifies that the current environmental perception data meets the safety conditions, it performs a system restart operation. The system restart operation includes sending a start-up permission command to the aerial work platform controller and a system restart command to the detection main pole. The "verifying that the current environmental perception data meets safety conditions" refers to a deterministic logical judgment on the safety status report command received in step two: the main control MCU parses the data domain, extracts the minimum distance values ​​in all six directions, and compares them one by one with the preset safety recovery threshold. This safety recovery threshold is a dynamic parameter, and its value is equal to the "sensor stopping distance threshold" defined in Specific Implementation Method 4 plus a fixed offset of 0.5 meters (this offset is a safety margin obtained through dual verification by GB / T 3805-2008 "Extra Low Voltage (ELV) Limits" and EN 13072-2013 "Safety Requirements for Aerial Work Platforms", and can be optionally modified to 0.3m or 0.8m, corresponding to different risk levels of different work scenarios). It is determined that "safety conditions are met" only when the minimum distance values ​​in all six directions are strictly greater than this safety recovery threshold; otherwise, it is determined that "safety conditions are not met". The decision logic is implemented using hard-coded Boolean expressions (e.g., if (d_front>T_safe&&d_rear>T_safe&&... )), eliminating the risk of floating-point operation errors and branch prediction failures. The "system restart operation" includes two concurrent actions: First, the main control MCU sends a "start allowed" signal to the aerial work platform controller via the relay output interface (dry contact type, contact capacity AC250V / 5A). This signal is a continuously closed level signal with a duration ≥200ms, ensuring reliable identification by the platform controller. Second, the main control MCU generates a "system restart command" with instruction code 0x02, an empty data field, and issues it after CRC verification. Upon delivery of the command, the main probe clears all alarm flags, shuts down the audible and visual alarms, resets the internal state machine to the initial monitoring state, and resumes the regular obstacle scan with a 100ms cycle. The two actions are executed strictly synchronously with a time deviation ≤10ms, avoiding a "safety window" where the platform has started but the collision avoidance system is not yet ready.

[0054] Through the above-described steps, this application achieves the following: After the wireless receiver control box enters a locked state due to a dangerous shutdown, the operator initiates a restart request, and the control box drives the detection pole to perform a mandatory, millisecond-level omnidirectional environmental re-sensing. Only when all detection directions confirm no obstacles and meet the distance threshold with a safety margin, is the platform controller granted startup permission and a system reset command issued to the detection pole simultaneously. This mechanism eliminates the risk of blind restarts caused by "pressing the reset button to resume operation" in traditional solutions, upgrading restart decisions from subjective experience-based judgment to objective data-driven decisions. This ensures that the collision avoidance system maintains the same safety level as the initial protection during the recovery phase after emergency intervention, significantly improving the inherent safety and human-machine collaborative reliability of the aerial work platform in complex dynamic environments. Example

[0055] Based on the above embodiments, this embodiment further provides: The restart trigger signal comes from the physical button operation on the wireless receiver control box, or from a remote restart command received through an authorized channel.

[0056] The restart trigger signal is the initial input signal that initiates the collaborative restart process. Essentially, it is a digital event signal with clear timing characteristics and authorization identifiers, used to wake up the main control MCU (Microcontroller Unit) in the wireless receiver control box, which is in a low-power locked state, and trigger subsequent environment queries, security verification, and system recovery procedures. This signal does not directly execute the restart action; instead, it serves as the entry condition for the collaborative state machine, ensuring that the restart operation is always controlled by a legitimate source that has undergone policy verification.

[0057] The physical button operation on the wireless receiver control box refers to the operation signals generated by mechanical or touch-sensitive operating components located on the casing of the wireless receiver control box. These physical buttons can be designed to prevent accidental touches, such as microswitches with a press travel ≥1.2 mm (e.g., Omron D2FC-F-7N), or capacitive touch buttons with pressure threshold recognition (response pressure ≥0.8 N). The button circuit is connected to the MCU's GPIO interrupt pin via pull-up resistors. When a closed signal lasting ≥3 seconds (i.e., a long press) is detected, the MCU determines it as a valid restart request and immediately enters the button debouncing and anti-double-click processing flow. If a short press (<1.5 seconds) or double-click is detected, it is ignored or mapped to other auxiliary functions (such as status self-check, buzzer mute). This design ensures that field personnel can quickly, intuitively, and without external equipment intervention initiate a safe restart after emergency troubleshooting, avoiding long-term system lock-up due to communication interruption or mobile terminal unavailability.

[0058] The remote restart command received through the authorized channel is an asynchronous digital command protected by both authentication and communication encryption. Its transmission path is independent of the Sub-1G / 2.4GHz main wireless channel between the main pole and the control box to avoid the risk of command failure due to main channel congestion or interference. This authorized channel is specifically implemented as a Bluetooth Low Energy (BLE) communication link. The control box has a built-in BLE module compliant with the Bluetooth 5.0 standard (such as Nordic RF52832) that supports the LE Secure Connections pairing protocol. Mobile terminals (such as Android / iOS handheld devices) initiate the connection through a pre-installed dedicated configuration APP, requiring the following steps: ① Bluetooth name matching (broadcast name format is "SMART-GUARD-XXXX", where XXXX is the last four digits of the device's unique MAC address); ② PIN code secondary authentication (the default initial PIN is "123456", which must be changed upon first use); ③ Command frame-level AES-128 encryption (the key is dynamically negotiated and generated during the pairing process, updated with each session). The data structure of the remote restart command includes command code 0x06, a timestamp (to prevent replay attacks), an operator ID hash (SHA-256), and a CRC32 checksum field. After receiving the command from the BLE module in the control box, the MCU performs layer-by-layer verification: first, it verifies the validity of the timestamp (deviation ≤ 5 seconds); then, it decrypts and compares the operator ID hash value to the whitelist database; finally, it verifies the CRC. Only after all verifications are successful is the command converted into an internal restart trigger signal. This mechanism allows remote monitoring centers or maintenance engineers to securely issue restart commands within a range of 100 meters (typical BLE Class 1 communication distance), meeting the needs of multi-machine cluster centralized management scenarios, while completely eliminating the possibility of unauthorized third parties forging restart commands through scanning, sniffing, or other methods.

[0059] The authorized channel does not refer to any encrypted channel in general, but specifically to a technical path that meets the following three constraints: First, physical layer isolation—using an independent radio frequency channel with a different frequency band and protocol stack from the main wireless communication module (responsible for interacting with the probe main pole) (e.g., the main channel is a 433MHz private FSK protocol, while the authorized channel is limited to 2.4GHz BLE); Second, logical layer authentication—embedding an authentication process based on asymmetric keys or pre-shared keys (PSK), and automatically locking the BLE connection channel for 10 minutes after three authentication failures; Third, application layer integrity—all remote commands must carry an anti-replay time window identifier and a message authentication code (MAC), and the MAC calculation covers the three elements of command code, payload, and timestamp. This definition excludes other wireless standards such as Wi-Fi, Zigbee, and NB-IoT as alternatives because they have inherent defects in industrial settings, such as high protocol stack complexity, uncontrollable power consumption, or strong dependence on base stations. These cannot meet the comprehensive requirements of this invention for real-time performance (end-to-end latency ≤200ms), low power consumption (standby current ≤10μA), and ease of deployment.

[0060] The various technical features form a strict hierarchical calling relationship: physical button operations operate at the hardware interface layer, providing the lowest-level, zero-dependency triggering path; the authorization channel runs at the protocol stack application layer, providing an auditable and traceable remote triggering path; both are uniformly processed through the MCU's internal interrupt vector table and event scheduler—regardless of the signal source, they are all converted into the same semantic "RESTART_REQ" internal event, which is then uniformly parsed and responded to by the collaborative restart state machine. This dual-source heterogeneous design ensures system availability under single-point failures (e.g., a physical button can still be used to restart the system when the Bluetooth module is damaged), and also enables elastic expansion of operation and maintenance strategies (e.g., updating the authentication algorithm of the authorization channel via OTA upgrades).

[0061] Through the above-described steps, this application achieves the following: by adopting a dual-path triggering mechanism of local physical buttons and authorized channels, it solves the problem in the background technology of a single restart triggering method that cannot adapt to the actual working conditions where on-site real-time operation and remote centralized management coexist. Therefore, it achieves both the certainty and timeliness of manual intervention in emergency situations and the support of the digital operation and maintenance system for closed-loop management of the equipment life cycle. At the same time, through the hard security constraints of the authorized channel, it effectively blocks the risk of illegal remote control, thus building a verifiable and implementable balance between convenience and security. Example

[0062] Based on the above embodiments, this embodiment further provides: Verifying that the current environmental perception data meets safety conditions includes: determining whether the minimum distance values ​​reported by the main detection pole in each direction are all greater than the preset safety recovery threshold.

[0063] Among them, "verifying that the current environmental perception data meets safety conditions" is a key safety criterion before the system performs a restart operation in a dangerous shutdown and lockout state. Its essence is to transform the abstract "environmental safety" into a quantifiable, repeatable, and verifiable numerical comparison process. This criterion does not rely on human visual inspection or experience judgment, but is a closed-loop state confirmation completed by the detection main pole and the wireless receiver control box in collaboration, constituting the core verification link in the collision avoidance system's safe restart logic.

[0064] The term "minimum distance values ​​reported by the main detection pole in each direction" refers to the process by which the main detection pole, upon receiving an environmental query request, performs an omnidirectional rapid scan (response time ≤ 100ms) on its integrated multi-directional sensor array (e.g., ultrasonic or laser ranging sensors in six directions: front, back, left, right, up, and down). It then extracts the distance values ​​of the nearest obstacles in each direction from the raw distance data collected in each direction, ultimately forming a distance set containing N values ​​(N≥2, N=6 in a typical embodiment). Each value in this set corresponds to a physical spatial direction, possessing clear spatial directionality and measurement traceability. Sensors in each direction can employ the same or different technologies (e.g., using lidar in the front to ensure accuracy, and ultrasonic sensors in the side to balance cost and anti-interference). Their installation positions, pitch angles, and horizontal deflection angles are calibrated and fixed within the main pole structure to ensure consistency of the spatial coordinate system. As an optional implementation, the directions can be dynamically configured—the number of effective detection directions and corresponding orientation codes are set through the Bluetooth parameter configuration steps (see Specific Implementation 3–4), for example, only the front + left and right directions are enabled, or it is expanded to eight directions (adding left front, right front, left rear, and right rear) to adapt to different platform structure forms (such as scissor lift, articulated boom, and telescopic boom aerial work platforms).

[0065] The "preset safety recovery threshold" is a safety margin parameter independent of the stopping distance threshold. Its value is strictly greater than the stopping distance threshold upon which dangerous stopping is based, and its value ranges from "stopping distance threshold + 0.3m to 0.8m," with "stopping distance threshold + 0.5m" being an option. This threshold is not a fixed constant but is stored in the non-volatile memory (such as EEPROM or Flash) of the wireless receiver control box. It can be modified on-site through the Bluetooth configuration channel described in embodiments 3-4. Its setting logic embodies dual safety redundancy: on the one hand, it avoids sensor measurement errors (such as ±2cm system error, temperature drift), and on the other hand, it reserves buffer space for personnel / tool ​​evacuation. As an optional implementation, this threshold can also be designed as a dynamic adaptive value—automatically adjusted according to the current operating height of the platform (e.g., +0.3m when height ≤ 6m, +0.5m when 6m < height ≤ 12m, and +0.8m when height > 12m), or generated by a weighted algorithm in combination with external parameters such as ambient light intensity and humidity, to cope with the perception uncertainty under complex working conditions.

[0066] The "judging whether all are greater than" part is a strict full-scale logical operation. This involves comparing each of the aforementioned N minimum distance values ​​with the same safety recovery threshold. Only when all N comparison results are "true" (i.e., the distance values ​​in all directions are strictly greater than the threshold) is the system deemed to "meet the safety conditions." If any direction does not meet the threshold, the system is deemed "not meeting the conditions," remains locked, and triggers local audio-visual feedback (e.g., three short beeps from the buzzer and rapid flashing of the red light). This judgment is executed at the firmware level by the main control MCU (microcontroller unit) of the wireless receiver control box, using a fixed-point comparison algorithm to avoid timing jitter introduced by floating-point operations, ensuring the determinism and timeliness of the judgment (single judgment time ≤ 5ms). As an optional implementation, this judgment logic can be extended to a weighted judgment—assigning different safety weights to different directions (e.g., 1.0 for the front, 1.2 for the top due to higher fall risk), normalizing the distance values ​​in each direction, summing them by weight, and then comparing them with a weighted threshold; or introducing a time window constraint, requiring that the conditions be met for three consecutive scans before final confirmation, to suppress transient interference and misjudgment.

[0067] There is a deterministic temporal and functional coupling relationship among the various technical features: the preset security recovery threshold provides a benchmark for judgment; the minimum distance value obtained by multi-directional scanning of the main probe is the data source for judgment; and the "all greater than" logical operation is the execution rule for judgment. The three together constitute an inseparable verification closed loop—without any one element, it is impossible to achieve an objective, comprehensive, and robust security assessment of the restart environment.

[0068] Through the above solution, this application achieves the following: after an emergency shutdown of an aerial work platform triggered by a collision risk, the system does not directly resume operation. Instead, the wireless receiver control box actively initiates an environmental verification request. The main probe generates a minimum distance set based on real-time sensing data from multiple directions, and the control box synchronously compares the data in all directions according to a preset and adjustable safety recovery threshold. Because this verification mechanism mandates sufficient safety margins in all detection directions, it solves the technical problem in the background technology that "restarting after simply removing obstacles may lead to secondary collisions." This achieves the technical effects of significantly improving restart safety, preventing derivative accidents caused by misoperation, and constructing multi-layered physical-logical dual protection. Example

[0069] Based on the above embodiments, this embodiment further provides: In the predefined command protocol, each command frame contains a checksum. The wireless receiver control box performs a checksum before parsing the command, and discards the command frame if the checksum fails.

[0070] The predefined command protocol refers to a data interaction specification with integrity protection capabilities specifically designed for ensuring the reliability of industrial-grade wireless communication between the probe pole and the wireless receiver control box. This protocol is independent of common communication standards (such as Zigbee, BLE link layer, or Wi-Fi MAC layer), employs a proprietary frame structure, and operates on RF communication modules in the Sub-1GHz band (e.g., 433MHz) or the 2.4GHz ISM band. It supports point-to-point low-latency transmission, with a typical over-the-air transmission rate of no less than 50kbps and an end-to-end command transmission latency of ≤100ms. This protocol does not rely on upper-layer TCP retransmission mechanisms; instead, it achieves reliable delivery of safety-critical commands through lightweight, deterministic, and controllable frame-level verification and acknowledgment logic. Its frame format strictly includes fixed fields: frame header (0xAA, used for synchronization and start identification), instruction type code (1 byte, such as 0x01 for dangerous shutdown, 0xA1 for acknowledgment response), data length field (1 byte, indicating the number of subsequent payload bytes), data field (including sensor ID, real-time distance value, timestamp, and other context information), and checksum (2 bytes, generated by the CRC-16-CCITT algorithm, with a polynomial of x). 16 + x 15 + x 5 + 1) Frame end (0x55, used to end recognition). This structural design balances parsing efficiency and anti-interference robustness, avoiding instruction misalignment caused by frame boundary misjudgment.

[0071] Each instruction frame contains a checksum, specifically a redundant checksum embedded within the instruction frame and strongly coupled to the data field, rather than an external channel code (such as a convolutional code) or link-layer FCS. This checksum is calculated by the main processor of the detection pole after completing instruction data encapsulation, based on the complete payload (including instruction type code and data field), and written into the frame structure immediately after the data field. The calculation process uses a hardware acceleration unit or an optimized software CRC function, with a single calculation time of ≤20μs under the condition that the main pole MCU main frequency is ≥48MHz, ensuring that it does not affect the response rhythm of 100Hz high-frequency obstacle detection. In optional embodiments, the checksum can also be replaced with an 8-bit checksum, a 16-bit XOR-16 checksum, or a BCH(15,11) block code. Among them, the BCH code can support single-bit error correction while maintaining the same computational overhead, and is suitable for strong interference conditions with electromagnetic noise intensity exceeding −80dBm (such as the working environment of nearby frequency converters and welding machines).

[0072] The wireless receiver control box performs verification before parsing instructions. This means that after the second wireless communication module of the control box demodulates the original radio frequency signal into a digital baseband frame, its main control MCU performs a verification step before entering the instruction semantic parsing process (such as determining the instruction type, extracting the distance value, and triggering the relay action). First, it verifies whether the frame header (0xAA) and frame tail (0x55) match. Second, it reads the corresponding number of bytes of payload based on the data length field in the frame. Finally, it calls the same CRC-16-CCITT algorithm to recalculate the check value of the payload and compares it bit by bit with the 2-byte checksum carried in the frame. Only when all three (frame header, frame tail, and CRC) pass the verification is the subsequent instruction execution process allowed to start. If any step fails, the entire frame data is marked as invalid and immediately cleared from the receive buffer, without entering any state machine branch or triggering an acknowledgment or alarm. This "verify first, then parse" timing is a hard constraint, implemented by an unbypassable verification gating logic in the MCU firmware, and cannot be disabled by configuration. In an optional embodiment, the verification process can be extended to two levels: the primary verification is CRC-16 fast verification, and after passing the primary verification, the secondary verification is initiated—the reasonable range of the distance value in the data field is checked (such as whether it is within the range of 0.1m–10.0m, whether it is a floating point NaN / Inf). Only if the double verification fails is the data discarded, so as to prevent malicious forgery of frames or abnormal data injection caused by sensor hardware malfunctions.

[0073] In this scenario, "discarding" the instruction frame upon verification failure means physically removing the frame from the receive buffer, releasing the corresponding memory space, and not sending any form of negative acknowledgment (NAK) to the master pole. This strategy avoids increased channel contention and broadcast storms caused by NAK feedback, maintaining channel clearance in multi-master pole coexistence systems. Simultaneously, the discard operation triggers local log recording (stored in non-volatile Flash, containing a discard timestamp, a hexadecimal snapshot of the original frame, and a verification failure type code) for offline fault diagnosis. In an optional embodiment, when five consecutive frames fail verification with an interval of less than 200ms, the control box can automatically switch to a backup communication channel (e.g., from channel 11 to channel 25) and simultaneously report a "channel quality degradation" event to the mobile terminal's Bluetooth channel, prompting maintenance personnel to check the on-site radio frequency environment.

[0074] The various technical features work synergistically as follows: the predefined instruction protocol provides a structured carrier for the verification mechanism, ensuring a strong binding between the checksum and business data; the algorithm selection and embedding position of the checksum determine the balance between error detection coverage and real-time performance; the timing constraint of "mandatory verification before parsing" eliminates the risk path of corrupted data entering the control logic; and the "discarding" strategy cuts off the error propagation chain at the system architecture level, preventing invalid instructions from being misinterpreted as high-risk actions such as shutdown or restart. These four elements constitute a closed-loop protection: protocol definition framework → checksum redundancy injection → verification timing locking of the entry point → discarding action blocking the exit point.

[0075] Through the above scheme, this application achieves the following: by adopting a predefined command protocol and a built-in checksum, and by strictly implementing the "verify first, then parse" process in the control box, coupled with a feedback-free discard mechanism, the wireless receiving control box can actively identify and isolate transmission damage such as bit flipping, frame truncation, or data sticking caused by industrial electromagnetic interference, signal attenuation, or multipath effects; thereby preventing damaged frames from being misinterpreted as dangerous shutdown commands (for example, normal data originally meaning "distance 3.2m" is misread as "distance 0.0m" due to CRC mismatch, thus triggering a false shutdown), and also avoiding the misjudgment of damaged confirmation response frames as new dangerous commands; ultimately solving the problem of "insufficient wireless communication reliability and simple protocols being easily interfered with, leading to command loss or false triggering" mentioned in the background technology, significantly reducing the probability of false alarm shutdown, and improving the functional safety level of the collision avoidance system in complex industrial environments (meeting the basic requirements of IEC 61508 SIL2 level for safety-related communication integrity). Example

[0076] Intelligent collision avoidance systems for aerial work platforms have long faced practical challenges, including poor reliability of wired connections, limited wireless control functionality, and weak safety coordination logic. Traditional wired solutions suffer from complex wiring, easily loosened interfaces, and accelerated cable aging under high-frequency vibration and repeated bending, leading to a high risk of signal interruption. Existing wireless solutions often employ simple switch-to-transmission mechanisms without verification, acknowledgment, or retransmission, making them highly susceptible to command loss or false triggering in industrial environments with strong electromagnetic interference, failing to meet functional safety requirements. Furthermore, parameter adjustments require disassembly and rewiring for debugging, lacking remote adaptation capabilities; system restart permissions after shutdown are ambiguous, failing to establish a closed-loop safety process of "detection-confirmation-verification-authorization-execution," posing a risk of secondary accidents caused by single-point failures. Therefore, there is an urgent need for a physical wireless control system that deeply integrates highly reliable communication protocols, configurable control logic, and a dual-end collaborative state machine to support the stable, reliable, and mass-producible implementation of the aforementioned methods in real-world operational scenarios.

[0077] This application raises the following points: The wireless control system of the aerial work platform collision avoidance system includes a detection pole and a wireless receiver control box.

[0078] This embodiment provides an engineerable physical system architecture. Its core lies in concretizing all the aforementioned software control logic into two functionally defined, clearly interfaced, and reliably coordinated hardware units through firmware burning, hardware module integration, and communication protocol solidification. The main detection pole, as the front-end sensing and command initiation node, integrates a multi-directional ultrasonic / laser ranging sensor array, an embedded microcontroller (MCU), a first wireless communication module (operating in the Sub-1G band or a 2.4GHz proprietary protocol RF module), a power management circuit, and status indicator lights. The wireless receiver control box, as the back-end execution and decision-making hub, integrates a main control MCU, a second wireless communication module strictly paired with the main detection pole, an independent Bluetooth communication module (Bluetooth 5.0 and above, supporting BLE encrypted connection), a relay output interface (used to cut off the power supply circuit of the platform's main controller), physical operation buttons, an audible and visual alarm unit (including a buzzer and red / green dual-color LEDs), non-volatile memory (such as EEPROM or Flash), and a wide-temperature-range power module. The two establish a low-latency, highly robust connection through a pre-defined two-way wireless channel and run the same set of security-verified firmware, enabling the entire system to have both methodological intelligent control capabilities and product-level physical feasibility and environmental adaptability.

[0079] The "detection main rod" refers to a columnar structure installed at the top of the boom or a key circumferential position of the aerial work platform. Inside, at least three independently operating distance sensors are arranged axially or radially to collect real-time distance data to obstacles in multi-dimensional space, including those in front, to the left, to the right, and diagonally above. Its MCU periodically scans the sensor data; when the measured distance in any direction falls within a preset stopping distance threshold, it is deemed a dangerous state and a command generation process is triggered. This main rod does not directly perform mechanical braking actions; it only undertakes sensing, judgment, and command sending / receiving functions. All its control logic is implemented by firmware and cannot be arbitrarily modified by the user. Optionally, the detection main rod can also adopt an integrated encapsulation design, with the shell material being UV-resistant and corrosion-resistant reinforced polycarbonate (PC+ABS alloy), achieving an IP67 protection rating, suitable for wide-temperature operating environments from -25℃ to 70℃; or it can be replaced with a TOF (Time-of-Flight) laser sensor module with temperature compensation function to improve distance measurement stability in rainy and foggy weather.

[0080] The "wireless receiver control box" refers to an independent control unit fixed inside the electrical control cabinet of the aerial work platform or on the side wall of the cab. Its main control MCU communicates with the platform's main controller via a hard-wired interface (such as dry contacts or CAN bus), providing electrical isolation. Its second wireless communication module and the first wireless communication module of the detection pole are ID-bound and channel-synchronized before leaving the factory, supporting frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS) anti-interference mechanisms. The Bluetooth module is dedicated to the parameter configuration channel, physically isolated and logically independent from the main wireless channel, avoiding interference with safety command transmission during the configuration process. Its relay output interface adopts a dual-contact redundancy design to ensure reliable power cut-off of the platform in the event of a single-path failure. All input / output signals are optically isolated and protected by TVS diodes. Optionally, the control box can also integrate a LoRaWAN module as a backup long-distance communication link for uploading equipment health status to the cloud platform; or use an ARM Cortex-M4 core MCU to replace the traditional 8-bit MCU to support more complex CRC check algorithms and multi-task scheduling strategies.

[0081] The phrase "configured to execute the above method" refers to the following: the firmware programs of the main probe and the wireless receiver control box embed a complete state machine engine and protocol stack. This configuration includes not only low-level driver code such as command frame format parsing, CRC16 verification, response waiting timer, retransmission counter, Bluetooth pairing key verification, parameter writing verification, and environment query response logic, but also upper-level collaborative control processes. For example, after sending a dangerous stop command, the main probe automatically enters a three-state loop of "waiting for confirmation → timeout retransmission → failure alarm." After receiving a dangerous stop command, the control box must complete verification, execute a power-off action, and send an confirmation frame within ≤50ms; otherwise, it is considered a communication anomaly. During system restart, both strictly adhere to the four-step timing constraint of "control box sends request → main probe fast scan feedback → control box verification → dual-channel synchronous release." This configuration is burned into the chip's Flash memory once via the JTAG / SWD interface, and key parameter areas (such as security thresholds and maximum retransmission counts) support dynamic updates via encrypted Bluetooth commands. However, all changes must undergo internal MCU permission verification and pre-write read comparison to prevent unauthorized tampering.

[0082] The two hardware units interact via a predefined wireless communication protocol, which defines a unified frame structure: frame header (0xAA), instruction type code (1 byte), data length (1 byte), data field (including sensor ID, distance value, timestamp, etc.), CRC16 checksum (2 bytes), and frame trailer (0x55). All instruction frames are required to carry a checksum field. The control box must complete the full frame header / frame trailer identification and CRC check before parsing. If any step fails, the frame is discarded and no response is generated. The main pole end is equipped with a 200ms response waiting window and a maximum of 3 retransmission mechanisms to ensure that the transmission success rate of critical instructions is not less than 99.99% in a typical industrial signal-to-noise ratio (≥15dB) environment. The control box end has a built-in watchdog timer. If the main pole heartbeat frame is not received for 3 consecutive times, the communication interruption event is actively reported and the output is locked to prevent "silent failure".

[0083] Through the above technical solution, this application achieves deep physical coupling and precise logical coordination between the detection main pole and the wireless receiving control box. In a typical high-altitude operation: when the platform boom extends forward and approaches the building's exterior wall, the sensor on the right side of the detection main pole detects that the distance has shortened to 1.2 meters (below the preset stopping threshold of 1.5 meters). The MCU immediately encapsulates a dangerous stopping frame with instruction code 0x01, adds CRC16 verification, and sends it through the Sub-1G module. The control box completes reception, verification, and relay action within 15ms, cutting off the platform's travel and lifting power, and simultaneously sending back an acknowledgment frame. After receiving the acknowledgment, the main pole illuminates a red warning light and stops outputting movement commands. After the operator clears the obstacle, they press and hold the control box's reset button for 3 seconds. The control box then sends an environmental query frame, and the main pole completes an omnidirectional scan within 100ms and returns a safety report indicating that the minimum distance is greater than 2.0 meters. After the control box verifies the operation, it outputs an "enable" dry contact signal to the platform's main controller and sends a system restart command to the main pole. Both parties simultaneously exit the locked state and resume normal monitoring. Because the detection pole and the wireless receiver control box are configured together to execute a complete methodology that includes ensuring the reliability of commands, remotely adjustable parameters, and collaborative restart verification, the systemic defects mentioned in the background technology, such as unreliable wired connections, lack of redundancy in wireless control, and unclear restart permissions, are fundamentally solved. This forms a physical anti-collision control system that combines high safety, strong adaptability, and easy maintenance, providing a reliable physical-level safety barrier for aerial work platforms.

[0084] Example 10: Based on the above embodiments, this embodiment further provides: A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0085] The computer-readable storage medium involved in this embodiment is a physical carrier used to carry and persistently store the software code that implements the wireless control logic of the aerial work platform collision avoidance system. Essentially, it solidifies all the aforementioned method steps—including command transmission, response waiting and retransmission, local wireless parameter configuration, collaborative restart process, frame verification and parsing, etc.—into an executable program within a non-volatile storage structure. This medium itself does not constitute an independent hardware device, but rather serves as the software operating basis for the embedded control system in the detection main pole or wireless receiver control box. This allows both to automatically complete the entire safety control closed loop simply by loading and running the program within it, without external intervention. Its technical advantage lies in transforming the safety control functions, which originally relied on dedicated hardware logic or fixed circuits, into software-defined behaviors that are version-iterative, remotely updatable, and batch-deployable, significantly enhancing system adaptability, maintainability, and intellectual property protection.

[0086] "Computer-readable storage medium" refers to a physical storage unit that can be recognized, addressed, and read by embedded processors such as microcontrollers (MCUs), digital signal processors (DSPs), or system-on-a-chip (SoCs). Its specific forms include, but are not limited to, any or a combination of embedded flash memory, serial peripheral interface flash memory (SPI Flash), electrically erasable programmable read-only memory (EEPROM), secure digital card (SD Card), universal serial bus flash drive (USB Flash Drive), and solid-state drive (SSD). In the optional scheme of this embodiment, the probe main rod and the wireless receiver control box are respectively equipped with SPI Flash chips with a capacity of not less than 512KB, and use Quad SPI mode for high-speed reading to ensure that the instruction parsing and state switching response time is ≤10ms. During system power-on initialization, the medium is mapped to the program space by the processor. Its stored content is compiled into an executable binary image with a defined entry address. It supports partitioned storage by functional modules, such as: a protocol stack area (including frame header 0xAA / frame tail 0x55 definitions and CRC16 checksum implementation), a communication driver area (Sub-1G RF transceiver control logic), a state machine area (containing six-state transition logic: "idle → detection → send → wait → retransmission → acknowledgment"), a configuration management area (Bluetooth pairing key verification and parameter pre-write verification logic), and a collaborative control area (environment query request triggering, security threshold comparison, and dual-channel command issuance timing control). As an optional implementation, the medium can also employ a Secure Element with an encryption engine, integrating key distribution and firmware signature verification mechanisms while storing the program to prevent unauthorized tampering. Another optional implementation is to store the program in the medium as a differential upgrade package, supporting OTA (Over-The-Air) dynamic patch loading without requiring a full package refresh.

[0087] Among them, "computer program" refers to a sequence of machine code written in a high-level language (such as C / C++) or assembly language and generated by cross-compilation. Its functional structure strictly corresponds to the method steps defined above: the program contains at least five core functional modules—(1) Dangerous event detection and instruction encapsulation module, which is used to receive raw distance data from the sensor array, trigger instruction generation according to the preset collision judgment rules (such as minimum distance in one direction < stopping distance threshold), and add check codes according to the frame format specified above; (2) Wireless instruction transmission and response management module, which is used to start a timer to wait for confirmation and response, execute a maximum of 3 retransmission strategies, and record communication abnormality logs after timeout. (3) Local wireless connection establishment and configuration parsing module, used to listen to Bluetooth broadcasts, respond to pairing requests, decrypt received configuration data packets, and write the updated warning distance threshold, shutdown distance threshold, and wireless communication channel number into the non-volatile register; (4) Cooperative restart control module, used to respond to physical button or authentication Bluetooth commands, initiate environmental queries to the detection pole, and perform security condition verification based on the returned multi-directional minimum distance value; (5) Command verification and execution scheduling module, used to sequentially verify the frame header, frame tail, and CRC16 value of the received data frame at the receiving end, and only call downstream actions such as relay driving, audible and visual alarm, and platform enabling after the verification is passed. The modules communicate loosely through a shared memory area or message queue to avoid blocking calls and ensure that high-priority dangerous commands (such as the dangerous shutdown command mentioned above) always receive the highest interrupt response level. As an optional implementation, the program can use a real-time operating system (RTOS) for task scheduling, assigning independent task stacks and priorities to different functional modules. For example, instruction verification and halt execution can be set as the highest priority task (Priority 0), while Bluetooth configuration processing can be set as a medium-low priority task (Priority 3). Another optional implementation is to use a bare-metal cyclic scanning architecture, polling each status flag bit in the main loop, which is suitable for resource-constrained 8-bit MCU platforms.

[0088] The phrase "the steps to implement the above-described method when executed by the processor" emphasizes that the program's execution result must completely reproduce the technical process defined above, rather than just partial functionality. Specifically: when the processor loads the program and begins execution, its behavior is as follows: the main pole-side processor periodically collects data from ultrasonic / laser ranging sensors. Once the obstacle determination conditions set above are met, it calls the instruction encapsulation module to generate a dangerous stop instruction frame containing a checksum and sends it through the radio frequency module. Upon receiving this frame, the wireless receiver control box-side processor first calls the verification module to complete CRC16 verification. If the verification is successful, it immediately executes the stop action and sends a confirmation response back to the main pole, while simultaneously starting a response waiting timer. If no response is received, the retransmission management module triggers a retransmission. At the same time, when the mobile terminal connects to the control box via Bluetooth and sends new parameters, the configuration parsing module writes the parsed threshold into the corresponding register, thereby dynamically changing the subsequent danger determination benchmark. When the system is in a stop-locked state, the restart control module responds to the restart trigger signal, actively initiates an environmental query, and performs dual verification based on the returned data. Finally, it synchronously sends start-up permission and system restart commands to the platform controller and the main pole. All of the above behaviors are autonomously triggered by the same program in different runtime contexts, without manual intervention or additional control logic. As an optional implementation, the program supports dual-core heterogeneous deployment: the main core (such as ARM Cortex-M4) is responsible for real-time control and communication scheduling, while the co-core (such as RISC-V ULP core) is dedicated to running the low-power Bluetooth protocol stack. The two cores synchronize configuration change events through shared memory and mailbox mechanisms. Another optional implementation is that the program has built-in self-checking logic, which checks the integrity of key function pointers and the CRC of stored parameters at each startup. If an anomaly is found, it automatically enters a security degradation mode, retaining only basic obstacle detection and hard shutdown functions.

[0089] The layout of the above modules in the storage medium is not in a fixed order, but is dynamically loaded according to the processor bootloader process: in the initial stage, only the minimum kernel and verification module are loaded to ensure basic security; after the system stabilizes, the configuration management module and the coordination control module are loaded as needed, thereby reducing startup latency and improving anti-interference capability. The functional modules communicate through standardized interfaces. For example, the instruction encapsulation module outputs a unified format `structcmd_frame_t` structure, containing `frame_header`, `cmd_type`, `payload_len`, `payload_data`, and `crc16` fields; the verification module inputs this structure and returns a boolean verification result; the response management module then uses this result to determine whether to start a timer or trigger a retransmission. This interface abstraction design allows the same program to be deployed on both the probe main pole (using an STM32H7 series MCU as the hardware platform) and the wireless receiver control box (using an NXP i.MX RT1064 as the hardware platform), requiring only adaptation to the underlying driver layer without modifying the business logic layer code.

[0090] Through the above technical solution, this application realizes the embedding of all wireless control logic of the aerial work platform anti-collision system into a general-purpose storage medium in software form, and ensures that it can be accurately loaded and executed by processors on different embedded hardware platforms, thereby completely reproducing the method steps defined above. Because the computer program is constructed to strictly cover the instruction protocol definition (including frame structure and verification mechanism), bidirectional interaction process (including response waiting and retransmission strategy), parameter configuration channel (including Bluetooth connection and threshold update), and cooperative state machine (including environment query and security verification), it solves the problems pointed out in the background technology that "existing wireless solutions only transmit switch signals, lack handshake confirmation, and cannot support remote adjustment and safe recovery". It achieves the technical effects of high-reliability transmission of key safety instructions, flexible and configurable management of system operating parameters, and multiple security verifications for the recovery process after shutdown. Also, because the program encapsulates all control logic in executable code form, even if a third party bypasses the hardware structure and directly copies the control idea, as long as the software with substantially the same function runs in its product, it falls within the scope of this protection, thus providing the inventor with a more solid and advanced intellectual property defense barrier.

[0091] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A wireless control method for a boom collision avoidance system for aerial work platforms, applied to a system comprising a detection main boom and a wireless receiving control box, characterized in that, The method includes: Command transmission steps: When the main detection pole detects an obstacle, it wirelessly sends a dangerous shutdown command to the wireless receiving control box based on a predefined command protocol; After successfully receiving and executing the dangerous shutdown command, the wireless receiver control box sends an acknowledgment response to the detection main pole.

2. The wireless control method of a collision prevention system of a high-altitude work platform according to claim 1, characterized in that, In the instruction transmission step, after sending the dangerous stop instruction, the detection main rod starts a response waiting timer; if the confirmation response is not received within a preset time, the instruction is retransmitted until the maximum number of retransmissions is reached or confirmation is received.

3. The wireless control method of a collision prevention system of a high-altitude work platform according to claim 1, characterized in that, The method also includes a parameter configuration step: Establish a local wireless connection between the wireless receiver control box and the external mobile terminal; The configuration data is received from the mobile terminal via the local wireless connection. Based on the configuration data, update the anti-collision system operating parameters stored in the wireless receiver control box.

4. The wireless control method for the aerial work platform anti-collision system according to claim 3, characterized in that, The local wireless connection is a Bluetooth connection; the operating parameters include at least the following: sensor warning distance threshold, sensor shutdown distance threshold, and wireless communication channel.

5. The wireless control method for the aerial work platform anti-collision system according to claim 1, characterized in that, The method further includes a collaborative restart step, which is executed after the wireless receiver control box triggers the dangerous shutdown command. The collaborative restart step includes: In response to receiving a restart trigger signal, the wireless receiver control box sends an environment query request to the detection main pole; The detection pole responds to the environmental query request, acquires the current environmental perception data, and sends it to the wireless receiving control box; After verifying that the current environmental perception data meets the safety conditions, the wireless receiver control box performs a system restart operation. The system restart operation includes sending a start-up permission command to the aerial work platform controller and a system restart command to the detection main pole.

6. The wireless control method of a boom platform anti-collision system according to claim 5, characterized in that, The restart trigger signal originates from the physical button operation on the wireless receiver control box, or from a remote restart command received through an authorized channel.

7. The wireless control method of a collision prevention system of a high-altitude work platform according to claim 5, characterized in that, The verification that the current environmental perception data meets the safety conditions includes: determining whether the minimum distance values ​​in each direction reported by the detection main rod are all greater than a preset safety recovery threshold.

8. The wireless control method of a boom platform anti-collision system according to claim 1, characterized in that, In the predefined instruction protocol, each instruction frame contains a checksum. The wireless receiving control box performs a checksum before parsing the instruction, and discards the instruction frame if the checksum fails.

9. Wireless control system for a collision prevention system of an aerial work platform, comprising a detection mast and a wireless receiving control box, characterized in that, The main probe and the wireless receiver control box are configured to perform the method as described in any one of claims 1 to 8.

10. A computer readable storage medium having stored thereon a computer program, characterized in that When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 8.

Images