Recording control method, device, system and program product for fusion trigger event

Abstract

The present disclosure relates to a recording control method, device, system and program product for fusing trigger events, which is used for XR robot demonstration collection business, the method comprising: obtaining trigger events corresponding to a collection environment collected by a collector, converting trigger events of different sources into the same recording trigger mode through a trigger fusioner; establishing a unified trigger entrance, calling a switching recording instruction, and inputting the recording trigger mode into the switching recording instruction; in response to meeting a business gate, mapping the trigger event to a state machine through the unified trigger entrance, and based on the current state of the state machine, controlling whether to record, wherein the business gate is a prerequisite check condition for the trigger event to take effect. The present disclosure effectively solves the problem of data mismatch caused by repeated operations by establishing a unified trigger entrance for trigger events of different sources and using a business gate and a state machine anti-jitter mechanism, thereby improving the stability and consistency of data collection.

Description

Technical Field

[0001] This disclosure relates to the field of data acquisition technology, specifically to a recording control method, device, system, and program product that integrates trigger events. Background Technology

[0002] In Extended Reality (XR) robot training and data acquisition, a data acquisition operator typically needs to perform specific operations while wearing an XR device. The system records the operational data for robot training. To facilitate the operator in starting or stopping data recording during tasks, non-contact triggering methods, such as gesture recognition, are usually employed. The operator can control the recording process by making preset gestures (such as giving a thumbs-up with both hands), which has significant advantages in scenarios where hands are occupied or physical buttons are inconvenient to access.

[0003] However, the relevant technologies have the following drawbacks: First, vision-based gesture recognition technology is highly sensitive to lighting conditions. In complex outdoor lighting environments such as backlighting, low light, or when the hand is partially obscured, the accuracy and stability of gesture recognition will drop significantly, making it impossible for the data acquisition operator to reliably trigger recording, affecting acquisition efficiency and data continuity. Second, although hardware buttons (such as volume buttons on head-mounted devices) can be introduced as an alternative triggering method, this brings new problems: how to uniformly manage these two trigger signals, which have completely different sources and characteristics, ensuring that they follow the same business logic and quality control gating, and preventing hardware buttons from bypassing necessary inspection processes. In addition, due to potential network latency, when the system is in a waiting state, the data acquisition operator may unconsciously repeat gesture or button operations, thus causing the system to repeatedly initiate task requests, incorrectly start or stop recording, and cause data mismatch or state confusion. Summary of the Invention

[0004] This disclosure aims to solve the aforementioned technical problems, namely, the technical problems in XR robot teaching and data acquisition caused by the integration of multiple trigger sources, resulting in chaotic control logic and repeated triggering, leading to erroneous control recording.

[0005] According to some embodiments of this disclosure, a recording control method for fused trigger events is provided for XR robot teaching and acquisition operations. The method includes: acquiring trigger events collected by a collector corresponding to the acquisition environment; converting the trigger events from different sources into the same recording trigger mode through a trigger fusion device, wherein the recording trigger mode corresponds to different types based on the different sources of the trigger events; establishing a unified trigger entry point, calling a unified switching recording instruction, and inputting the recording trigger mode into the switching recording instruction; in response to meeting business gating, mapping the trigger events to a state machine through the unified trigger entry point, and controlling whether to perform recording based on the current state of the state machine, wherein the business gating is a pre-check condition for the trigger events to take effect; and in response to meeting the recording conditions, performing recording through the switching recording instruction based on the type of the recording trigger mode, and using the recorded data file as XR robot teaching operation data.

[0006] In some embodiments, acquiring the trigger event corresponding to the collection environment collected by the collector includes: responding to the light conditions of the collection environment meeting the collection conditions, using a gesture recognition event as the trigger event, wherein the type of the recording trigger mode is a gesture type; responding to the light conditions of the collection environment not meeting the collection conditions, using a hardware button event as the trigger event, wherein the type of the recording trigger mode is a button type.

[0007] In some embodiments, in response to the collector's gesture satisfying a preset gesture recognition condition, a gesture execution event is triggered, and a gesture end event is triggered when the gesture ends. The gesture recognition event between the gesture execution event and the gesture end event is obtained. The preset gesture recognition condition includes a gesture detection preset interval, a preset holding time, a shape integrity threshold, a preset number of stability checks, and a stability check preset interval.

[0008] In some embodiments, the business gate control includes: whether the first task has been received, whether the QR code has been scanned, whether the tracker status is normal, and whether the cloud collection quota is allowed. The first task is used to characterize the collection needs of the XR robot, the QR code is used to bind the collection environment and collection scene, the tracker is used to calculate the hand movement data of the collector, and the collection quota is used to determine the remaining number of current collection attempts.

[0009] In some embodiments, controlling whether to record based on the current state of the state machine includes: responding to the current state of the state machine being idle, executing a subtask acquisition; responding to the subtask being acquired and confirmed by the development board, executing a recording program; responding to the current state of the state machine changing from idle to waiting for the cloud to return a subtask, displaying a waiting prompt for new trigger events, and executing a recording program after the development board confirms the acquisition of the subtask; responding to the current state of the state machine changing from waiting for the cloud to return a subtask to waiting for the development board to retrieve a subtask, displaying a waiting prompt for new trigger events, and executing a recording program after the development board confirms the acquisition of the subtask; responding to the current state of the state machine changing from waiting for the development board to retrieve a subtask to recording, ending the currently running recording program, and switching the current state back from recording to idle.

[0010] In some embodiments, the execution of subtask retrieval includes: the XR wearable device's acquisition device requesting the acquisition of a subtask from the cloud, and the cloud returning a first identifier to the acquisition device; in response to receiving the first identifier from the acquisition device, the XR wearable device's development board requesting the retrieval of the subtask from the cloud; and the cloud returning a second identifier to the development board, wherein the first identifier and the second identifier are used to represent the corresponding subtask.

[0011] In some embodiments, while waiting for the cloud to return a subtask, in response to waiting for more than a preset time or failure to return, the current state of the state machine is switched back to the idle state, and the reason for failure is recorded; while waiting for the development board to pull a subtask, in response to waiting for more than a preset time or failure to pull, the current state of the state machine is switched back to the idle state, and the reason for failure is recorded; in response to recording failure when entering the recording state, the current state of the state machine is switched back to the idle state, and the reason for failure is recorded.

[0012] In some embodiments, before controlling whether to record based on the current state of the state machine, the method further includes: encapsulating the trigger events from different sources into the same trigger event queue, and the state machine consuming each trigger event one by one based on the timestamp of the event occurrence or the enqueue order of the different trigger events.

[0013] In some embodiments, when the first valid triggering event, whose timestamp is the earliest or which was first enqueued in the triggering event queue, triggers a state transition, and the current state of the state machine is switched from the idle state to the waiting for the cloud to return the subtask state, a cooling window is triggered. Subsequent triggering events that arrive consecutively within the cooling window will no longer trigger new fetching tasks, and the subsequent triggering events will be marked as duplicate triggers for debouncing.

[0014] In some embodiments, when the gesture recognition event is acquired, a hand frame, a crosshair, and a hand model are displayed on the acquisition page. The hand frame moves with the acquisition operator's head and remains perpendicular to the line of sight. The crosshair is used to assist the acquisition operator in locating the center of the field of vision. The hand model is used to display the acquisition operator's hand skeletal recognition status in real time.

[0015] According to some embodiments of this disclosure, a recording control device for fusing trigger events is provided for XR robot teaching and data acquisition operations. The device includes: an acquisition unit, configured to acquire trigger events collected by a data collector corresponding to the acquisition environment, and convert the trigger events from different sources into the same recording trigger mode through a trigger fusion device, wherein the recording trigger mode corresponds to different types based on the different sources of the trigger events; a calling unit, configured to establish a unified trigger entry, call the same switching recording command, and input the recording trigger mode into the switching recording command; a stabilization unit, configured to, in response to meeting business gating, map the trigger events to a state machine through the unified trigger entry, and control whether to perform recording based on the current state of the state machine, wherein the business gating is a pre-check condition for the trigger events to take effect; and a recording unit, configured to, in response to meeting recording conditions, perform recording through the switching recording command based on the type of the recording trigger mode, and use the recorded data file as XR robot teaching operation data.

[0016] According to some embodiments of this disclosure, a data acquisition and control system for integrating triggering events is provided for controlling the acquisition of teaching operation data of an XR robot. The system includes an XR wearable device and a cloud, wherein the XR wearable device is worn by a data acquisition operator. The XR wearable device includes a data acquisition device and a development board. The data acquisition device is used to acquire trigger events implemented by the data acquisition operator, convert them into a unified recording trigger mode, and establish a unified trigger entry point. The data acquisition device is also used to request sub-tasks from the cloud and, when the trigger event meets the business gate control, control whether to record based on the current state of the state machine. The development board is used to interact with the data acquisition device and, based on the sub-tasks acquired by the data acquisition device, request the cloud to retrieve the sub-tasks. The development board is also used to execute the recording program when the recording conditions are met and generate XR robot teaching operation data. The data acquisition device is also used to display the data acquisition operator's gestures on the data acquisition page and record the data acquisition operator's behavior and abnormal situations through pop-up windows.

[0017] According to some embodiments of this disclosure, an XR wearable device is provided, including: a processor; a memory for storing computer programs or instructions executable by the processor; wherein the processor is configured to execute the computer programs or instructions to implement the recording control method for fusion trigger events in any of the above embodiments.

[0018] According to some embodiments of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the recording control method for fusion triggering events in any of the above embodiments.

[0019] By adopting the above technical solution, this disclosure establishes a unified trigger entry point for trigger events from different sources, and at the same time adopts business gating and state machine debouncing mechanisms to ensure that the subsequent processing flow remains consistent regardless of the triggering method. Furthermore, it only provides prompts for subsequent repeated trigger events without initiating new task requests, effectively solving the problem of data mismatch caused by repeated operations in scenarios such as network latency, and improving the stability and consistency of data collection. Attached Figure Description

[0020] The preferred embodiments of this disclosure are described below with reference to the accompanying drawings, in which: Figure 1 This is a flowchart illustrating a recording control method for fusion-triggered events according to some embodiments of this disclosure; Figure 2 This is a schematic diagram illustrating the current states of a state machine according to some embodiments of this disclosure; Figure 3 This is a schematic diagram illustrating a dual-mechanism control recording according to some embodiments of the present disclosure; Figure 4 This is a block diagram of a recording control device for fusion trigger events, illustrated according to some embodiments of the present disclosure; Figure 5This is a block diagram of a recording and control system for fusion-triggered events, illustrated according to some embodiments of the present disclosure. Detailed Implementation

[0021] Some embodiments of this disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become readily apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become readily apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0022] The embodiments described in the following examples of this disclosure do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims. Those skilled in the art should understand that these embodiments are merely for explaining the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure.

[0023] This disclosure provides a method for recording and controlling fusion-triggered events in some embodiments, which is used to control the acquisition of teaching operation data for XR robots.

[0024] Before providing a further detailed description of the embodiments of this disclosure, the nouns and terms involved in the embodiments of this disclosure will be explained, and the nouns and terms involved in the embodiments of this disclosure are subject to the following interpretations.

[0025] (1) XR robot teaching and data collection service: This refers to a business scenario in which human operators demonstrate the operation of XR devices to collect data for training robots (such as robotic arms, humanoid robots, etc.) to imitate human behavior. The core of this service is to record human actions, gaze, interactions, and other data in real or virtual environments with high quality and high fidelity.

[0026] (2) Triggering event: refers to a discrete signal initiated by the collector with the intention of controlling the start or end of the recording. These signals come from various sources, including physical actions such as specific gestures (thumbs up gestures) and hardware interactions such as pressing physical buttons on the device (such as volume buttons).

[0027] (3) Recording trigger mode: refers to a standardized data structure used to uniformly represent trigger events from different sources. By converting gesture events, key events, etc., into recording trigger modes with the same format and attributes, they can be processed with a unified set of logic, thereby decoupling the trigger source from the subsequent business processing flow.

[0028] (4) Trigger Fusion Unit: This refers to a logical or physical module whose core function is to receive raw trigger signals from different input sources and convert them into a unified recording trigger mode. It is a key link in achieving multi-source input compatibility, and its function is to fuse events from different sources such as gesture recognition and hardware button events.

[0029] (5) Business gating: refers to a series of pre-check conditions that must be passed before core business operations (such as starting recording) are performed. These conditions are designed to ensure that the system operates in the correct state and under the correct authorization, and to prevent recording from starting under invalid or insecure conditions, thereby ensuring the validity and compliance of the collected data.

[0030] (6) State machine: refers to a mathematical model used to describe the behavior of a system in transitioning between different states based on input triggering events. In this disclosure, the state machine is the core mechanism for implementing recording process control and repeated trigger debouncing, and precisely defines the behavior and transition logic of the system in states such as idle, waiting, and recording.

[0031] Figure 1 This is a flowchart illustrating a recording control method 100 for fusion-triggered events according to some embodiments of this disclosure, such as... Figure 1 As shown, the method 100 includes steps S102, S104, S106 and S108.

[0032] In S102, the trigger events collected by the collector corresponding to the collection environment are obtained, and the trigger events from different sources are converted into the same recording trigger mode through the trigger fusion device. The recording trigger mode corresponds to different types according to the different sources of the trigger events.

[0033] In this embodiment, in a specific application scenario, a data collector wears an XR wearable device, whose task is to demonstrate a series of operations for the robot to learn. Trigger events initiated by the data collector are acquired. The sources of these trigger events vary depending on the data collection environment; for example, a specific gesture made by the data collector in well-lit conditions (such as a thumbs-up gesture), or a physical button pressed on the device (such as a volume button) in low light conditions where gesture recognition is difficult. To mask the differences in these sources, a trigger fusion processor uniformly converts these trigger events from different sources into a standardized recording trigger mode. This recording trigger mode includes information such as the event source type, for example, gesture type or button type. The trigger fusion processor allows subsequent processing logic to disregard the specific physical source of the event, thereby achieving compatibility and expansion for trigger events from different input methods. By converting trigger events from all sources into a standard format, the complexity and maintenance difficulties caused by writing independent processing logic for each input method in related technologies are resolved.

[0034] In S104, a unified trigger entry point is established, the same switching recording command is invoked, and the recording trigger mode is input into the switching recording command.

[0035] In this embodiment, the unified trigger entry point can be understood as a software interface or function. All recording trigger modes processed by the trigger fusion unit will enter the subsequent processing flow through this single entry point. The unified trigger entry point calls the recording switch instruction (TryToggleRec) and passes the recording trigger mode as a parameter to the instruction. In this way, it is ensured that whether it is gesture recognition or hardware button triggering, it ultimately boils down to a call to the same logical instruction, laying the foundation for the subsequent implementation of consistent business rules and state management. By establishing a unified trigger entry point, this disclosure can avoid the logical conflicts and race conditions that may be caused by multi-path, multi-entry control of recording.

[0036] In S106, in response to satisfying the business gating, the trigger event is mapped to the state machine through a unified trigger entry point, and the recording is controlled based on the current state of the state machine. The business gating is a pre-check condition for the trigger event to take effect. In this embodiment, the activation of a trigger event requires compliance with business gating constraints. Business gating consists of a series of pre-check conditions, such as whether a data collection task has been assigned, whether the data collection scenario has been bound via QR code, whether the tracker used for tracking actions is in normal condition, and whether the cloud-based data collection quota is sufficient. Only when all gating conditions are met is the trigger event considered valid. Therefore, this ensures the compliance of recording operations and the validity of data from a business perspective, preventing recording from starting under erroneous conditions. After passing the gating check, a valid trigger event is mapped to a state machine for processing. The state machine determines how to respond to the trigger event based on its current state (e.g., idle, waiting, recording), thereby controlling whether to record. For example, if the state machine is currently in an "idle state," a new recording process may be initiated; while if the state machine is in a "waiting for the cloud to return a task" state, the new trigger may be ignored or only a prompt may be given to the user. This state-based control is the core of implementing complex process management and debouncing functionality.

[0037] In S108, in response to the fulfillment of the recording conditions, recording is performed by switching the recording instruction based on the type of recording trigger mode, and the data file generated by the recording is used as teaching operation data for the XR robot.

[0038] In this embodiment, when recording conditions are met (e.g., the state machine successfully enters the recording state from the waiting state), the system executes a specific recording operation based on the type of recording trigger mode using the aforementioned switching recording command. For example, the system can record whether the recording was initiated by a gesture or a button based on the trigger mode type. After recording begins, the system records data such as the operator's actions and environmental images, and saves the generated data files as the final XR robot teaching operation data. This step is the ultimate goal of the entire process: generating high-quality training data. Through the aforementioned series of rigorous control processes, it is ensured that the final generated data files completely correspond to the expected acquisition tasks and states.

[0039] This disclosed recording control method for fusion-triggered events is applied to XR robot teaching and data acquisition. By integrating multiple triggering methods in complex outdoor lighting environments, it ensures the stability and reliability of recording control, avoiding recording errors or data mismatches caused by repetitive user operations or system delays.

[0040] Furthermore, in a preferred embodiment, the method for acquiring trigger events is described in detail. The most suitable triggering method is dynamically selected based on the lighting conditions of the acquisition environment. Specifically, when the lighting conditions in the acquisition environment meet preset acquisition conditions (e.g., illuminance is higher than a certain threshold, and hand tracking is stable), gesture recognition events are preferentially used as trigger events. This method offers natural interaction, requires no contact, and is very convenient. In this case, the type of recording trigger mode generated by the trigger fusion unit is marked as "gesture type". Conversely, when the lighting conditions in the acquisition environment do not meet the acquisition conditions (e.g., in outdoor backlight, twilight, or completely dark environments, the gesture recognition rate drops significantly), the method switches to hardware button events as trigger events. The acquisition operator can trigger recording by pressing a specific physical button (such as a volume button) on the XR wearable device or its handle. In this case, the type of recording trigger mode is marked as "button type". This design, which adaptively switches triggering methods based on ambient light, greatly improves the universality and reliability of the method. It retains the convenience of gesture interaction while providing a hardware fallback solution to ensure the task can continue under adverse conditions, solving the problem of poor adaptability of a single triggering method in complex outdoor environments.

[0041] In another preferred embodiment, to improve the accuracy and anti-interference capability of gesture recognition, the conditions for triggering gesture recognition events are finely designed. Not any brief or non-standard gesture will be accepted as a valid trigger event. A gesture execution event is triggered only when the gesture made by the data collector meets a series of preset gesture recognition conditions. These conditions may include: a preset gesture detection interval (e.g., once every 100 milliseconds to avoid excessive CPU consumption), a preset holding time (e.g., the gesture must be held stably for more than 0.5 seconds), a shape integrity threshold (e.g., the matching degree between the skeletal key points of the gesture and the standard template must be higher than 90%), a preset number of stability checks (e.g., three consecutive checks meet the conditions), and a preset interval for stability checks (e.g., the time interval between these three stability checks). When the gesture begins to meet these conditions, a "gesture execution event" is triggered, and a prompt such as "Two hands simultaneously giving a thumbs up" is displayed at the top of the data collection page; when the gesture no longer meets these conditions (e.g., the gesture ends or changes), a "gesture end event" is triggered. The system acquires stable gesture recognition events that are continuously confirmed between gesture execution events and gesture end events. By using these multi-dimensional and time-sequential constraints, we can effectively filter out unconscious, brief, or non-standard hand movements by the data collector during the operation, ensuring that only clear and continuous intentional gestures can trigger recording, thereby reducing the probability of false triggering and improving the accuracy of human-computer interaction.

[0042] In this embodiment, gesture quality can be scored using preset gesture recognition conditions. The gesture recognition module can output indicators such as shape integrity, duration of hold, whether both hands meet the requirements simultaneously, and whether the hand is being tracked. If the values ​​are below the threshold, only auxiliary prompts are displayed, and data collection is not triggered.

[0043] Furthermore, to provide intuitive and real-time feedback to the data acquisition operator, this embodiment of the disclosure displays a wealth of auxiliary information on the user interface of the data acquisition page, especially when gesture recognition is triggered. This information may include a hand frame, a crosshair, and a hand model. The hand frame is a virtual box that moves with the operator's head and remains approximately perpendicular to their line of sight. This frame serves as a cue to keep the operator's hand within the device's recognizable area. The crosshair, typically located at the center of the field of view, is a fixed marker used to assist the operator in locating the center of the field of view, ensuring that the key object being acquired is centered in the image. The hand model is a three-dimensional virtual hand model that reproduces the real-time recognized hand skeletal posture and movements of the operator in real time and with high fidelity. For example, when hand tracking is normal, the hand model may be displayed in green or highlighted; when tracking is lost or of poor quality, the hand model may turn red or semi-transparent. Through this series of visual feedbacks, the data collector can clearly perceive whether their hand has been correctly recognized by the system and how well it is being tracked. This allows them to proactively adjust the position and posture of their hand to meet the triggering conditions, forming an effective "perception-action-feedback" closed loop that improves the success rate of gesture interaction and user experience.

[0044] In one optional implementation, this disclosure describes in detail the specific content of business gating. Business gating is the first line of defense to ensure the correct execution of data collection tasks. This business gating includes the following checks: First, checking whether a first task has been claimed. The first task is a broad category of tasks representing the specific data collection needs of the XR robot; if no task has been claimed, subsequent recording is meaningless. Second, checking whether a QR code has been scanned. QR codes are typically used to bind the current physical data collection environment to a specific data collection scenario in the cloud database, ensuring that the collected data can be correctly classified and labeled. Third, checking whether the tracker is functioning correctly. Trackers (such as built-in or external locators in XR devices) are used to calculate the motion data of key parts of the data collector, such as hands and head; abnormal status will directly lead to low data quality or completely invalid data. Finally, checking whether the cloud data collection quota allows it. To manage storage and computing resources, a quota for the number of data collections or the duration is usually set for each user or project; new data collection should be prevented when the quota is exhausted. Only when all the above conditions (task claimed, code scanned, tracker functioning correctly, quota sufficient) are met can the business gate be considered passed, the triggered event be valid, and the process be allowed to proceed to the next stage. This multi-dimensional gate control mechanism ensures the effectiveness and compliance of the recording operation from multiple levels, including task, scenario, hardware, and resources.

[0045] Furthermore, Figure 2 This is a schematic diagram illustrating the current states of a state machine according to some embodiments of this disclosure, such as... Figure 2 As shown, the current state control recording process based on a state machine is explained in detail. The state machine is the core of managing the entire complex recording process. When a valid trigger event passes through the business gate, the state machine responds differently according to its current state. For example, when the current state of the state machine is idle (None), it indicates that no task is currently being executed by the system, i.e., no recording is being done. When a trigger event is received at this time, the subtask claiming process will begin. This process may include requesting a new subtask from the cloud. After the subtask information is returned and the development board confirms that it can be executed, the current state of the state machine transitions to the recording state and the recording program starts. When the current state of the state machine changes from the idle state to the waiting for the cloud to return the subtask (WaitingLocalPullJob) state, during this period, if the collector performs another trigger operation, the system will not start a new task request, but will display a waiting prompt such as "Waiting for the cloud to return the subtask, please wait" on the collector's interface, and will not repeatedly call ClaimCase (requesting the cloud to claim the subtask), thus achieving debouncing for repeated triggers. The system will only continue recording once the cloud successfully returns the subtask information and the development board confirms that it has accepted the subtask.

[0046] Similarly, when the state machine's current state changes from "Waiting for cloud to return subtask" to "Waiting for development board to pull subtask" (WaitingBoardPullJob), any new triggering event during this period will only trigger a waiting prompt. The state machine interface will display "Waiting for development board to pull subtask, please wait," and will no longer repeatedly send pull_job (request to pull task), thus achieving debouncing against repeated triggers. Recording will only begin after the development board successfully pulls and confirms the task. When the state machine's current state changes from "Waiting for development board to pull subtask" to "Recing," if another triggering event is received, its logical meaning changes to "Stop recording," ending the currently running recording program and switching the state machine's current state back from "Recing" to "Idle." Through this fine-grained state division and state transition logic, the state machine effectively manages the entire process from task application to recording completion, and solves the problem of repeated triggering in various waiting stages through the debouncing mechanism. The state machine's "Waiting for cloud to return subtask" and "Waiting for development board to pull subtask" states are also "Waiting to record" states. The state machine interface continuously displays the current states of the state machine, so when the data collector sees the state waiting to be recorded, there is no need to repeat gestures or key presses.

[0047] Figure 3 This is a schematic diagram illustrating a dual-mechanism control recording according to some embodiments of the present disclosure, such as... Figure 3 As shown, multi-source trigger events, such as gesture recognition events and hardware button events, are converted into a standardized recording trigger mode through a trigger fusion unit. The recording process is dually controlled by a pre-defined service gating and a repetitive trigger anti-shake mechanism. After passing through the gating service and undergoing anti-shake through the repetitive trigger anti-shake mechanism, the recording process begins (waiting to record, recording in progress, and ending). This disclosure manages the recording process through service gating and a state machine, effectively solving the problems of system state chaos and data inconsistency caused by network latency or repeated user operations, significantly improving system stability and data integrity.

[0048] This disclosure describes the specific process for retrieving a subtask, which involves the collaborative work between the acquisition device within the XR wearable device, the development board, and the remote cloud. First, the acquisition device within the XR wearable device (e.g., a processor running the main application logic) initiates a request to the cloud to retrieve a subtask. Upon receiving and verifying the request, the cloud generates a new subtask instance and returns a first identifier to the acquisition device to uniquely identify the subtask. Subsequently, the acquisition device passes the received first identifier to the development board within the same XR wearable device (e.g., a coprocessor or embedded board specifically responsible for data processing and hardware control). Upon receiving the first identifier, the development board uses it to request detailed information about the subtask from the cloud (such as the acquisition target, duration, parameter configuration, etc.). After verifying the validity of the first identifier, the cloud returns a second identifier (or data packet) containing complete task details to the development board, where the first and second identifiers together represent this specific subtask. This two-step mechanism, where the acquisition device "receives" the task ID and the development board "retrieves" the task details, separates task distribution from task execution, making the system architecture clearer and facilitating monitoring and management of different stages of the task lifecycle.

[0049] In another preferred embodiment, to enhance the robustness of the system, timeout and failure handling mechanisms are designed for the critical waiting states of the state machine. (See reference) Figure 2 While waiting for the cloud to return the subtask, the system starts a timer. If the waiting time exceeds a preset threshold (e.g., 15 seconds), or if the cloud explicitly returns a failure message, the system determines that the task retrieval has failed and switches the state machine's current state from the waiting state back to the idle state. Simultaneously, the system records the specific reason for the failure (e.g., "network timeout" or "server error") and may display a notification to the data acquisition operator via the interface. Similarly, a similar timeout or failure handling mechanism exists while waiting for the development board to retrieve the subtask. If the development board fails to retrieve the task successfully within a preset time, the state machine will also switch back to the idle state and record the reason for the failure. Furthermore, even if the task has been successfully retrieved, failure may still occur when entering the recording state and actually starting the recording program (e.g., camera hardware initialization failure). In this case, the state machine will immediately switch back from the recording state to the idle state and record the reason for the failure. When the data acquisition operator triggers the process again, they will first see a summary of the previous failure through the retry window. By setting up recovery paths for every potentially blocked or failed step, the system is ensured not to be permanently stuck in an intermediate state. Even if the user operates in a weak network or unstable hardware environment, the system can roll back to the initial state after a failure and wait for the next trigger, thus improving system stability and user experience.

[0050] Furthermore, for trigger events from different sources, whether they are events generated by the gesture recognition module or events captured by the hardware key monitoring module, they are not processed immediately after being recognized or monitored. They are first encapsulated into trigger events and then placed in the same first-in-first-out trigger event queue. Trigger events from different sources can arrive sequentially or be queued separately within the same frame or a short time window. A trigger event can contain the following fields: trigger source, timestamp of the event occurrence, system state at the time of the event, task ID, and debouncing key value, etc. The task ID identifies which task the event belongs to, and events with the same debouncing key value are processed only the first one within a short time. In this embodiment, the quality score of gesture recognition, hold duration, number of consecutive successes, and hardware duration can be placed in the same trigger event queue. Events are retrieved from the queue one by one according to the order in which they entered the queue or according to the event timestamp for consumption. In this way, all concurrently generated trigger events are serialized, and the state machine processes only one event at any given time. Therefore, the possibility of multiple triggering events modifying the state machine state at the same time is avoided, ensuring the atomicity and consistency of state transitions, which is the foundation for achieving reliable debouncing and process control.

[0051] In this embodiment, "the same frame" refers to events that are detected by the system within the same rendering / update cycle. However, the gesture recognition callback, key listening callback, event encapsulation, and enqueueing actions still have a sequential order in program execution. The timestamp can record the time when the event is generated or received. However, if the timestamps of two triggering events are not precise enough, they may have completely identical timestamps. In this case, the timestamps are not used to forcibly distinguish them; instead, the enqueueing order is used as a fallback order.

[0052] This disclosure, through the serial processing mechanism of a state machine, avoids the concurrent modification of the state machine's state by multiple triggered events within the same frame. It fundamentally solves the race condition problem that may arise from multiple sources and concurrently triggered events.

[0053] Furthermore, in this embodiment of the disclosure, intelligent debouncing can be combined with a cooling window to handle scenarios where users trigger events consecutively within a short period of time. When the state machine consumes an event from the queue, and this event is valid (i.e., passes the business gating), causing the state machine to switch from an idle state to a state waiting for the cloud to return a subtask, this event is called the first valid trigger event. Immediately after this state transition, the system initiates a brief "cooling window" (e.g., 2 seconds). During the duration of this cooling window, if the state machine consumes subsequent trigger events from the queue, the system checks the timestamps of these trigger events. If the events occur within the cooling window, they will be automatically marked as "repeated triggers" and debouncing will be performed. Specifically, the system will not trigger a new fetch task process because of these subsequent events, but may only record a repeated trigger in the log or briefly display a "operation too fast" prompt on the interface. Only after the cooling window ends can a new trigger event be considered a completely new intent. By utilizing the cooling window design disclosed herein, even if gestures and key presses are queued in the same frame, after the first valid event causes the state machine to enter a waiting state, the second event, when consumed, will be debounced because the state has changed, preventing duplicate task fetching. This mechanism effectively solves the "frenzied clicking" problem caused by network latency or user uncertainty. It can respond promptly to the user's first valid operation and intelligently ignore subsequent redundant operations, thereby avoiding sending a large number of duplicate requests to the backend server, saving resources, and ensuring the cleanliness and uniqueness of the data flow.

[0054] In this embodiment of the disclosure, the trigger source (gesture or button), gesture recognition status (completeness, success or failure) and recording status changes (waiting to record, recording in progress, finished) can be recorded through logs and metadata. This information can be used for subsequent analysis to determine whether the problem is caused by gesture failure, hardware triggering, slow network, or repeated operation by the data collector.

[0055] In this embodiment, hardware buttons can be configured to distinguish between short and long presses. For example, a short press of volume + can be used to start / end recording, while a long press can be used as an emergency stop or on status prompt. Different button modes still enter the same business gate control process, the only difference being that different branch logic is executed based on whether it is a "short press" or a "long press".

[0056] Based on the same concept, this disclosure also provides a recording control device 400 for fusion trigger events. It is understood that the recording control device 400 for fusion trigger events provided in this disclosure includes hardware structures and / or software modules corresponding to each function in order to achieve the above-mentioned functions. Combining the units and algorithm steps of the various examples disclosed in this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of this disclosure.

[0057] Figure 4 This is a block diagram of a recording control device 400 for fusion-triggered events, illustrated according to some embodiments of the present disclosure. (Refer to...) Figure 4 The device 400 is used for XR robot teaching and data acquisition, and includes an acquisition unit 402, a recall unit 404, a stabilization unit 406, and a recording unit 408.

[0058] The acquisition unit 402 is configured to acquire trigger events collected by the collector corresponding to the collection environment, and convert trigger events from different sources into the same recording trigger mode through a trigger fusion unit. The recording trigger mode corresponds to different types depending on the source of the trigger event. The invocation unit 404 is configured to establish a unified trigger entry point, invoke the same switching recording command, and input the recording trigger mode into the switching recording command. The anti-shake unit 406 is configured to, in response to meeting business gating requirements, map trigger events to a state machine through the unified trigger entry point, and control whether to record based on the current state of the state machine. The business gating is a pre-check condition for the trigger event to take effect. The recording unit 408 is configured to, in response to meeting recording conditions, execute recording through a switching recording command based on the type of the recording trigger mode, and use the generated data file as XR robot teaching operation data.

[0059] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0060] Figure 5 This is a block diagram of a recording and control system 500 for fusion-triggered events, illustrated according to some embodiments of this disclosure. Please refer to [link to relevant documentation]. Figure 5This disclosure also provides a data acquisition and control system 500 that integrates trigger events for controlling the acquisition of teaching operation data for an XR robot. The system 500 includes an XR wearable device 510 worn by the acquisition operator and a remote cloud 520. The XR wearable device 510 is the front end for data acquisition, and its internal structure can be logically divided into an acquisition device 511 and a development board 512. The acquisition device 511 typically refers to the part that runs the main application, handles user interaction, and conducts initial communication with the cloud. The acquisition device 511 is responsible for acquiring trigger events (gestures or buttons) performed by the acquisition operator, converting them into a unified recording trigger mode, and establishing a unified trigger entry point. Simultaneously, the acquisition device 511 is also responsible for initiating a request to the cloud 520 to retrieve sub-tasks. When the trigger event meets the business threshold, the state machine within the acquisition device 511 will control whether to start the recording process based on the current state. The development board 512 is more geared towards low-level and data-intensive tasks. It interacts with the acquisition device 511, and after obtaining the identifier of the sub-task, requests the cloud 520 to retrieve the complete data of that sub-task. When the recording conditions are met, development board 512 is responsible for executing the actual recording program (e.g., controlling hardware such as cameras and sensors), and processing and generating the final XR robot teaching operation data. In addition, acquisition device 511 is responsible for the user interface presentation, such as displaying the gesture recognition status to the acquisition operator in real time via the acquisition page, recording the cause of any anomalies and solutions via pop-ups, and recording the acquisition operator's actions of clicking confirm, cancel, or close. The content recorded in the pop-ups is associated with the task ID, trigger source, state machine state, and anomaly type of the triggering event. By recording the pop-up appearance time, click time, clicked button, and trigger source, combined with the task ID, an operation audit chain is formed. This chain can be used by the acquisition operator to analyze whether problems are caused by accidental button presses, repeated gestures, or ignoring high-priority anomalies, forming a complete interaction and feedback loop.

[0061] This disclosure also provides an XR wearable device, which can be a head-mounted display, smart glasses, or other extended reality device. Its hardware structure includes, but is not limited to, one or more processors, a memory for storing programs and data, a display unit, one or more cameras, an inertial measurement unit (IMU), and a network communication module. The memory stores computer programs or instructions, and when the processor executes these computer programs or instructions, it can implement the recording control method for fusion trigger events of any of the foregoing embodiments. In other words, this XR wearable device, through its internal hardware and software collaboration, can achieve the fusion of trigger events, unified entry point invocation, state machine-based image stabilization control, and final recording execution, constituting a complete and independent solution entity.

[0062] In some embodiments of this disclosure, a storage medium is provided, which may be a non-transitory computer-readable storage medium.

[0063] In some embodiments of this disclosure, when instructions in the storage medium are executed by the processor of an electronic device (such as an XR wearable device), the electronic device is able to perform the recording control method for the fusion trigger event involved in any of the above embodiments.

[0064] This disclosure also provides a computer program product, which can exist in the form of a non-transitory computer-readable storage medium, such as a USB flash drive, optical disc, hard disk, or cloud storage. The storage medium stores computer program code. When the computer program is loaded and executed by a processor (e.g., a processor in an XR wearable device, or a processor on a server), it can implement the recording control method for fusion-triggered events involved in any of the above embodiments.

[0065] In a specific application scenario, suppose a data collector is wearing a PICO 4 Pro XR wearable device in a poorly lit auto repair shop, tasked with collecting data on brake pad replacement. First, the collector scans a QR code on the vehicle frame. The system checks the data through business gating, confirming the task is valid, the scene is successfully bound, the tracker is functioning properly, and the data collection quota is sufficient. Due to the alternating light and dim lighting in the shop, gesture recognition is unstable. The collector then presses the volume + button on the device to start recording. The acquisition unit captures this button event, triggers the fusion unit to convert it into a recording trigger mode of type "button type," and pushes it to the trigger event queue. The state machine consumer retrieves the event from the queue. At this point, the state machine is in an "idle state," and since the business gating has passed, the state machine transitions to "waiting for the cloud to return the subtask status" and initiates a 2-second cooldown window. Simultaneously, the data collection device requests the subtask from the cloud. Due to a slight network delay, the collector is unsure if the trigger was successful and presses the volume + button again after one second. The second button event is also encapsulated and queued. At this point, the cloud returns the first identifier, and the state machine transitions to the "Waiting for the development board to pull the subtask" state. Next, the state machine consumer processes the second button event, but it detects that the current state is not "idle" and that the event is within the cooldown window. Therefore, it directly marks it as a duplicate trigger and discards it, displaying a "Processing, do not repeat" message on the state machine interface. The development board successfully pulls detailed brake pad replacement task parameters from the cloud using the first identifier. The state machine then transitions to the "Recording" state, the recording unit activates all cameras and sensors, and the state machine interface displays a "Recording" icon and a timer. Simultaneously, the handprint function is activated, displaying real-time tracking of the operator's gloved hand movements. After completing the entire replacement process, the operator briefly presses the volume + button again. This event is processed by the queue and the state machine. Since the current state is "Recording," the state machine executes the stop recording logic and eventually switches back to the "idle" state. If the development board fails to complete the task fetching within 20 seconds during this process, a timeout mechanism will be triggered. The state machine will automatically revert to the "idle state" and display a pop-up message: "Task fetching timed out. Please check your network and try again." The reason for the failure will also be recorded. Through the coordinated operation of these mechanisms, even in complex environments and under conditions of user error, the system can still ensure the correctness, stability, and consistency of the recording process.

[0066] This disclosure achieves flexible integration of triggering methods by converting trigger events from different sources, such as gesture recognition and hardware buttons, into a unified recording trigger mode and establishing a unified trigger entry point for processing. When gesture recognition fails due to poor lighting, it can seamlessly switch to reliable hardware buttons, ensuring continuous and high-success-rate data acquisition in complex outdoor environments. By setting business gating, it ensures that any trigger event must undergo a series of pre-checks before taking effect, including task assignment, scene binding, device status, and cloud quotas. This guarantees that regardless of the triggering method, the recording operation strictly adheres to unified business rules, preventing invalid or illegal data acquisition operations from the source and ensuring the standardization of data acquisition. Furthermore, by introducing a state machine to manage the recording process and designing anti-jitter logic for intermediate states such as "waiting for cloud return" and "waiting for development board pull," subsequent repeated trigger events (whether gestures or buttons) will be identified and suppressed when the system is in these waiting states, preventing the generation of new task requests. This effectively solves the problems of system state chaos and data inconsistency caused by network latency or repeated user operations, significantly improving system stability and data integrity.

[0067] It should be noted that in the description of this disclosure, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0068] In this description, "multiple" means at least two, referring to two or more, such as two, three, etc., unless otherwise explicitly specified. Other quantifiers are similar. The singular forms "a," "the," and "the" are also intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, unless otherwise specified or clearly indicated from the context, the articles "a" and "an" as used in this disclosure and the appended claims are generally understood to mean "one or more."

[0069] It should be understood that, unless otherwise specifically indicated, features of various embodiments of this disclosure described herein can be combined with each other. As used herein, the term "and / or" includes any one of the related listed items and any combination of two or more; "and / or" describes the association relationship between related objects, indicating that three relationships may exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Similarly, "at least one of..." includes any one of the related listed items and any combination of two or more.

[0070] Furthermore, the term "exemplary" is used herein to indicate that it serves as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term "exemplary" is intended to present concepts in a concrete manner. As used herein, the term "or" is intended to indicate an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or clear from the context, "X applies A or B" is intended to indicate any of the natural inclusive permutations. That is, if X applies A; X applies B; or X applies both A and B, then applying A or B satisfies the condition under any of the foregoing instances.

[0071] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding the specification and drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in this disclosure, such terms are intended to be inclusive in a manner similar to the term “including.”

[0072] The technical solutions of this disclosure have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of this disclosure is obviously not limited to these specific embodiments. Without departing from the principles of this disclosure, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of this disclosure.

Claims

1. A recording control method integrating trigger events, used for XR robot teaching and data acquisition, characterized in that, The method includes: The system acquires trigger events collected by the collector that correspond to the collection environment, and converts the trigger events from different sources into the same recording trigger mode through a trigger fusion device, wherein the recording trigger mode corresponds to different types according to the different sources of the trigger events; Establish a unified trigger entry point, invoke the same switching recording command, and input the recording trigger mode into the switching recording command; In response to satisfying business gating, the triggering event is mapped to a state machine through the unified triggering entry point, and based on the current state of the state machine, control is exercised to determine whether recording is performed, wherein the business gating is a pre-check condition for the triggering event to take effect; and In response to the fulfillment of recording conditions, recording is performed by switching recording instructions based on the type of the recording trigger mode, and the data file generated by the recording is used as teaching operation data for the XR robot.

2. The method according to claim 1, characterized in that, The acquisition of trigger events corresponding to the acquisition environment collected by the collector includes: In response to the light conditions of the acquisition environment meeting the acquisition conditions, a gesture recognition event is used as the trigger event, and the type of the recording trigger mode is a gesture type; In response to the fact that the light in the acquisition environment does not meet the acquisition conditions, a hardware button event is used as the trigger event, and the recording trigger mode type is button type.

3. The method according to claim 2, characterized in that, In response to the operator's gesture meeting the preset gesture recognition conditions, a gesture execution event is triggered, and a gesture end event is triggered when the gesture ends. The gesture recognition event between the gesture execution event and the gesture end event is obtained. The preset gesture recognition conditions include a gesture detection preset interval, a preset holding time, a shape integrity threshold, a preset number of stability checks, and a preset stability check interval.

4. The method according to claim 1, characterized in that, The business gate control includes: whether the first task has been received, whether the QR code has been scanned, whether the tracker status is normal, and whether the cloud collection quota is allowed. The first task is used to represent the collection needs of the XR robot, the QR code is used to bind the collection environment and collection scene, the tracker is used to calculate the hand movement data of the collector, and the collection quota is used to determine the remaining number of collection attempts.

5. The method according to claim 1, characterized in that, The step of controlling whether to record based on the current state of the state machine includes: In response to the current state of the state machine being idle, the subtask is picked up; in response to the subtask being picked up and confirmed by the development board, the recording program is executed. In response to the current state of the state machine changing from the idle state to the waiting for the cloud to return the subtask state, a waiting prompt is displayed for new trigger events. After the development board confirms that it has received the subtask, the recording program is executed. In response to the current state of the state machine, the state changes from waiting for the cloud to return the subtask to waiting for the development board to pull the subtask. A waiting prompt is displayed for new trigger events. After the development board confirms that it has received the subtask, the recording program is executed. In response to the current state of the state machine changing from the waiting for the development board to pull a subtask to the recording state, the currently running recording program ends, and the current state is switched back from the recording state to the idle state.

6. The method according to claim 5, characterized in that, The execution of sub-tasks includes: The XR wearable device requests a sub-task from the cloud, and the cloud returns a first identifier to the acquisition device. In response to receiving the first identifier transmitted by the acquisition device, the development board of the XR wearable device requests the subtask from the cloud; The cloud returns a second identifier to the development board, wherein the first identifier and the second identifier are used to represent the corresponding subtask.

7. The method according to claim 5, characterized in that, While waiting for the cloud to return the subtask, in response to waiting for more than a preset time or failure to return, the current state of the state machine is switched back to the idle state, and the reason for failure is recorded. While waiting for the development board to pull the subtask, in response to waiting for more than a preset time or failure to pull, the current state of the state machine is switched back to the idle state, and the reason for failure is recorded. In response to a recording failure when entering the recording state, the current state of the state machine is switched back to the idle state, and the reason for the failure is recorded.

8. The method according to claim 5, characterized in that, Before controlling whether to record based on the current state of the state machine, the method further includes: The triggering events from different sources are encapsulated into the same triggering event queue, and the state machine consumes each triggering event one by one based on the timestamp of the event occurrence or the order in which they were enqueued.

9. The method according to claim 8, characterized in that, When the first valid triggering event in the triggering event queue, whose timestamp is the earliest or which was first enqueued, triggers a state transition, the current state of the state machine is switched from the idle state to the waiting for the cloud to return the subtask state, and a cooling window is triggered. Subsequent triggering events that arrive consecutively within the cooling window will no longer trigger new fetching tasks, and the subsequent triggering events will be marked as duplicate triggers for debouncing.

10. The method according to claim 2, characterized in that, When the gesture recognition event is acquired, the hand frame, crosshair, and hand model are displayed on the acquisition page. The hand frame moves with the acquisition operator's head and remains perpendicular to the line of sight. The crosshair is used to assist the acquisition operator in locating the center of the field of vision. The hand model is used to display the acquisition operator's hand skeletal recognition status in real time.

11. A recording control device integrating trigger events, used for XR robot teaching and data acquisition, characterized in that, The device includes: The acquisition unit is used to acquire trigger events collected by the collector that correspond to the collection environment, and to convert the trigger events from different sources into the same recording trigger mode through the trigger fusion unit, wherein the recording trigger mode corresponds to different types according to the different sources of the trigger events; The calling unit is used to establish a unified trigger entry point, call the same switching recording command, and input the recording trigger mode into the switching recording command; A debounce unit is used to respond to business gating by mapping the trigger event to a state machine through the unified trigger entry, and controlling whether to record based on the current state of the state machine, wherein the business gating is a pre-check condition for the trigger event to take effect; and The recording unit is used to perform recording by switching recording instructions based on the type of the recording trigger mode in response to the fulfillment of recording conditions, and to use the data file generated by the recording as teaching operation data for the XR robot.

12. A data acquisition and control system integrating trigger events, used to control the acquisition of teaching operation data for an XR robot, characterized in that, The system includes: an XR wearable device and a cloud, wherein the XR wearable device is worn by the data collector; The XR wearable device includes a data acquisition device and a development board. The data acquisition device is used to acquire trigger events implemented by the data acquisition operator, convert them into the same recording trigger mode, and establish a unified trigger entry point. The data acquisition device is also used to receive sub-tasks from the cloud and, when the trigger event meets the business threshold, control whether to record based on the current state of the state machine. The development board is used to interact with the acquisition device, and to request the sub-task from the cloud based on the sub-task received by the acquisition device; the development board is also used to execute the recording program when the recording conditions are met, and to generate XR robot teaching operation data. The data collection device is also used to display the collector's gestures on the data collection page and to record the collector's behavior and abnormal situations through a pop-up window.

13. An XR wearable device, characterized in that, include: processor; Memory for storing computer programs or instructions executable by the processor; The processor is configured to execute the computer program or instructions to implement the recording control method for fusion trigger events as described in any one of claims 1-10.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the recording control method for fusion trigger events as described in any one of claims 1-10.

Images