A construction site work event recognition method and system

Abstract

The application discloses a kind of construction site operation event identification method and system, method includes: according to the personnel fall event detected by intelligent safety helmet, through the relay forwarding of workmate safety helmet to remote camera, make up the number of camera gap;According to all the camera that receives help message automatically join multicast group, generate multicast message containing verification confirmation, verification rejection or cannot verify result;According to the camera that possesses AI detection algorithm receives cannot verify message, generates verification confirmation or verification rejection proxy message;According to all the verification message collected by temporary decision maker, response workmate is guided by equivalent rescue distance index, realizes dynamic rescue network construction.Using the embodiment of the application, the detection accuracy of construction site emergency and response timeliness can be improved, to provide intelligent, reliable active safety protection capability for construction site.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, specifically a method and system for identifying construction site operation events. Background Technology

[0002] Construction sites are complex environments with dense populations and high safety risks. Traditional construction site safety monitoring mainly relies on fixed cameras and manual monitoring, which suffers from numerous blind spots and delayed responses. In recent years, with the development of technologies such as smart safety helmets and the Internet of Things (IoT), proactive early warning and event detection based on wearable devices have gradually become a research hotspot. However, existing methods still have significant shortcomings in the detection and response to emergencies such as falls: on the one hand, the reliability of single-point device detection is limited and easily affected by factors such as obstruction and lighting, leading to false alarms and missed alarms; on the other hand, the lack of a multi-device collaborative linkage mechanism after an event makes it difficult to quickly obtain multi-angle visual evidence, resulting in insufficient basis for rescue decisions. In addition, the complex network environment of construction sites, insufficient camera coverage in some areas, and the inability of traditional fixed communication methods to guarantee the reliable transmission of distress messages, coupled with the lack of an effective distributed computing power scheduling mechanism for collaborative verification of suspicious events, cause delays or misjudgments in rescue responses. Therefore, there is an urgent need for an intelligent identification method for construction site operation events that can integrate wearable devices and fixed camera resources to achieve dynamic networking, collaborative detection, and hierarchical decision-making. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for identifying construction site operation events, in order to overcome the shortcomings of the prior art, improve the detection accuracy and response time of construction site emergencies, and provide intelligent and reliable proactive safety protection capabilities for construction sites.

[0004] One embodiment of this application provides a method for identifying construction site operation events, the method comprising: Event Triggering and Dynamic Agent Reporting: Based on the smart safety helmet detecting a person falling, it determines whether the number of surrounding cameras meets a preset threshold. If not, a dynamic communication agent selection mechanism is activated. Based on a dynamically adjusted RSSI threshold range, qualified worker safety helmets are selected as relays, and agents report distress messages to remote cameras to fill the gap in the number of cameras. The RSSI threshold range is used to eliminate redundant workers with overlapping viewpoints due to excessively strong signals and workers with unstable communication links due to excessively weak signals. Multicast group establishment and initial visual verification: All cameras that receive the distress message are automatically added to the multicast group. Cameras with pan-tilt units turn their pan-tilt units according to the distress coordinates and perform initial visual verification according to their own capabilities, generating multicast messages containing verification confirmation, verification rejection, or verification failure results. Distributed collaborative computing power proxy verification: Based on the unverifiable message received by the camera with AI detection algorithm, the unverifiable image is subjected to distributed collaborative detection through cache hierarchical management including degraded storage strategy, priority random timer competition associated with camera status and proxy detection list mechanism, and a verification confirmation or verification rejection proxy message is generated. Collaborative decision-making and tiered rescue response: Based on all verified messages collected by the temporary decision-maker, the confidence level of the distress call is calculated. When the confidence level reaches a preset threshold, the worker's rescue request is triggered. The frequency of the audible and visual alarms is dynamically adjusted based on the equivalent rescue distance index generated by fusing the distress call confidence level with the distance to the worker in need, and the responding workers are guided in a tiered manner to achieve the construction of a dynamic rescue network.

[0005] Optionally, the event triggering and dynamic proxy reporting include: Fall detection: Based on the built-in accelerometer of the smart safety helmet, a sudden acceleration is detected and the worker is then brought to a standstill, indicating that a fall may have occurred. Surrounding camera scanning: Triggered by an event, the distress helmet automatically scans for nearby Bluetooth signals, identifies surrounding cameras, and obtains their device IDs; Camera count determination: Compare the number of scanned cameras with the preset number. If the number is less than the preset number, proceed to the step of scanning safety helmets and collecting information; otherwise, proceed to the step of reporting directly. Worker safety helmet scanning and information collection: In the event of insufficient number of cameras, the distress helmet scans the surrounding Bluetooth signals to identify the worker's safety helmet, obtains the RSSI value of each worker's safety helmet and the information of the surrounding supplementary cameras, and generates a table of supplementary camera information around the worker's safety helmet; Dynamic RSSI threshold range calculation: Based on the number of camera gaps, the number of available worker safety helmets, and the number of cameras that each worker safety helmet can supplement, a reasonable RSSI threshold range [R1, R2] is dynamically calculated. R1 is the communication stability threshold, used to remove worker safety helmets with too weak RSSI, and R2 is the coverage redundancy threshold, used to remove worker safety helmets with too strong RSSI. By verifying and correcting the RSSI threshold range, it is ensured that the total number of cameras that worker safety helmets falling within the range can supplement meets the number of camera gaps, thus obtaining a candidate agent worker safety helmet list. Communication proxy node selection and proxy reporting: Based on the list of candidate worker safety helmets, prioritize the worker safety helmet with an RSSI value closer to R2 and that can fill the gap in the camera as the communication proxy node, and use Bluetooth to instruct its proxy to report the distress message to the remote camera; Direct reporting: Based on events where the number of cameras meets a preset threshold, the distress helmet establishes a Bluetooth connection with each camera detected by direct scanning and directly reports a distress message via Bluetooth.

[0006] Optionally, the multicast group establishment and initial visual verification include: Multicast group joining: Record the distress information based on all cameras that received the distress message, including the event ID, distress helmet ID, distress location coordinates, and a list of worker helmet IDs near the distress helmet, and automatically join multicast group G for multicast communication; Gimbal turning control: Based on the camera equipped with a gimbal, the camera's own installation position coordinates, installation height, and the worker's distress call coordinates, the camera calculates the azimuth and pitch angles to determine whether the distress call location is within the line of sight. If so, the camera drives the gimbal to turn and align with the distress call coordinates. Initial visual verification classification response: Classify and process according to the camera's own capabilities: Cameras with AI detection algorithms that can make judgments perform human detection and posture recognition, and send a verification confirmation or verification rejection message to multicast group G; Cameras without AI detection algorithms or with AI detection algorithms but unable to make judgments due to their own reasons send an unverifiable message to multicast group G, carrying a compressed captured image; Cameras with AI detection algorithms but unable to make judgments due to external reasons are not processed.

[0007] Optionally, the distributed collaborative computing power agent verification includes: Cache hierarchical management: Based on the unverifiable multicast messages received by cameras with AI detection algorithms, the first message to arrive with the same event ID is processed first, and the remaining messages are temporarily stored in the cache. If the free space in the cache is less than the threshold, subsequent messages will only store the event ID, the distress helmet ID, and the unconfirmed camera ID, and will not store compressed images to save storage space. Priority Random Timer Competition: Random timers of different priorities are started based on the camera's own state to participate in the competition for the proxy detection task: Cameras that have not turned and have AI detection algorithms start a random timer with a preset high priority time range, while cameras that have turned and have AI detection algorithms start a random timer with a preset second priority time range. Computing power proxy detection execution: AI analysis is performed on the cached images based on the camera whose timeout expires first. If a determination is made, a verification confirmation or verification rejection proxy message is sent to multicast group G on behalf of the original camera. Update the proxy detection list: After the proxy is executed based on the proxy camera, the mapping pair of event ID and proxied camera ID is stored in the local proxy detection list; after other cameras receive the proxy results, the associated timer is canceled and the mapping pair is also stored to avoid duplicate processing; Continuous processing of cached messages: After processing all current messages from all cameras, check the cache area and delete processed messages. If there are still unprocessed messages in the cache and they are not in the proxy detection list, repeat the priority random timer competition and computing power proxy detection execution steps. Image Request and Retransmission: If a camera detects that a compressed image is not stored when processing cached messages, it sends a detection image request message to multicast group G; if other cameras find a cached image, they unicast a retransmission and send a response message to avoid duplicate requests.

[0008] Optionally, the collaborative decision-making and tiered rescue response include: Provisional decision-maker determination: Based on each event ID, the first camera to send a verification confirmation or verification rejection multicast message becomes the provisional decision-maker associated with that event ID; SOS confidence calculation: Based on the temporary decision-maker's listening to verification messages of the same event sent by other cameras, if no new messages are received within a preset time, the percentage of verified confirmation messages is calculated as the SOS confidence E; Rescue request triggered: Based on the rescue confidence level E being greater than or equal to a preset threshold, the temporary decision-maker sends a coworker rescue request message to multicast group G, which includes the event ID, the rescue helmet ID, the rescue location coordinates, the rescue confidence level, and a list of coworker safety helmet IDs near the rescue helmet; Dynamic rescue network construction: Based on all cameras that have received rescue request messages, scan the surrounding safety helmets via Bluetooth, prioritize establishing a connection with the safety helmets in the list of safety helmet IDs of coworkers near the safety helmet in distress and send a distress message, and then send it to the remaining safety helmets; Tiered response and dynamic guidance: The straight-line distance D between the worker and the coordinates of the distress call is calculated based on the worker's safety helmet after receiving the distress message. Combined with the distress call confidence level E, the equivalent rescue distance D / E is obtained. Tiered response is performed according to the preset distance threshold, triggering audible and visual alarms of different frequencies, and the response is adjusted in real time as the rescuers move.

[0009] Optionally, the method further includes a two-stage collaborative decision-making mechanism based on multi-dimensional credibility weights of camera physical location and visual quality: Single camera credibility weight calculation: Based on the camera's own physical location factor and visual quality factor, the credibility weight W of the single camera is dynamically calculated in real time when the camera sends a verification confirmation or verification rejection message. The physical location factor includes distance factor and angle factor, and the visual quality factor includes image quality factor and occlusion factor. AI-free camera weight transfer and completion: When a camera without AI detection algorithm sends an unverifiable message, it calculates and carries a physical location factor. The subsequent proxy detection camera combines the received physical location factor with the visual quality factor obtained from its own analysis during proxy detection to complete and calculate the final single-camera judgment credibility weight W of the proxy camera. The first stage is high-confidence rapid decision-making: Based on the verification messages sent by other cameras collected by the temporary decision-maker, high-confidence messages with a single camera's judgment confidence weight W greater than the first threshold are selected. The first round of distress call confidence E1 is calculated based on the weight of these messages. If E1 is greater than or equal to the distress call confidence threshold, the rescue request is triggered in advance. The second stage is a routine decision-making process with low confidence: if the confidence threshold for distress is not reached according to the first round of calculation, then the collaborative decision-making and tiered rescue response are carried out according to the steps, all verified messages are collected to calculate the confidence level E for distress, and the rescue request is determined based on E.

[0010] Another embodiment of this application provides a construction site operation event recognition system, the system comprising: The triggering module is used for event triggering and dynamic proxy reporting: based on the smart safety helmet detecting a person falling, it determines whether the number of surrounding cameras meets a preset threshold. If not, it activates a dynamic communication proxy selection mechanism, using dynamically adjusted RSSI threshold ranges to select qualified worker safety helmets as relays, and proxy reports distress messages to remote cameras to fill the gap in the number of cameras; wherein, the RSSI threshold range is used to eliminate redundant workers whose viewpoints overlap due to excessively strong signals and workers whose communication links are unstable due to excessively weak signals; The module is used for multicast group establishment and initial visual verification: all cameras that receive the distress message are automatically added to the multicast group. Cameras with pan-tilt units turn their pan-tilt units according to the distress coordinates and perform initial visual verification according to their own capabilities, generating multicast messages containing verification confirmation, verification rejection or verification failure results. The verification module is used for distributed collaborative computing power proxy verification: based on the unverifiable message received by the camera with AI detection algorithm, the unverifiable image is detected in a distributed collaborative manner through cache hierarchical management including degraded storage strategy, priority random timer competition associated with camera status and proxy detection list mechanism, and a verification confirmation or verification rejection proxy message is generated. The decision-making module is used for collaborative decision-making and tiered rescue response: Based on all verified messages collected by the temporary decision-maker, the confidence level of the distress call is calculated. When the confidence level reaches a preset threshold, the worker's rescue request is triggered. The frequency of the audible and visual alarms is dynamically adjusted based on the equivalent rescue distance index generated by fusing the distress call confidence level and the distance to the worker in need, and the responding workers are guided in a tiered manner to realize the construction of a dynamic rescue network.

[0011] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0012] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0013] Compared with existing technologies, the construction site operation event identification method provided by this invention can improve the detection accuracy and response time of construction site emergencies, and provide intelligent and reliable proactive safety protection capabilities for construction sites. Attached Figure Description

[0014] Figure 1 A hardware structure block diagram of a computer terminal for a construction site operation event recognition method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a construction site operation event identification method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a construction site operation event recognition system provided in an embodiment of the present invention. Detailed Implementation

[0015] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0016] Currently, in construction site safety management, smart safety helmets have one-click alarm or automatic fall alarm functions, but they have the following problems: (1) High false alarm rate: Simple acceleration or posture detection can easily misjudge workers resting, leaning, or sliding as falls or accidents, resulting in the background receiving frequent invalid alarms. (2) Delayed verification: Alarm information is usually sent to a remote cloud platform and verified by manual remote monitoring, resulting in a long response time. (3) Low rescue efficiency: Traditional distress notifications are usually broadcast to everyone or managers, which cannot automatically guide the nearest worker to provide immediate rescue.

[0017] In addition, construction sites are temporary, and there are both reused and newly purchased cameras. The models and configurations of the cameras vary, and there are differences in whether they have a pan-tilt unit or built-in AI detection capabilities. Moreover, using a single camera to detect people falling can lead to false alarms or lack of support.

[0018] The present invention first provides a method for identifying construction site operation events, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0019] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a construction site operation event recognition method provided in an embodiment of the present invention. Figure 1As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0020] See Figure 2 The present invention provides a method for identifying construction site operation events, which may include the following steps: S201, Event Triggering and Dynamic Agent Reporting: Based on the smart safety helmet detecting a person falling, it is determined whether the number of surrounding cameras meets a preset threshold. If not, a dynamic communication agent selection mechanism is activated. Based on a dynamically adjusted RSSI threshold range, qualified worker safety helmets are selected as relays, and the agents report distress messages to remote cameras to fill the gap in camera count. The RSSI threshold range is used to eliminate redundant workers with overlapping viewpoints due to excessively strong signals and workers with unstable communication links due to excessively weak signals. Specifically, the event triggering and dynamic agent reporting includes: Fall detection: Based on the built-in accelerometer of the smart safety helmet, a sudden acceleration is detected and the worker is then brought to a standstill, indicating that a fall may have occurred. Surrounding camera scanning: Triggered by an event, the distress helmet automatically scans for nearby Bluetooth signals, identifies surrounding cameras, and obtains their device IDs; Camera count determination: Compare the number of scanned cameras with the preset number. If the number is less than the preset number, proceed to the step of scanning safety helmets and collecting information; otherwise, proceed to the step of reporting directly. Worker safety helmet scanning and information collection: In the event of insufficient number of cameras, the distress helmet scans the surrounding Bluetooth signals to identify the worker's safety helmet, obtains the RSSI value of each worker's safety helmet and the information of the surrounding supplementary cameras, and generates a table of supplementary camera information around the worker's safety helmet; Dynamic RSSI threshold range calculation: Based on the number of camera gaps, the number of available worker safety helmets, and the number of cameras that each worker safety helmet can supplement, a reasonable RSSI threshold range [R1, R2] is dynamically calculated. R1 is the communication stability threshold, used to remove worker safety helmets with too weak RSSI, and R2 is the coverage redundancy threshold, used to remove worker safety helmets with too strong RSSI. By verifying and correcting the RSSI threshold range, it is ensured that the total number of cameras that worker safety helmets falling within the range can supplement meets the number of camera gaps, thus obtaining a candidate agent worker safety helmet list. Communication proxy node selection and proxy reporting: Based on the list of candidate worker safety helmets, prioritize the worker safety helmet with an RSSI value closer to R2 and that can fill the gap in the camera as the communication proxy node, and use Bluetooth to instruct its proxy to report the distress message to the remote camera; Direct reporting: Based on events where the number of cameras meets a preset threshold, the distress helmet establishes a Bluetooth connection with each camera detected by direct scanning and directly reports a distress message via Bluetooth.

[0021] S202, Multicast Group Establishment and Initial Visual Verification: All cameras that received the distress message automatically join the multicast group. Cameras equipped with pan-tilt units (PTZs) adjust their pan-tilt positions according to the distress coordinates and perform initial visual verification based on their capabilities, generating a multicast message containing verification confirmation, verification rejection, or verification failure results. Specifically, the multicast group establishment and initial visual verification include: Multicast group joining: Record the distress information based on all cameras that received the distress message, including the event ID, distress helmet ID, distress location coordinates, and a list of worker helmet IDs near the distress helmet, and automatically join multicast group G for multicast communication; Gimbal turning control: Based on the camera equipped with a gimbal, the camera's own installation position coordinates, installation height, and the worker's distress call coordinates, the camera calculates the azimuth and pitch angles to determine whether the distress call location is within the line of sight. If so, the camera drives the gimbal to turn and align with the distress call coordinates. Initial visual verification classification response: Classify and process according to the camera's own capabilities: Cameras with AI detection algorithms that can make judgments perform human detection and posture recognition, and send a verification confirmation or verification rejection message to multicast group G; Cameras without AI detection algorithms or with AI detection algorithms but unable to make judgments due to their own reasons send an unverifiable message to multicast group G, carrying a compressed captured image; Cameras with AI detection algorithms but unable to make judgments due to external reasons are not processed.

[0022] S203, Distributed Collaborative Computing Power Proxy Verification: Based on the unverifiable message received by the camera equipped with the AI ​​detection algorithm, distributed collaborative detection is performed on the unverifiable image through cache hierarchical management including a degraded storage strategy, priority random timer competition associated with the camera status, and a proxy detection list mechanism, generating a verification confirmation or verification rejection proxy message; specifically, the distributed collaborative computing power proxy verification includes: Cache hierarchical management: Based on the unverifiable multicast messages received by cameras with AI detection algorithms, the first message to arrive with the same event ID is processed first, and the remaining messages are temporarily stored in the cache. If the free space in the cache is less than the threshold, subsequent messages will only store the event ID, the distress helmet ID, and the unconfirmed camera ID, and will not store compressed images to save storage space. Priority Random Timer Competition: Random timers of different priorities are started based on the camera's own state to participate in the competition for the proxy detection task: Cameras that have not turned and have AI detection algorithms start a random timer with a preset high priority time range, while cameras that have turned and have AI detection algorithms start a random timer with a preset second priority time range. Computing power proxy detection execution: AI analysis is performed on the cached images based on the camera whose timeout expires first. If a determination is made, a verification confirmation or verification rejection proxy message is sent to multicast group G on behalf of the original camera. Update the proxy detection list: After the proxy is executed based on the proxy camera, the mapping pair of event ID and proxied camera ID is stored in the local proxy detection list; after other cameras receive the proxy results, the associated timer is canceled and the mapping pair is also stored to avoid duplicate processing; Continuous processing of cached messages: After processing all current messages from all cameras, check the cache area and delete processed messages. If there are still unprocessed messages in the cache and they are not in the proxy detection list, repeat the priority random timer competition and computing power proxy detection execution steps. Image Request and Retransmission: If a camera detects that a compressed image is not stored when processing cached messages, it sends a detection image request message to multicast group G; if other cameras find a cached image, they unicast a retransmission and send a response message to avoid duplicate requests.

[0023] S204, Collaborative Decision-Making and Tiered Rescue Response: Based on all verified messages collected by the temporary decision-maker, the confidence level of the distress call is calculated. When the confidence level reaches a preset threshold, a rescue request from a fellow worker is triggered. The frequency of audible and visual alarms is dynamically adjusted based on an equivalent rescue distance index generated by fusing the distress call confidence level with the distance to the rescuing worker, providing tiered guidance to responding workers and achieving the construction of a dynamic rescue network. Specifically, the collaborative decision-making and tiered rescue response includes: Provisional decision-maker determination: Based on each event ID, the first camera to send a verification confirmation or verification rejection multicast message becomes the provisional decision-maker associated with that event ID; SOS confidence calculation: Based on the temporary decision-maker's listening to verification messages of the same event sent by other cameras, if no new messages are received within a preset time, the percentage of verified confirmation messages is calculated as the SOS confidence E; Rescue request triggered: Based on the rescue confidence level E being greater than or equal to a preset threshold, the temporary decision-maker sends a coworker rescue request message to multicast group G, which includes the event ID, the rescue helmet ID, the rescue location coordinates, the rescue confidence level, and a list of coworker safety helmet IDs near the rescue helmet; Dynamic rescue network construction: Based on all cameras that have received rescue request messages, scan the surrounding safety helmets via Bluetooth, prioritize establishing a connection with the safety helmets in the list of safety helmet IDs of coworkers near the safety helmet in distress and send a distress message, and then send it to the remaining safety helmets; Tiered response and dynamic guidance: The straight-line distance D between the worker and the coordinates of the distress call is calculated based on the worker's safety helmet after receiving the distress message. Combined with the distress call confidence level E, the equivalent rescue distance D / E is obtained. Tiered response is performed according to the preset distance threshold, triggering audible and visual alarms of different frequencies, and the response is adjusted in real time as the rescuers move.

[0024] Furthermore, the method also includes a two-stage collaborative decision-making mechanism based on multi-dimensional credibility weights of camera physical location and visual quality: Single camera credibility weight calculation: Based on the camera's own physical location factor and visual quality factor, the credibility weight W of the single camera is dynamically calculated in real time when the camera sends a verification confirmation or verification rejection message. The physical location factor includes distance factor and angle factor, and the visual quality factor includes image quality factor and occlusion factor. AI-free camera weight transfer and completion: When a camera without AI detection algorithm sends an unverifiable message, it calculates and carries a physical location factor. The subsequent proxy detection camera combines the received physical location factor with the visual quality factor obtained from its own analysis during proxy detection to complete and calculate the final single-camera judgment credibility weight W of the proxy camera. The first stage is high-confidence rapid decision-making: Based on the verification messages sent by other cameras collected by the temporary decision-maker, high-confidence messages with a single camera's judgment confidence weight W greater than the first threshold are selected. The first round of distress call confidence E1 is calculated based on the weight of these messages. If E1 is greater than or equal to the distress call confidence threshold, the rescue request is triggered in advance. The second stage is a routine decision-making process with low confidence: if the confidence threshold for distress is not reached according to the first round of calculation, then the collaborative decision-making and tiered rescue response are carried out according to the steps, all verified messages are collected to calculate the confidence level E for distress, and the rescue request is determined based on E.

[0025] This application constructs a decentralized collaborative method and system for reporting, verifying, and guiding rescue operations for worker distress calls, based on smart safety helmets and heterogeneous cameras on construction sites. This overcomes the shortcomings of existing technologies, such as high false alarm rates due to reliance on single sensor data, slow verification responses due to centralized cloud processing, and inefficient and indiscriminate rescue notifications. The system aims to achieve low false alarm rates, low latency, high reliability, and high accuracy in construction site rescue responses. Specific technical solutions include: (I) Core Idea: After detecting a worker's fall, the smart safety helmet seeks further verification of the incident through image detection from several nearby cameras. If the number of nearby cameras is insufficient, a dynamic communication proxy selection mechanism is activated based on the RSSI threshold range of the worker's safety helmet's Bluetooth received signal. Helmets with excessively strong signals are eliminated to reduce potential overlap and redundancy, while those with excessively weak signals are eliminated to reduce the risk of communication link instability. Finally, a safety helmet with moderate signal strength is selected as the relay to relay the distress message to a sufficient number of nearby cameras to expand visual coverage.

[0026] Then, the panning cameras with gimbals perform initial visual verification based on their own capabilities and internal / external reasons. Cameras with AI detection algorithms that can make a judgment are directly detected and sent a verification confirmation message or a verification rejection message via multicast. Cameras without AI detection algorithms or with AI detection algorithms but unable to make a judgment due to their own reasons send an unverifiable message via multicast, carrying the unconfirmed camera ID (i.e., its own camera ID, which is also the ID of the camera to be proxied), the unverifiable result, and a compressed captured image, in order to seek computing power to proxy detection. Cameras with AI detection algorithms but unable to make a judgment due to external reasons are not processed.

[0027] Next, cameras equipped with AI detection algorithms perform distributed collaborative proxy verification through "tiered cache management + priority random timer competition + proxy detection list". Tiered cache management means that for the same event ID, if a camera receives multiple "unverifiable" multicast messages from different cameras, the first arriving message is processed first, and the remaining messages are temporarily stored in the cache. If the camera receives messages containing other different event IDs, all other messages are also stored in the cache. If the cache's free space is less than a threshold, subsequent messages only store the event ID, the distress helmet ID, and the unconfirmed camera ID, without storing compressed images, thus saving space and solving the camera cache resource bottleneck problem.

[0028] The priority random timer refers to the system where cameras that have not been turned and have AI detection algorithms (indicating that they have available resources and can be processed first) start a random timer with a preset high priority time range (e.g., 1-5 seconds); cameras that have been turned and have AI detection algorithms (which have their own detection tasks and are processed second priority) start a random timer with a preset second priority time range (e.g., 5-10 seconds). This allows the former cameras to be identified as proxy detection cameras first, while the latter are handled as a fallback.

[0029] The "Proxy Detection List" refers to the list where, after a proxy camera performs a proxy task, it stores the mapping pair between the event ID and the proxy camera ID in its local "Proxy Detection List" and multicasts the corresponding verification confirmation or verification rejection proxy message. Other cameras, upon receiving the proxy result multicast message, cancel the associated timer and store the mapping pair in their local "Proxy Detection List," thereby avoiding duplicate processing of images that have already been proxied.

[0030] For each event ID, the first camera to send a verification confirmation or verification rejection multicast message (based on a comparison of the timestamps of other multicast messages of this type received with its own sent message timestamp) becomes the temporary decision-maker (associated with the event ID). The temporary decision-maker listens to verification result messages or proxy messages (both verification confirmation and verification rejection) sent by other cameras via multicast, and then calculates the proportion of verification confirmation messages to obtain the distress call confidence level E. When the confidence level is greater than a threshold, the temporary decision-maker multicasts a notification to all cameras, which then further notify nearby workers' safety helmets via Bluetooth. The workers' safety helmets then combine this confidence level with the real-time distance to the worker in distress to generate an equivalent rescue distance index. Based on this, a hierarchical response rescue network is dynamically constructed, enabling real-time adjustment of the frequency of audible and visual alarms.

[0031] Further improvements include the introduction of a two-stage collaborative decision-making mechanism based on multi-dimensional confidence weights derived from camera physical location and visual quality. This mechanism calculates multi-dimensional factors such as distance, angle, image quality, and occlusion in real-time using the camera and constructs dynamic weights (for cameras without AI detection algorithms, only the physical location factor is transmitted; the proxy detection camera calculates the visual quality factor and completes the final weights). Based on these weights, high-confidence votes are processed quickly, while low-confidence votes are handled through a standard fallback process, significantly reducing decision-making delays while ensuring accuracy.

[0032] This solution, through the aforementioned decentralized and self-organizing edge-to-edge collaboration approach, addresses the issues of high false alarm rates, delayed verification, and blind rescue in existing technologies, significantly improving the emergency response speed and rescue success rate at construction sites.

[0033] (II) Complete technical implementation process: Prerequisites: 1. The smart safety helmet worn by workers integrates a main control computing module (including a processor and memory), an accelerometer sensor module, a Bluetooth communication module, and a Beidou positioning module. The main control computing module is responsible for data processing and logical operations; the accelerometer sensor monitors the wearer's movement in real time to trigger events; the Bluetooth module scans surrounding devices, measures the Bluetooth signal strength (RSSI), and performs data exchange; and the Beidou positioning module obtains the wearer's real-time geographical coordinates. All of these modules are powered by a built-in power supply module.

[0034] 2. All cameras on the construction site are connected to the site's IP network. Camera types include smart cameras with built-in AI detection algorithms and ordinary cameras with only basic video capture functions. These cameras may or may not have pan-tilt-zoom (PTZ) mechanisms, and all cameras support multicast communication protocols and image data upload capabilities.

[0035] 3. The camera's latitude and longitude coordinates and installation height information should be pre-entered during configuration.

[0036] 4. The cameras on the construction site are equipped with communication modules (such as Bluetooth modules or Bluetooth beacons / gateways associated with the cameras) to continuously broadcast their device ID and status information.

[0037] 5. All smart helmets will periodically scan surrounding cameras and broadcast summary information of surrounding devices via Bluetooth broadcast packets.

[0038] Complete process: 1. Event Triggering and Initial Reporting: The smart safety helmet detects sudden acceleration changes and subsequent stasis using a built-in accelerometer, indicating a potential fall or other accident. The helmet (hereinafter referred to as the distress helmet) then automatically scans nearby Bluetooth signals to identify cameras. If there are fewer than a preset number of cameras (e.g., 5), the distress helmet will, in addition to directly reporting a distress message to the nearby cameras, further activate a dynamic communication proxy selection mechanism to seek suitable fellow worker helmets as relay nodes to connect with more distant cameras and supplement the missing cameras compared to the preset number. If there are at least a preset number of nearby cameras, the distress helmet can directly report a distress message to the nearby cameras without activating the dynamic communication proxy selection mechanism. Calling for help requires requesting a predetermined number of cameras for two reasons: First, multiple cameras are needed to verify the fall incident. A single camera may give false alarms, and a small number of cameras may not support AI detection algorithms such as human detection and posture recognition, lack a gimbal or have angle issues preventing them from turning towards the incident location, or have obstructed images, thus failing to identify the fall. Therefore, a certain number of cameras are needed to ensure verification. Second, after multiple cameras have verified and confirmed the incident, nearby coworkers need to be notified to provide assistance. If there are only one or a few cameras, there is a risk that there may be few or no coworkers nearby, which could hinder the rescue.

[0039] The distress helmet is categorized into two cases based on the number of nearby cameras directly detected, as detailed below: (1) If there are fewer than the preset number of nearby cameras (e.g., 5): The distress helmet should be reported directly, and a dynamic communication agent selection mechanism should be activated. The specific steps are as follows: 1) Report directly: The distress helmet immediately establishes a Bluetooth connection with each nearby camera detected by the direct scan, and reports a distress message directly via Bluetooth. The message includes a globally unique event ID (generated by the distress helmet ID and the timestamp of the detected fall), the distress helmet ID, the distress location coordinates, and a list of fellow workers' distress helmet IDs near the distress helmet.

[0040] 2) Dynamic communication agent selection and agent reporting: The distress helmet scans surrounding Bluetooth signals to identify fellow workers' helmets; then it sorts the Bluetooth signal strength (RSSI) of all fellow workers' helmets in descending order; next, by parsing the "list of nearby camera IDs" carried in the Bluetooth broadcast packet of each worker's helmet, it removes camera IDs that it has already directly scanned, forming a supplementary camera information table around each worker's helmet, which includes the worker's helmet ID, its RSSI value, and a list of camera IDs in its vicinity that are not directly connected to by the distress helmet.

[0041] Then, the distress helmet dynamically calculates a reasonable RSSI threshold range [R1, R2] based on the current number of camera gaps (i.e., the preset number minus the actual number), the number of available worker helmets, and the number of cameras that each worker helmet can supplement. Here, R1 is the communication stability threshold and R2 is the coverage redundancy threshold. The calculation principles include: ① Excluding those with excessively high RSSI (e.g., excluding cameras in the top 20% of RSSI ranking, this threshold can be dynamically adjusted based on the total number of safety helmets and the number of gaps: if the total number is high and the number of gaps is small, the threshold can be increased; conversely, it can be decreased), because their distance is too close, the camera detected by the safety helmet may highly overlap with the camera detected by the safety helmet in distress, leading to duplicate communication links for the same camera, resulting in wasted resources and potential data conflicts. Based on this, the upper limit reference value of R2 is initially determined; ② Excluding those with excessively low RSSI (e.g., excluding cameras in the bottom 30% of ranking, this threshold can also be dynamically adjusted), because their communication links are unstable and the associated cameras may be too far away, posing a risk of unclear images or ineffective coverage. Based on this, the lower limit reference value of R1 is initially determined; ③ Combining the number of camera gaps, the interval width is dynamically adjusted to ensure that the total number of cameras that safety helmets with RSSI falling within [R1, R2] can supplement is not less than the number of gaps, thereby maximizing the expansion of visual coverage while ensuring communication quality. The specific calculation method is as follows: ① Sort all the scanned safety helmet RSSI values ​​in descending order. ② Determine R2 (coverage redundancy threshold): Eliminate the top X% of excessively strong nodes (due to their highly overlapping coverage), and use the RSSI value at the X% quantile as the upper limit reference value of R2. The value of X can be dynamically adjusted according to the number of camera gaps: the smaller the gap, the larger X can be appropriately increased to more aggressively eliminate redundancy. ③ Determine R1 (communication stability threshold): Eliminate the bottom Y% of excessively weak nodes (due to their unstable links), and use the RSSI value at the (100-Y)% quantile as the lower limit reference value of R1. The value of Y is dynamically adjusted according to the communication environment: when there is a lot of environmental interference, Y can be decreased to relax the signal strength requirements. ④ Thus, the RSSI interval [R1, R2] of the candidate agents is obtained. ⑤ Verification and correction: Calculate the total number of cameras that the safety helmets of workers falling within the [R1, R2] interval can supplement. If this total number is less than the current number of gaps, dynamically adjust X or Y (for example, appropriately decrease X to expand the upper limit, or decrease Y to widen the lower limit) until the gap requirements are met, thereby achieving a balance between ensuring communication quality and avoiding redundancy.

[0042] Ultimately, the distress helmet prioritizes helmets with RSSI values ​​closer to R2 (i.e., better signal) from among those within the dynamic range [R1, R2], selecting those that can fill the gap in the camera's signal and serve as communication proxy nodes. If the number of helmets meeting these criteria is less than the number of gaps, all are selected. The distress helmet then uses Bluetooth to instruct these selected helmets to act as relay nodes, connecting to nearby cameras and relaying distress messages. These messages include the same event ID, the distress helmet ID, the distress location coordinates, and a list of nearby helmet IDs.

[0043] (2) If the number of nearby cameras is greater than or equal to the preset number: The distress helmet only needs to establish a Bluetooth connection with each camera detected by direct scanning, and report the distress message directly via Bluetooth. The message content includes the event ID, distress helmet ID, distress location coordinates, and a list of worker helmet IDs near the distress helmet, without needing to start an agent selection process.

[0044] 2. Multicast group establishment and spatial positioning: All nearby cameras that receive the distress message (including direct distress and proxy distress) record the distress information (including event ID, distress helmet ID, distress location coordinates, and a list of worker helmet IDs near the distress helmet) and automatically join multicast group G to communicate with other cameras via multicast.

[0045] Each camera with a pan-tilt unit (including those with and without AI detection algorithms) calculates its azimuth and pitch angles based on its known installation coordinates, installation height, and the worker's distress call coordinates to determine if the distress location is within its line of sight. If within sight, the camera drives the pan-tilt unit to turn, aiming the lens in the approximate direction of the distress call coordinates; if outside sight or without a pan-tilt unit, it remains in its original position.

[0046] 3. Initial visual verification and classification response: Initial visual verification of pan-tilt-zoom (PTZ) cameras, categorized based on their own capabilities and internal / external factors: (1) Cameras with AI detection algorithms and capable of making judgments perform human body detection and posture recognition in the central area of ​​the image. If a fallen person is detected, a verification confirmation message is sent to multicast group G, containing the corresponding event ID, the distress helmet ID, the camera ID, and the verification confirmation result; if no abnormality is detected, a verification rejection message is sent to multicast group G, containing the corresponding event ID, the distress helmet ID, the camera ID, and the verification rejection result.

[0047] (2) Cameras without AI detection algorithms or those with AI detection algorithms but unable to be judged due to their own reasons (such as limited accuracy of camera algorithms, excessive computing load, etc.) send an unverifiable message to multicast group G. The message includes the corresponding event ID, the distress helmet ID, the unconfirmed camera ID (i.e., its own camera ID, which is also the camera ID to be proxied), the unverifiable result, and the compressed captured image, in order to seek computing power proxy detection.

[0048] (3) Cameras with AI detection algorithms that cannot be identified due to external factors (such as people obstructing the view in the image) will not be processed. This is because if the inability to identify the image is due to external factors, even if the image is sent to other cameras, they will not be able to see it clearly. Therefore, these cameras will be skipped to save communication and computing resources.

[0049] 4. Distributed collaborative computing power agent verification mechanism: All cameras that have joined multicast group G and have built-in AI detection algorithms should handle "unverifiable" multicast messages as follows: (1) Camera messages are cached on demand: For the same event ID, if a camera receives multiple "unverifiable" multicast messages from different cameras, the first message to arrive will be processed first, and the remaining messages will be temporarily stored in the buffer.

[0050] If the camera receives messages containing other different event IDs, all other messages will also be stored in the buffer. If the buffer's free space is less than a threshold (e.g., 15%), then for subsequent received messages, only the event ID, the distress helmet ID, and the unconfirmed camera ID information will be stored; compressed images will not be stored to save space.

[0051] (2) The camera participates in the competition for computing power agent detection tasks based on its own status: 1) Cameras that are not turned and have AI detection algorithms (indicating that there are idle resources and can be prioritized): Start a preset high-priority time range (e.g., 1-5 seconds) random timer, which is associated with the event ID and the ID of the camera to be proxied.

[0052] 2) Cameras that have turned and have AI detection algorithms (which have their own detection tasks, are processed with secondary priority to achieve fallback operations, such as for cases where there are no cameras that have not turned and have AI detection algorithms): Start a preset secondary priority time range (e.g., 5-10 seconds) random timer (also associated with the event ID and the ID of the camera to be proxied).

[0053] (3) Detection of computing power proxy: First, cameras whose timeouts have expired undergo a computing power proxy detection process, performing AI analysis on the received compressed image. If a decision can be made (confirmation or rejection), the corresponding verification confirmation or rejection proxy message (including event ID, distress helmet ID, proxy camera ID, proxied camera ID, and verification confirmation / rejection result) is sent to multicast group G instead of the original unconfirmed camera. If a decision cannot be made (potentially due to internal or external reasons), no action is taken. (Note: If a decision cannot be made, the next camera whose timeout has expired will undergo computing power proxy detection, and so on. In an extreme case, if all cameras whose timeouts have expired cannot be determined, no multicast message will be sent, and the image will not be considered during collaborative decision-making in step 5.)

[0054] (4) Update the list of proxied detections: After performing proxying, the proxy camera stores the mapping pair of event IDs and proxied camera IDs in its local "Proxyed Detection List". Other cameras, upon receiving the proxy result multicast message, cancel their associated timers and store the mapping pair in their local "Proxyed Detection List". This list stores all event ID and proxied camera ID mapping pairs detected by itself and other proxied cameras to avoid duplicate processing of images already detected by proxy.

[0055] (5) Continuous computing power proxy detection: After all cameras have finished processing the current message, they check the cache area and delete the processed messages. If there are still unprocessed messages in the cache, and the mapping pair between the event ID and the proxy camera ID in the message is not in the local "proxy detection list", then repeat steps 4(2)-(4) until all relevant messages in the cache area have been processed.

[0056] When processing cached messages, for cameras that do not store compressed captured images, the camera sends a "Detect Image Request" message to multicast group G, containing the original event ID and the requesting camera ID (its own ID). Other cameras, upon receiving this multicast message, compare it to their local cache. If they match the event ID and contain a compressed image, they unicast the image to that camera and multicast a "Detect Image Request Response Completed" message (without a compressed image), containing the original event ID and the original requesting camera ID. This causes other cameras to ignore the original "Detect Image Request" message upon hearing it.

[0057] 5. Multi-camera collaborative decision-making: For each event ID, the system makes the following collaborative decisions: The first camera to send a verification confirmation or verification rejection multicast message (based on a comparison of the timestamps of other multicast messages of the same type received with its own sent message timestamp) becomes the temporary decision-maker (associated with the event ID).

[0058] The temporary decision maker listens to this type of multicast message from other cameras (including verification confirmation / verification rejection multicast messages, and verification confirmation / verification rejection proxy multicast messages). If no new such type of multicast message is received within the preset time (such as within 15 seconds) after listening to this type of multicast message (indicating that all verification messages have been sent, including those detected by the camera itself and the proxy), then calculate the proportion of verification confirmation messages (i.e., the number of verification confirmation messages / (the number of verification confirmation messages + the number of verification rejection messages), which is the distress confidence level E). If E is greater than or equal to the distress confidence threshold (such as 60%), it is determined as highly suspected of an accident; then a worker rescue request message is multicast to the multicast group G, including the event ID, the ID of the distress safety helmet, the distress location coordinates, the distress confidence level, and the list of IDs of the safety helmets of the workers near the distress safety helmet.

[0059] During the listening process, if the temporary decision maker receives a decision message with the same event ID sent by other cameras (such as a rescue request multicast message sent by another temporary decision maker), then compare the timestamps carried in the message, and the one with the later timestamp gives up the identity of the temporary decision maker to avoid conflicts.

[0060] 6. Dynamic rescue network construction: All cameras near the distress safety helmet and communication proxy cameras that receive the multicast packet of the worker rescue request message scan the surrounding safety helmets via Bluetooth to obtain a list of IDs of the safety helmets of the nearby workers.

[0061] The camera first sorts the scanned surrounding safety helmets according to the list of IDs of the safety helmets of the workers near the distress safety helmet it received; it preferentially establishes a connection with the safety helmets of the workers in the list via Bluetooth (because they are closer to the distressed person, and notifying for rescue first saves rescue time) and sends a distress message, the message content including the event ID, the ID of the distress safety helmet, the distress location coordinates, and the distress confidence level; afterwards, it sends distress information to each of the remaining safety helmets via Bluetooth.

[0062] 7. Hierarchical response and dynamic guidance: The safety helmet of the worker that receives the distress message calculates the straight-line distance (D) between its own coordinates and the distress coordinates and divides it by the distress confidence level (E) to obtain the equivalent rescue distance (D / E). It responds hierarchically according to the distance thresholds (D1, D2): If D / E <= D1, this worker is a high-priority responder, and the safety helmet triggers a high-frequency whistle and flashing; if D1 < D / E <= D2, this worker is a medium-priority responder, triggering a medium-frequency whistle and flashing; if D / E > D2, this worker is a low-priority responder, triggering a low-frequency whistle and flashing. As the rescue worker moves, the safety helmet of the worker dynamically updates the calculation of the equivalent rescue distance, and the whistle and flashing frequencies are adjusted in real time according to the change in the equivalent distance.

[0063] 8. Further improvements: A two-stage collaborative decision-making mechanism based on the multi-dimensional credibility weights of camera physical location and visual quality.

[0064] In step 5, "Multi-camera Collaborative Decision Making," the temporary decision-maker needs to receive all verification confirmation / rejection multicast messages and verification confirmation / rejection proxy multicast messages. Then, after waiting a preset time (e.g., within 15 seconds), the SOS confidence level E can be calculated. Only after determining a high likelihood of an accident can the SOS request message be multicast and sent. This process is time-consuming and hinders timely rescue in emergencies. A further improvement involves using cameras to calculate multi-dimensional factors such as distance, angle, image quality, and occlusion in real time and constructing dynamic weights (for cameras without AI detection algorithms, only the physical location factor is transmitted; the proxy detection camera calculates the visual quality factor and completes the final weights). Based on these weights, high-confidence votes are processed quickly, while low-confidence votes are handled by the regular process as a fallback, significantly reducing decision delay while ensuring accuracy. The specific steps are as follows: (1) In step 3, “Initial Visual Verification and Classification Response”, when the camera sends a verification confirmation message or a verification rejection message, it not only carries the verification confirmation or rejection result, but also calculates and carries the credibility weight W of the camera (typically ranging from 0 to 1). This weight W is not a preset static weight, but is dynamically calculated in real time based on the camera’s physical position (such as distance and angle) and visual quality (such as clarity and occlusion). It reflects the credible evidence value of the current camera for the current event, which is fundamentally different from the weight preset based on the voter’s identity in the general voting system. The credibility weight includes two categories: physical position factor and visual quality factor, as shown in the following examples (each factor ranges from 0 to 1): 1) Physical location factor: Distance factor (Wd): Calculated based on the distance between the camera and the distress coordinates. The closer the distance, the higher the weight.

[0065] Angle factor (Wa): Calculated based on the angle between the camera's optical axis and the location of the incident. The smaller the angle (the more directly opposite), the higher the weight.

[0066] 2) Visual quality factor: Image quality factor (Wq): Calculated based on the camera's own resolution or the sharpness score of the captured image.

[0067] Occlusion factor (Wo): If the camera detects that the main subject of the image is partially occluded, the weight is reduced.

[0068] The final single-camera judgment confidence weight W=f(Wd,Wa,Wq,Wo), with a typical calculation formula as follows: W = 0.3*Wd + 0.2*Wa + 0.3*Wq + 0.2*Wo.

[0069] (2) In step 3 “Initial visual verification and classification response”, when the camera sends a message that it cannot be verified, it adds the calculation and carries the camera’s judgment distance factor (Wd) and angle factor (Wa), and the subsequent agent detection camera will calculate the final single camera judgment confidence weight W.

[0070] (3) In step 4, “Distributed Collaborative Computing Power Proxy Verification Mechanism”, when the proxy detection camera sends verification confirmation or verification rejection proxy messages in place of the original unconfirmed camera, it combines the distance factor (Wd) and angle factor (Wa) transmitted by the proxy camera with its own image quality factor (Wq) and occlusion factor (Wo) obtained from image detection analysis, and also calculates and carries the single camera judgment credibility weight W.

[0071] (4) In step 5, “Multi-camera collaborative decision-making”, after the temporary decision-maker sends a verification confirmation or verification rejection multicast message, he collects multicast messages of the same type from other cameras (including verification confirmation / verification rejection multicast messages and verification confirmation / verification rejection proxy multicast messages) within a preset time (e.g., 5 seconds, much less than the original waiting time in step 5). Then, for messages in which the single camera’s judgment confidence weight W is greater than the threshold (e.g., 70%, greater than the original distress confidence threshold of 60%), the distress confidence E1 within the current preset time is calculated in the first round. E1 = (sum of weights of current confirmation messages) / (weight of current confirmation message + weight of current rejection message). If E1 is greater than or equal to the distress confidence threshold (e.g., 60%) (indicating high confidence and the ability to respond early), the temporary decision-maker will not wait to collect all multicast messages and will send the worker's distress request message via multicast in advance. If E1 is less than the distress confidence threshold, the distress confidence E will be calculated after collecting all multicast messages according to the original method in step 5. At this time, E = (the sum of the weights of all confirmed messages) / (the weights of all confirmed messages + the weights of all rejected messages). Based on E, it will be determined whether to send the worker's distress request message.

[0072] Beneficial effects: 1. Significantly reduce false alarm rate. By combining the acceleration sensing data of the safety helmet with multi-camera distributed collaborative visual verification, the single-dimensional "fall detection" is upgraded to a multi-dimensional, multi-angle "event fusion confirmation". This effectively filters out interfering behaviors such as leaning and sliding, making the judgment of the confidence of distress calls more scientific and reducing the false alarm rate.

[0073] 2. Reduce response latency. By building a decentralized network that enables direct collaboration between the "end" and the "edge," the event verification and decision-making process is moved from the cloud to the edge of the construction site. This avoids the long wait of uploading data to the cloud and manually retrieving monitoring data, thus saving valuable time for emergency rescue.

[0074] 3. Improve the accuracy and efficiency of rescue efforts. By using an equivalent rescue distance decision variable, the certainty of the event is integrated with the spatial proximity of rescue personnel, enabling intelligent classification and dynamic guidance of rescue personnel, thus avoiding the blindness of traditional broadcast notifications.

[0075] 4. Utilize existing equipment and reduce system costs. The solution fully considers the complex situation of construction site cameras with varying models and capabilities. Through a distributed collaborative mechanism, ordinary cameras can also participate in event verification by leveraging the computing power of smart cameras, thus realizing the reuse and empowerment of existing equipment.

[0076] New innovation point: 1. Intelligent relay selection mechanism. When there are not enough nearby cameras, instead of simply selecting the worker's safety helmet with the strongest signal as a communication proxy, a dynamic RSSI threshold range is introduced to select the worker's safety helmet with "moderate RSSI (between R1 and R2)". This can eliminate redundancy that is too close and eliminate unreliable safety helmets that are too far away, seeking a balance between communication quality and coverage breadth to effectively expand the camera coverage area.

[0077] 2. Distributed Collaborative Proxy Verification Mechanism. When multiple cameras without AI detection algorithms send unverifiable messages containing images, AI-enabled cameras achieve distributed collaborative computing power through "tiered cache management + priority random timer competition + already-proxyed detection list." Specifically, tiered cache management addresses the bottleneck of camera cache resources, the priority random timer identifies the preferred proxy detection camera and avoids conflicts, and the already-proxyed detection list prevents the same image from being analyzed by multiple cameras.

[0078] 3. Weighted Hierarchical Response Based on Demand Confidence. The demand confidence level (E) is calculated through multi-camera voting and then fused with the straight-line distance (D) to obtain the equivalent rescue distance (D / E). The frequency of audible and visual alarms is dynamically adjusted based on this. The equivalent rescue distance is not a physical distance, but a new decision variable that integrates the certainty of the event with spatial proximity.

[0079] 4. A two-stage collaborative decision-making mechanism based on multi-dimensional credibility weights of camera physical location and visual quality. The camera dynamically calculates the credibility weight W based on distance, angle, image quality, and occlusion factors. For cameras without AI, a method of "physical location factor transfer + proxy completion of visual quality factors" is used to construct the weights. The temporary decision-maker prioritizes high-weight messages for confidence calculation; if the threshold is met, rescue is triggered in advance; otherwise, all messages are processed and calculation is pending.

[0080] Another embodiment of the present invention provides a construction site operation event recognition system, see [link to relevant documentation]. Figure 3 The system may include: Trigger module 301 is used for event triggering and dynamic proxy reporting: based on the smart safety helmet detecting a person falling, it determines whether the number of surrounding cameras meets a preset threshold. If not, it activates a dynamic communication proxy selection mechanism, using dynamically adjusted RSSI threshold ranges to select qualified worker safety helmets as relays, and proxy reports distress messages to remote cameras to fill the gap in the number of cameras; wherein, the RSSI threshold range is used to eliminate redundant workers with overlapping viewpoints due to excessively strong signals and workers with unstable communication links due to excessively weak signals. Module 302 is used for multicast group establishment and initial visual verification: all cameras that receive the distress message are automatically added to the multicast group, cameras with pan-tilt units turn their pan-tilt units according to the distress coordinates, and perform initial visual verification according to their own capabilities, generating multicast messages containing verification confirmation, verification rejection or unverifiable results. Verification module 303 is used for distributed collaborative computing power proxy verification: based on the unverifiable message received by the camera with AI detection algorithm, the unverifiable image is subjected to distributed collaborative detection through cache hierarchical management including degradation storage strategy, priority random timer competition associated with camera status and proxy detection list mechanism, and a verification confirmation or verification rejection proxy message is generated. The decision module 304 is used for collaborative decision-making and tiered rescue response: Based on all verified messages collected by the temporary decision-maker, it calculates the confidence level of the distress call. When the confidence level reaches a preset threshold, it triggers the worker's rescue request. It also dynamically adjusts the frequency of the audible and visual alarms based on the equivalent rescue distance index generated by fusing the distress call confidence level with the distance to the rescue worker, and provides tiered guidance to the responding workers to realize the construction of a dynamic rescue network.

[0081] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0082] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0083] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0084] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for identifying construction site operation events, characterized in that, The method includes: Event Triggering and Dynamic Agent Reporting: Based on the smart safety helmet detecting a person falling, it determines whether the number of surrounding cameras meets a preset threshold. If not, a dynamic communication agent selection mechanism is activated. Based on a dynamically adjusted RSSI threshold range, qualified worker safety helmets are selected as relays, and agents report distress messages to remote cameras to fill the gap in the number of cameras. The RSSI threshold range is used to eliminate redundant workers with overlapping viewpoints due to excessively strong signals and workers with unstable communication links due to excessively weak signals. Multicast group establishment and initial visual verification: All cameras that receive the distress message are automatically added to the multicast group. Cameras with pan-tilt units turn their pan-tilt units according to the distress coordinates and perform initial visual verification according to their own capabilities, generating multicast messages containing verification confirmation, verification rejection, or verification failure results. Distributed collaborative computing power proxy verification: Based on the unverifiable message received by the camera with AI detection algorithm, the unverifiable image is subjected to distributed collaborative detection through cache hierarchical management including degraded storage strategy, priority random timer competition associated with camera status and proxy detection list mechanism, and a verification confirmation or verification rejection proxy message is generated. Collaborative decision-making and tiered rescue response: Based on all verified messages collected by the temporary decision-maker, the confidence level of the distress call is calculated. When the confidence level reaches a preset threshold, the worker's rescue request is triggered. The frequency of the audible and visual alarms is dynamically adjusted based on the equivalent rescue distance index generated by fusing the distress call confidence level with the distance to the worker in need, and the responding workers are guided in a tiered manner to achieve the construction of a dynamic rescue network.

2. The method according to claim 1, characterized in that, The event triggering and dynamic proxy reporting include: Fall detection: Based on the built-in accelerometer of the smart safety helmet, a sudden acceleration is detected and the worker is then brought to a standstill, indicating that a fall may have occurred. Surrounding camera scanning: Triggered by an event, the distress helmet automatically scans for nearby Bluetooth signals, identifies surrounding cameras, and obtains their device IDs; Camera count determination: Compare the number of scanned cameras with the preset number. If the number is less than the preset number, proceed to the step of scanning safety helmets and collecting information; otherwise, proceed to the step of reporting directly. Worker safety helmet scanning and information collection: In the event of insufficient number of cameras, the distress helmet scans the surrounding Bluetooth signals to identify the worker's safety helmet, obtains the RSSI value of each worker's safety helmet and the information of the surrounding supplementary cameras, and generates a table of supplementary camera information around the worker's safety helmet; Dynamic RSSI threshold range calculation: Based on the number of camera gaps, the number of available worker safety helmets, and the number of cameras that each worker safety helmet can supplement, a reasonable RSSI threshold range [R1, R2] is dynamically calculated. R1 is the communication stability threshold, used to remove worker safety helmets with too weak RSSI, and R2 is the coverage redundancy threshold, used to remove worker safety helmets with too strong RSSI. By verifying and correcting the RSSI threshold range, it is ensured that the total number of cameras that worker safety helmets falling within the range can supplement meets the number of camera gaps, thus obtaining a candidate agent worker safety helmet list. Communication proxy node selection and proxy reporting: Based on the list of candidate worker safety helmets, prioritize the worker safety helmet with an RSSI value closer to R2 and that can fill the gap in the camera as the communication proxy node, and use Bluetooth to instruct its proxy to report the distress message to the remote camera; Direct reporting: Based on events where the number of cameras meets a preset threshold, the distress helmet establishes a Bluetooth connection with each camera detected by direct scanning and directly reports a distress message via Bluetooth.

3. The method according to claim 2, characterized in that, The multicast group establishment and initial visual verification include: Multicast group joining: Record the distress information based on all cameras that received the distress message, including the event ID, distress helmet ID, distress location coordinates, and a list of worker helmet IDs near the distress helmet, and automatically join multicast group G for multicast communication; Gimbal turning control: Based on the camera equipped with a gimbal, the camera's own installation position coordinates, installation height, and the worker's distress call coordinates, the camera calculates the azimuth and pitch angles to determine whether the distress call location is within the line of sight. If so, the camera drives the gimbal to turn and align with the distress call coordinates. Initial visual verification classification response: Classify and process according to the camera's own capabilities: Cameras with AI detection algorithms that can make judgments perform human detection and posture recognition, and send a verification confirmation or verification rejection message to multicast group G; Cameras without AI detection algorithms or with AI detection algorithms but unable to make judgments due to their own reasons send an unverifiable message to multicast group G, carrying a compressed captured image; Cameras with AI detection algorithms but unable to make judgments due to external reasons are not processed.

4. The method according to claim 3, characterized in that, The distributed collaborative computing power agent verification includes: Cache hierarchical management: Based on the unverifiable multicast messages received by cameras with AI detection algorithms, the first message to arrive with the same event ID is processed first, and the remaining messages are temporarily stored in the cache. If the free space in the cache is less than the threshold, subsequent messages will only store the event ID, the distress helmet ID, and the unconfirmed camera ID, and will not store compressed images to save storage space. Priority Random Timer Competition: Random timers of different priorities are started based on the camera's own state to participate in the competition for the proxy detection task: Cameras that have not turned and have AI detection algorithms start a random timer with a preset high priority time range, while cameras that have turned and have AI detection algorithms start a random timer with a preset second priority time range. Computing power proxy detection execution: AI analysis is performed on the cached images based on the camera whose timeout expires first. If a determination is made, a verification confirmation or verification rejection proxy message is sent to multicast group G on behalf of the original camera. Update the proxy detection list: After the proxy is executed based on the proxy camera, the mapping pair of event ID and proxied camera ID is stored in the local proxy detection list; after other cameras receive the proxy results, the associated timer is canceled and the mapping pair is also stored to avoid duplicate processing; Continuous processing of cached messages: After processing all current messages from all cameras, check the cache area and delete processed messages. If there are still unprocessed messages in the cache and they are not in the proxy detection list, repeat the priority random timer competition and computing power proxy detection execution steps. Image Request and Retransmission: If a camera detects that a compressed image is not stored when processing cached messages, it sends a detection image request message to multicast group G; if other cameras find a cached image, they unicast a retransmission and send a response message to avoid duplicate requests.

5. The method according to claim 4, characterized in that, The collaborative decision-making and tiered rescue response include: Provisional decision-maker determination: Based on each event ID, the first camera to send a verification confirmation or verification rejection multicast message becomes the provisional decision-maker associated with that event ID; SOS confidence calculation: Based on the temporary decision-maker's listening to verification messages of the same event sent by other cameras, if no new messages are received within a preset time, the percentage of verified confirmation messages is calculated as the SOS confidence E; Rescue request triggered: Based on the rescue confidence level E being greater than or equal to a preset threshold, the temporary decision-maker sends a coworker rescue request message to multicast group G, which includes the event ID, the rescue helmet ID, the rescue location coordinates, the rescue confidence level, and a list of coworker safety helmet IDs near the rescue helmet; Dynamic rescue network construction: Based on all cameras that have received rescue request messages, scan the surrounding safety helmets via Bluetooth, prioritize establishing a connection with the safety helmets in the list of safety helmet IDs of coworkers near the safety helmet in distress and send a distress message, and then send it to the remaining safety helmets; Tiered response and dynamic guidance: The straight-line distance D between the worker and the coordinates of the distress call is calculated based on the worker's safety helmet after receiving the distress message. Combined with the distress call confidence level E, the equivalent rescue distance D / E is obtained. Tiered response is performed according to the preset distance threshold, triggering audible and visual alarms of different frequencies, and the response is adjusted in real time as the rescuers move.

6. The method according to claim 5, characterized in that, The method also includes a two-stage collaborative decision-making mechanism based on multi-dimensional credibility weights of camera physical location and visual quality: Single camera credibility weight calculation: Based on the camera's own physical location factor and visual quality factor, the credibility weight W of the single camera is dynamically calculated in real time when the camera sends a verification confirmation or verification rejection message. The physical location factor includes distance factor and angle factor, and the visual quality factor includes image quality factor and occlusion factor. AI-free camera weight transfer and completion: When a camera without AI detection algorithm sends an unverifiable message, it calculates and carries a physical location factor. The subsequent proxy detection camera combines the received physical location factor with the visual quality factor obtained from its own analysis during proxy detection to complete and calculate the final single-camera judgment credibility weight W of the proxy camera. The first stage is high-confidence rapid decision-making: Based on the verification messages sent by other cameras collected by the temporary decision-maker, high-confidence messages with a single camera's judgment confidence weight W greater than the first threshold are selected. The first round of distress call confidence E1 is calculated based on the weight of these messages. If E1 is greater than or equal to the distress call confidence threshold, the rescue request is triggered in advance. The second stage is a routine decision-making process with low confidence: if the confidence threshold for distress is not reached according to the first round of calculation, then the collaborative decision-making and tiered rescue response are carried out according to the steps, all verified messages are collected to calculate the confidence level E for distress, and the rescue request is determined based on E.

7. A construction site operation event recognition system, characterized in that, The system includes: The triggering module is used for event triggering and dynamic proxy reporting: based on the smart safety helmet detecting a person falling, it determines whether the number of surrounding cameras meets a preset threshold. If not, it activates a dynamic communication proxy selection mechanism, using dynamically adjusted RSSI threshold ranges to select qualified worker safety helmets as relays, and proxy reports distress messages to remote cameras to fill the gap in the number of cameras; wherein, the RSSI threshold range is used to eliminate redundant workers whose viewpoints overlap due to excessively strong signals and workers whose communication links are unstable due to excessively weak signals; The module is used for multicast group establishment and initial visual verification: all cameras that receive the distress message are automatically added to the multicast group. Cameras with pan-tilt units turn their pan-tilt units according to the distress coordinates and perform initial visual verification according to their own capabilities, generating multicast messages containing verification confirmation, verification rejection or verification failure results. The verification module is used for distributed collaborative computing power proxy verification: based on the unverifiable message received by the camera with AI detection algorithm, the unverifiable image is detected in a distributed collaborative manner through cache hierarchical management including degraded storage strategy, priority random timer competition associated with camera status and proxy detection list mechanism, and a verification confirmation or verification rejection proxy message is generated. The decision-making module is used for collaborative decision-making and tiered rescue response: Based on all verified messages collected by the temporary decision-maker, the confidence level of the distress call is calculated. When the confidence level reaches a preset threshold, the worker's rescue request is triggered. The frequency of the audible and visual alarms is dynamically adjusted based on the equivalent rescue distance index generated by fusing the distress call confidence level and the distance to the worker in need, and the responding workers are guided in a tiered manner to realize the construction of a dynamic rescue network.

8. The system according to claim 7, characterized in that, The triggering module is specifically used for: Fall detection: Based on the built-in accelerometer of the smart safety helmet, a sudden acceleration is detected and the worker is then brought to a standstill, indicating that a fall may have occurred. Surrounding camera scanning: Triggered by an event, the distress helmet automatically scans for nearby Bluetooth signals, identifies surrounding cameras, and obtains their device IDs; Camera count determination: Compare the number of scanned cameras with the preset number. If the number is less than the preset number, proceed to the step of scanning safety helmets and collecting information; otherwise, proceed to the step of reporting directly. Worker safety helmet scanning and information collection: In the event of insufficient number of cameras, the distress helmet scans the surrounding Bluetooth signals to identify the worker's safety helmet, obtains the RSSI value of each worker's safety helmet and the information of the surrounding supplementary cameras, and generates a table of supplementary camera information around the worker's safety helmet; Dynamic RSSI threshold range calculation: Based on the number of camera gaps, the number of available worker safety helmets, and the number of cameras that each worker safety helmet can supplement, a reasonable RSSI threshold range [R1, R2] is dynamically calculated. R1 is the communication stability threshold, used to remove worker safety helmets with too weak RSSI, and R2 is the coverage redundancy threshold, used to remove worker safety helmets with too strong RSSI. By verifying and correcting the RSSI threshold range, it is ensured that the total number of cameras that worker safety helmets falling within the range can supplement meets the number of camera gaps, thus obtaining a candidate agent worker safety helmet list. Communication proxy node selection and proxy reporting: Based on the list of candidate worker safety helmets, prioritize the worker safety helmet with an RSSI value closer to R2 and that can fill the gap in the camera as the communication proxy node, and use Bluetooth to instruct its proxy to report the distress message to the remote camera; Direct reporting: Based on events where the number of cameras meets a preset threshold, the distress helmet establishes a Bluetooth connection with each camera detected by direct scanning and directly reports a distress message via Bluetooth.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images