Event-driven robot teaching data real-time segmentation method and device

Abstract

The invention provides an event-driven robot teaching data real-time segmentation method and device. The method comprises the steps of firstly monitoring an event instruction which is issued by an operator and at least contains a start instruction and an end instruction; when the start instruction is monitored, starting a data recording process to record a teaching data stream generated by robot teaching operation; and when an ending instruction is monitored, the recording process is ended, an independent data file accurately corresponding to the starting and ending time of the teaching operation is generated based on the process starting and stopping time period, and real-time physical segmentation is completed. According to the method, the operator instruction is taken as a core triggering condition, the problem of redundant or incomplete data of traditional fixed-duration recording is avoided, manual later-stage screening is not needed, the teaching data acquisition efficiency is greatly improved, the data integrity and availability are guaranteed, and support is provided for efficient data production of robot imitation learning.

Description

Technical Field

[0001] This application relates to the field of robot imitation learning technology, and in particular to an event-driven method and apparatus for real-time segmentation of robot teaching data. Background Technology

[0002] In the field of robot imitation learning technology, the quality and efficiency of teaching data acquisition directly determine the effectiveness of subsequent model training. Currently, the industry generally adopts the traditional work paradigm of recording first and then processing. A typical implementation of this paradigm is a fixed-duration recording mode. For example, in open-source robot projects like Leju, once the recording script starts, it continuously records data for a preset duration. This approach cannot dynamically adjust according to the actual operation time of a single teaching task, nor can it distinguish the effectiveness of the operator's teaching actions. If the recording duration is shorter than the actual task duration, key action data will be missing, generating invalid data; if the recording duration is longer than the actual task duration, a large amount of redundant data including idle periods will be generated. More importantly, this paradigm inevitably records operator failures or unsatisfactory attempts. This invalid data needs to be processed later by manually replaying all recording files, identifying valid segments, and manually removing invalid content. This not only consumes a lot of manpower and time but is also prone to errors in human judgment, leading to the omission of valid data or the retention of invalid data, becoming a core bottleneck restricting the efficiency of teaching data production.

[0003] Even with attempts to optimize some technical solutions, such as the LeRobot framework introducing a button-based adoption or skip mechanism, the limitations of the traditional paradigm remain unbroken: operators cannot freely control the start time of recording according to their own operating rhythm, and key semantic information such as task attributes and operation results cannot be synchronously associated during the recording process, resulting in a disconnect between data collection and semantic annotation processes. Subsequent manual supplementation of data attributes is still required, making it difficult to achieve full-link automation. There is an urgent need for a new technical solution that can achieve synchronous data collection and segmentation and reduce manual intervention. Summary of the Invention

[0004] In view of this, the embodiments of this application provide an event-driven real-time segmentation method and apparatus for robot teaching data. With operator instructions as the core triggering condition, it avoids the problems of redundant or incomplete data in traditional fixed-duration recording, eliminates the need for manual post-screening, greatly improves the efficiency of teaching data collection, ensures data integrity and availability, and provides support for efficient data production for robot imitation learning.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide an event-driven real-time segmentation method for robot teaching data, comprising the following steps: Listen for event commands issued by the operator, which include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. Upon receiving the start command, a data recording process is initiated to record the teaching data stream generated during the robot's teaching operation. Upon receiving the termination command, the data recording process is terminated. Based on the start-to-end time period of the data recording process, an independent data file precisely corresponding to the start and end times of the teaching operation is generated, thus completing the real-time physical segmentation of the teaching data.

[0006] Secondly, embodiments of this application also provide an event-driven real-time segmentation device for robot teaching data, the device comprising: The monitoring module is used to monitor event commands issued by the operator. The event commands include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. The recording module is used to start a data recording process when the start command is heard, so as to record the teaching data stream generated during the robot's teaching operation; The generation module is used to terminate the data recording process when the end command is detected, and generate an independent data file that precisely corresponds to the start and end time of the teaching operation based on the start to end time period of the data recording process, thereby completing the real-time physical segmentation of the teaching data.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the event-driven real-time segmentation method for robot teaching data as described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the event-driven real-time segmentation method for robot teaching data as described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: By using operator-initiated start / end commands as the core trigger for data recording, this approach breaks the limitations of traditional fixed-duration recording or objective condition-triggered modes. It achieves precise synchronization between the recording process and the start and end rhythm of a single teaching operation—avoiding redundant data due to excessive recording time and incomplete data due to insufficient recording time. Furthermore, it directly generates independent data files that perfectly correspond to each teaching operation, completing real-time physical segmentation of teaching data from the source of data acquisition. This core design eliminates the need for subsequent manual playback and data segmentation, completely removing the efficiency bottleneck of manual post-processing in the traditional record-then-process paradigm. It significantly shortens the overall iteration cycle from data acquisition to model training. Simultaneously, the independent data files naturally bind each teaching operation to a single data set, facilitating subsequent data management (such as categorizing by operation batch or task stage) and avoiding the risk of entire files becoming unusable due to corruption of a single data segment in traditional batch recording files. This effectively ensures the security and availability of data assets, providing core support for improving both the efficiency and quality of robot teaching data acquisition. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating steps S101-S103 provided in the embodiments of this application; Figure 2 This is a schematic diagram provided in an embodiment of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the event-driven real-time segmentation device for robot teaching data provided in the embodiments of this application; Figure 6 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0018] See Figure 1 , Figure 1This is a flowchart illustrating steps S101-S103 of the event-driven real-time segmentation method for robot teaching data provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S103 shown will be explained.

[0019] In step S101, the event commands issued by the operator are monitored. The event commands include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. In step S102, upon receiving the start command, a data recording process is initiated to record the teaching data stream generated during the robot's teaching operation. In step S103, when the end command is detected, the data recording process is terminated. Based on the start-to-end time period of the data recording process, an independent data file that precisely corresponds to the start and end time of the teaching operation is generated, thus completing the real-time physical segmentation of the teaching data.

[0020] For example, see Figure 2 , Figure 2 This is a schematic diagram provided in the embodiments of this application, such as... Figure 2 As shown, the system listens for event commands issued by the operator. These event commands include at least a start command to trigger data recording and an end command to trigger data recording termination. This action embodies event-driven operation. Existing technologies mostly use fixed-duration recording or objective condition triggering, neither of which can match the actual duration of a single operator's teaching operation. This solution uses the operator's subjective intention (through actively issuing commands) as the triggering basis, ensuring that the start and stop of recording completely follow the start-end rhythm of a single teaching session. This addresses the pain points of redundant data due to excessively long recordings and incomplete data due to excessively short recordings from the source. The command set includes at least a start command and an end command, covering the minimum functional requirements for single teaching data acquisition while reserving flexible space for subsequent expansion (such as pause commands and restart commands). It is not limited to specific scenarios and can be adapted to various robot teaching tasks (such as grasping, placing, and assembling).

[0021] Upon receiving the start command, a data recording process is initiated to record the teaching data stream generated during the robot's teaching operations. Once the start command is received, the system immediately starts the recording process without delay, ensuring data is recorded the moment the operator begins teaching. This avoids invalid operations where the teaching action has started but the data has not been recorded due to a delay in initiation. The teaching data stream is a broad concept, encompassing all key data during robot teaching, including but not limited to robot joint angles, rotational speeds, torque data, end effector pose (X / Y / Z coordinates, attitude angles) data, and environmental and interaction data collected by sensors (such as vision sensors, force / torque sensors, and distance sensors). It is adaptable to the data stream output requirements of different types of equipment, such as industrial robots and collaborative robots.

[0022] Upon receiving the termination command, the data recording process is terminated. Based on the start-to-end timeframe of the data recording process, an independent data file precisely corresponding to the start and end times of the teaching operation is generated, completing the real-time physical segmentation of the teaching data. Each closed loop of the start-to-end command corresponds to an independent data file, and the file's time span is completely synchronized with a single teaching operation (e.g., if the operator teaches to grasp the bottle for 30 seconds, the file duration is 30 seconds). This eliminates the need for subsequent manual review of videos and individual data segment filtering to remove redundant or invalid content, directly eliminating the efficiency bottleneck of manual post-processing in existing technologies and significantly shortening the iteration cycle from data acquisition to model training. Independent files naturally achieve the binding of a single teaching operation with a single data set, facilitating subsequent data management (e.g., categorizing by task, filtering by operation results), and avoiding the risk of the entire file being rendered unusable due to the corruption of a segment of data in traditional batch recording files, thus improving the security of data assets.

[0023] In some embodiments, the step of listening to the event instruction further includes receiving metadata input by the operator, the metadata including at least task type information; when the data recording process is started, the initial identification information of the independent data file is generated using the metadata.

[0024] In existing technologies, teaching data only contains pure motion trajectories (such as joint angle change curves) without any associated information. Downstream processing requires manual labeling of each data point to indicate what task it corresponds to, who operates it, and the operation time. In contrast, this solution moves the metadata input to the listening command stage. Operators can input metadata before (or simultaneously with) issuing the start command, such as selecting task type = grabbing bottles, operator ID = 001, and device number = Robot05, so that the data carries key attributes from the moment it is generated.

[0025] Task type is the core dimension of data classification (e.g., training a crawling model requires filtering all crawling task data), so it is a mandatory information; other metadata (such as operator ID and timestamp) can be added flexibly according to needs, ensuring both core functionality and flexibility.

[0026] Initial identifiers are typically represented by the name of the data file or built-in tags. For example, based on the task type = "grasp bottle" and the timestamp = 20241001-143025, the initial file name might be generated as "task_grasp_bottle_20241001143025". This identifier method allows downstream systems (such as model training platforms and data management systems) to quickly identify the task type of the data simply by looking at the identifier, without needing to open the file, significantly reducing classification costs. For instance, before model training, the system can automatically aggregate all grabbing task data by filtering files with the initial identifier "grasp_bottle", without manual intervention, laying the foundation for end-to-end automation of data acquisition and model training, which is currently impossible with existing technologies.

[0027] In some embodiments, a management main thread works in conjunction with an independent recording subprocess. The management main thread is used to listen for event commands and control the recording logic. The recording subprocess is dedicated to data stream recording, and the management main thread starts and terminates the recording subprocess in a non-blocking manner.

[0028] The main management thread serves as the system's control center, focusing on handling human-computer interaction-related logic, including listening for the operator's start / end commands, determining the validity of the commands, and sending start / stop signals to the recording subprocess—it does not participate in the specific data stream writing operations, ensuring the real-time nature of command listening (e.g., when the operator presses the end command, the main thread can respond immediately without waiting for data to be written).

[0029] The recording subprocess, as the system's data recording unit, is only responsible for collecting teaching data streams from the robot system (such as reading joint data and sensor data from ROS topics) and writing the data to a file—it does not process any instruction logic, thus avoiding data recording lag or frame loss due to instruction judgment consuming resources, and ensuring the continuity and integrity of data stream recording.

[0030] If a single process is used (which listens for both commands and records data), when the data volume is large and the writing speed is fast, the process resources will be allocated to data recording first, resulting in a delay in command listening (such as a response 1-2 seconds after the operator presses the end button). The dual-process architecture, through the separation of responsibilities, fundamentally avoids this conflict and improves the overall performance of the system.

[0031] The main management thread starts and terminates the recording subprocesses in a non-blocking manner. After sending a start signal, the main management thread can immediately return to the listening instruction state without waiting for the recording subprocess to complete initialization (such as creating files or establishing data stream connections)—avoiding the delay problem caused by the operator starting teaching while the main thread is not ready due to the time spent on subprocess initialization. After sending a termination signal, the main management thread does not forcibly kill the recording subprocess, but waits for the subprocess to complete writing the remaining data (such as writing the last few frames of data in the buffer to the file and closing the file handle). After the subprocess exits normally, the main thread then executes subsequent logic (such as generating file identifiers)—avoiding data file corruption (such as incorrect file format or missing data) caused by forced termination, and ensuring data integrity.

[0032] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. The main management thread has a built-in finite state machine, which includes at least an idle state and a recording state. The method also includes steps S301-S303, which will be explained in conjunction with each step.

[0033] In step S301, when the finite state machine is in an idle state, it only responds to the start instruction and ignores other event instructions; In step S302, when the finite state machine is in the recording state, it only responds to the end instruction and ignores other event instructions; In step S303, after responding to the start command, the finite state machine is switched from the idle state to the recording state; after responding to the end command, the finite state machine is switched from the recording state back to the idle state.

[0034] The main management thread has a built-in finite state machine, which includes at least an idle state and a recording state. A finite state machine is a tool for managing processes through state-event-action logic. This application embodiment designs two core states to meet functional requirements while avoiding excessive logical complexity.

[0035] Idle state: The initial state when the system has not started recording. At this time, the main management thread has only completed initialization (such as loading metadata configuration and establishing command listening channels), and the recording subprocess is in an inactive state.

[0036] Recording in progress: The system has started recording. At this time, the main management thread continuously listens for the end command, and the recording subprocess continuously records the teaching data stream. The two work together in a non-blocking manner.

[0037] When the finite state machine is in an idle state, it only responds to the start instruction and ignores other event instructions; when the finite state machine is in a recording state, it only responds to the end instruction and ignores other event instructions. This rule is the core of preventing misoperation.

[0038] If the system is idle (not recording), even if the operator accidentally presses the end or pause command, the main management thread will determine that the command is invalid and ignore it—to avoid triggering the termination of unstarted child processes due to accidental operation, which could lead to system errors or process disruptions.

[0039] If the system is in a recording state (with a child process already started), even if the operator accidentally presses the start command or restart command, the main management thread will determine that the command is invalid and ignore it—to avoid triggering repeated startup of the child process due to accidental operation, resulting in multiple child processes recording at the same time and generating messy and redundant data files.

[0040] Upon responding to the start command, the finite state machine is switched from the idle state to the recording state; upon responding to the end command, the finite state machine is switched back from the recording state to the idle state. This switching logic ensures the closed loop and controllability of the process.

[0041] After the main management thread listens for the start command, it first verifies that the current state is idle, then executes the action of starting the recording subprocess, and finally switches the state—avoiding starting the subprocess in a non-idle state and ensuring that each start corresponds to a brand new recording cycle.

[0042] After the main management thread hears the termination command, it first verifies that the current state is recording, then executes the actions of terminating the recording subprocess and generating a data file, and finally switches back to the idle state—to avoid terminating the subprocess in a non-recording state, and at the same time ensure that each termination corresponds to a complete recording cycle and generates an independent data file.

[0043] In some embodiments, the termination instruction includes descriptive information about the teaching operation result; after terminating the data recording process, it further includes a metadata injection step: updating the identifier of the independent data file according to the operation result information to associate the semantic information of the operation result.

[0044] The termination instruction includes descriptive information about the teaching operation result. This design allows the operation result and the termination of recording to be completed simultaneously, avoiding the tedious process of manually recording the result later. The descriptive information includes at least success and failure—this is a key dimension for judging the validity of the data (e.g., training a model only requires successful data, while analyzing the reasons for failure requires failure data). For example, after an operator completes a teaching operation, if the action meets expectations (e.g., successfully grabbing a bottle), a termination instruction with success information is issued; if the action is incorrect (e.g., the bottle falls), a termination instruction with failure information is issued.

[0045] In the prior art, the operation results need to be manually annotated by playing back the data after recording (such as watching a 30-second video to determine whether it was successful or not), which is time-consuming and prone to errors; while the embodiment of this application embeds the result information into the end command, so that the operator can complete the result determination at the same time as stopping the recording, realizing the one-step completion of recording termination and result annotation, which greatly improves efficiency.

[0046] After terminating the data recording process, a metadata injection step is also included: based on the operation result information, the identifier of the independent data file is updated to associate the semantic information of the operation result.

[0047] Injection is performed after the recording process terminates but before the data file is fully generated—ensuring that the operation result information is completely associated with the corresponding data file, avoiding mismatches between the result and the file due to improper injection timing (e.g., generating the file first and then injecting the result; if a system error occurs in between, the result will be lost). By updating file identifiers (such as filename, built-in tags, and database records), the data file directly reflects the operation result. For example, updating task_grasp_bottle_20241001143025 to task_grasp_bottle_20241001143025_success allows downstream systems to quickly filter valid data through the identifier. For example, model training platforms automatically filter _fail files and train only using _success files without manual intervention.

[0048] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application. Based on the operation result information, the independent data file is identified and updated to associate the semantic information of the operation result. Specifically, steps S401-S403 will be described in conjunction with each step.

[0049] In step S401, the current identification information of the independent data file is obtained; In step S402, the description information is encoded into the current identification information to generate updated identification information; In step S403, a naming update operation is performed on the independent data file based on the updated identification information.

[0050] Obtaining the current identifier information of the independent data file is a prerequisite for identifier updates, ensuring that the update action is based on an existing identifier and avoiding duplication or errors. If the system has already performed metadata presets, the current identifier is an initial identifier containing task type and timestamp (e.g., task_grasp_bottle_20241001143025); if not, the current identifier is a system-generated basic identifier (e.g., record_20241001143025). In either case, the purpose of obtaining the current identifier is to ensure that the updated identifier inherits the original core information (such as task type and time), only adding the operation result field. The identifier can be obtained by reading the filename in the file system, accessing records in the data management database, parsing the metadata tags built into the file, etc., and is not limited to a specific method, adapting to different system architectures.

[0051] Encoding the description information into the current identifier information to generate updated identifier information is the core of result-identifier binding. It's crucial to ensure the encoding rules are clear and easily identifiable. The encoded identifier must be both human-readable and machine-readable. For example, it can use the format of the original identifier + underscore + result description (e.g., task_grasp_bottle_20241001143025_s), or the format of the original identifier + hyphen + result abbreviation (e.g., task_grasp_bottle_20241001143025_s) – avoiding complex encoding (e.g., encrypted strings) to ensure operators and downstream systems can quickly identify the result. If the description information indicates success, it is encoded as a preset value such as success, s, or 01; if it indicates failure, it is encoded as fail, f, or 02 – a unified encoding mapping table needs to be preset in the system to avoid identifier confusion due to inconsistent descriptions (e.g., some files use success, some use ok).

[0052] Based on the updated identifier information, a naming update operation is performed on the independent data file. This is the final step in the identifier update, ensuring that the result information is directly reflected in the filename. Before performing the naming update, the system must verify that the data file has been generated and is in a closed state (no data is being written) to avoid update failure or file corruption due to file occupancy. After the update is completed, the system must record an update log (e.g., 202410011431: file task_grasp_bottle_20241001143025 updated to task_grasp_bottle_20241001143025_success) for subsequent traceability. After the naming update, downstream systems can quickly obtain valid data through simple string matching (e.g., filtering files whose filenames contain _success), without parsing file content or querying the database, significantly reducing the complexity and time consumption of data filtering.

[0053] In some embodiments, the event command is received via at least one of keyboard input, graphical user interface operation, voice command recognition, or physical handle button triggering; the robot teaching data stream includes at least one communication topic data corresponding to robot joint states and sensor data.

[0054] The event command is received via at least one of the following methods: keyboard input, graphical user interface operation, voice command recognition, or physical handle button triggering.

[0055] Keyboard input: This is the most basic receiving method. It enables quick operation through preset key mapping (such as the s key for start command, the n key for successful end command, and the m key for failure end command). It is suitable for scenarios where the operator can have close contact with and control the computer (such as teaching a laboratory robot).

[0056] Graphical User Interface (GUI) Operation: Receive instructions through components such as buttons and drop-down boxes in a visual interface. For example, clicking the Start Recording button triggers a start instruction, and selecting the operation result - after success, clicking the End Recording button triggers an end instruction with success information. This is suitable for scenarios with high requirements for intuitive operation (such as training novice operators and teaching complex tasks).

[0057] Voice command recognition: The voice recognition module parses the operator's voice input (such as start recording, end recording, success) to generate commands. It is suitable for scenarios where the operator needs to operate the robot with both hands (such as handheld teach pendant) and cannot touch the keyboard / GUI (such as collaborative robot assembly teaching).

[0058] Physical handle button triggering: Commands are received through the buttons of a dedicated physical handle (such as a game controller with customizable buttons or an industrial teaching handle). This is suitable for scenarios that require mobile operation and strong anti-interference capabilities (such as multi-robot teaching in a workshop or outdoor robot teaching).

[0059] The system can select one or more receiving methods as needed (such as supporting both keyboard and gamepad simultaneously) to improve adaptability and avoid the failure of the solution due to the inability of a single receiving method to meet the needs of a specific scenario.

[0060] The robot teaching data stream includes at least one communication topic data corresponding to robot joint states and sensor data. This definition clearly defines the scope of data collection and ensures that the solution is adaptable to different robot data stream output formats. Core operating parameters of the robot joints include joint angles (e.g., the rotation angle of each axis of a 6-axis robot), joint speeds (e.g., degrees per second), and joint torques (e.g., the torque output by the joint). These data directly reflect the robot's motion trajectory and are a core component of the teaching data, applicable to all articulated robots (e.g., industrial robotic arms, service robots). Key data for robot-environment interaction includes visual sensor data (e.g., images and depth maps captured by cameras), force and torque sensor data (e.g., the force and torque values ​​when the end effector contacts an object), and distance sensor data (e.g., the distance to obstacles collected by ultrasonic sensors). These data supplement the environmental and interactive information of the motion trajectory and are suitable for teaching tasks requiring precise interaction (e.g., grasping fragile items, assembling precision parts). Current mainstream robot systems (such as ROS-based robots) use a topic mechanism to transmit data streams. For example, joint states are transmitted via the ` / joint_states` topic, and visual data is transmitted via the ` / camera / image_raw` topic. This solution limits the communication topic data to ensure direct interface with the data stream interfaces of existing robot systems without significant hardware or software modifications, thus reducing implementation costs. Different teaching tasks require different types of data to be collected (e.g., simple motion teaching only requires joint state data, while complex interactive teaching requires joint and force sensor data). Therefore, at least one channel is required to meet minimum data requirements while supporting simultaneous acquisition of multiple data types, improving the versatility of the solution.

[0061] In summary, the embodiments of this application have the following beneficial effects: By employing an event-triggered mechanism centered on operator intent, combined with a design that generates independent data files through real-time segmentation, the system accurately matches the actual duration of each teaching operation, eliminating redundant and incomplete data at the source. This also completely eliminates the tedious manual post-processing and filtering, significantly shortening the iteration cycle from data acquisition to model training and dramatically improving data production efficiency. Simultaneously, through pre-setting metadata and real-time injection of operation results, teaching data is associated with key semantic information such as task type and execution effectiveness at the source of acquisition. Downstream systems can directly achieve automated classification and filtering based on data identifiers, providing data with a more comprehensive and efficient processing capability. This lays the foundation for full-chain automation of data management and model training. In addition, the introduction of a dual-process collaborative architecture and a finite state machine ensures the parallel and stable operation of instruction listening and data recording, as well as effectively shielding against operator errors. This avoids data recording lag or file corruption and prevents data failure caused by process disorder, further ensuring the integrity and high quality of data assets. Ultimately, it realizes a comprehensive upgrade of robot teaching data collection from passive recording to active control and from manual dependence to automated management, adapting to various robot teaching scenarios such as industrial and collaborative applications, and providing key support for the efficient implementation of robot imitation learning technology.

[0062] Based on the same inventive concept, this application also provides an event-driven robot teaching data real-time segmentation device corresponding to the event-driven robot teaching data real-time segmentation method in the first embodiment. Since the principle of the device in this application is similar to the above-mentioned event-driven robot teaching data real-time segmentation method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0063] like Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of the event-driven real-time robot teaching data segmentation device 500 provided in this application embodiment. The event-driven real-time robot teaching data segmentation device 500 includes: The monitoring module 501 is used to monitor the event commands issued by the operator. The event commands include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. The recording module 502 is used to start a data recording process when the start command is heard, so as to record the teaching data stream generated during the robot's teaching operation. The generation module 503 is used to terminate the data recording process when the end command is detected, and generate an independent data file that precisely corresponds to the start and end time of the teaching operation based on the start to end time period of the data recording process, thereby completing the real-time physical segmentation of the teaching data.

[0064] Those skilled in the art should understand that Figure 5The functions of each unit in the event-driven real-time segmentation device 500 for robot teaching data shown can be understood by referring to the relevant description of the event-driven real-time segmentation method for robot teaching data described above. Figure 5 The functions of each unit in the event-driven real-time segmentation device 500 for robot teaching data shown can be implemented by a program running on a processor or by specific logic circuits.

[0065] In one possible implementation, the step of listening to the event instruction further includes receiving metadata input by the operator, the metadata containing at least task type information; when the data recording process is started, the initial identification information of the independent data file is generated using the metadata.

[0066] In one possible implementation, a management main thread works in conjunction with independent recording subprocesses. The management main thread is used to listen for event commands and control the recording logic, while the recording subprocesses are dedicated to data stream recording. The management main thread starts and terminates the recording subprocesses in a non-blocking manner.

[0067] In one possible implementation, the main management thread has a built-in finite state machine, which includes at least an idle state and a recording state. The method further includes the following sub-steps: When the finite state machine is in an idle state, it only responds to the start instruction and ignores other event instructions; When the finite state machine is in the recording state, it only responds to the end instruction and ignores other event instructions; Upon responding to the start command, the finite state machine is switched from the idle state to the recording state; upon responding to the end command, the finite state machine is switched back from the recording state to the idle state.

[0068] In one possible implementation, the termination instruction includes descriptive information about the teaching operation result; after terminating the data recording process, it further includes a metadata injection step: updating the identifier of the independent data file according to the operation result information to associate the semantic information of the operation result.

[0069] In one possible implementation, the independent data file is identified and updated based on the operation result information to associate the semantic information of the operation result, specifically including the following sub-steps: Obtain the current identification information of the independent data file; The description information is encoded into the current identification information to generate updated identification information; Based on the updated identification information, a naming update operation is performed on the independent data file.

[0070] In one possible implementation, the event command is received via at least one of keyboard input, graphical user interface operation, voice command recognition, or physical handle button triggering; the robot teaching data stream includes at least one communication topic data corresponding to robot joint states and sensor data.

[0071] The aforementioned event-driven real-time segmentation device for robot teaching data, through an event-instruction triggering mechanism centered on the operator's subjective intent, combined with a design that generates independent data files in real-time segmentation, accurately matches the actual duration of a single teaching operation, eliminating redundant and incomplete data at the source, and completely eliminating the tedious manual post-processing and screening process. This significantly shortens the iteration cycle from data acquisition to model training, substantially improving data production efficiency. Simultaneously, through pre-setting metadata and real-time injection of operation results, the teaching data is associated with key semantic information such as task type and execution effectiveness at the source of acquisition. Downstream systems can directly achieve self-management based on data identifiers. The automated classification and screening lays the foundation for the full-chain automation of data management and model training. In addition, the introduction of the dual-process collaborative architecture and finite state machine ensures the parallel and stable operation of instruction listening and data recording, and effectively shields against operator errors. This avoids data recording lag or file corruption, and prevents data failure caused by process disorder, further ensuring the integrity and high quality of data assets. Ultimately, it realizes a comprehensive upgrade of robot teaching data collection from passive recording to active control, and from manual dependence to automated management. It is suitable for various robot teaching scenarios such as industrial and collaborative applications, and provides key support for the efficient implementation of robot imitation learning technology.

[0072] like Figure 6 As shown, Figure 6 This is a schematic diagram of the composition structure of the electronic device 600 provided in the embodiments of this application. The electronic device 600 includes: The device 600 includes a processor 601, a storage medium 602, and a bus 603. The storage medium 602 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the storage medium 602 via the bus 603. The processor 601 executes the machine-readable instructions to perform the steps of the event-driven real-time segmentation method for robot teaching data described in the embodiments of this application.

[0073] In practical applications, the various components in the electronic device 600 are coupled together via a bus 603. It is understood that the bus 603 is used to achieve communication between these components. In addition to a data bus, the bus 603 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus 603.

[0074] The aforementioned electronic equipment, through an event-triggered mechanism centered on the operator's subjective intent and combined with a design that generates independent data files in real-time segmentation, not only accurately matches the actual duration of a single teaching operation, eliminating redundant and incomplete data at the source, but also completely eliminates the tedious manual post-processing and filtering, significantly shortening the iteration cycle from data acquisition to model training and substantially improving data production efficiency. Simultaneously, through pre-setting metadata and real-time injection of operation results, teaching data is associated with key semantic information such as task type and execution effectiveness at the source of acquisition. Downstream systems can directly achieve automated classification and filtering based on data identifiers. This lays the foundation for full-chain automation of data management and model training. In addition, the introduction of the dual-process collaborative architecture and finite state machine ensures the parallel and stable operation of instruction listening and data recording, and effectively shields against operator errors. This avoids data recording lag or file corruption, and prevents data failure caused by process disorder, further ensuring the integrity and high quality of data assets. Ultimately, it realizes a comprehensive upgrade of robot teaching data collection from passive recording to active control, and from manual dependence to automated management. It is suitable for various robot teaching scenarios such as industry and collaboration, and provides key support for the efficient implementation of robot imitation learning technology.

[0075] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 601, the event-driven real-time segmentation method for robot teaching data described in this application is implemented.

[0076] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0077] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0078] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0079] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0080] The aforementioned computer-readable storage medium, through an event-driven instruction triggering mechanism centered on the operator's subjective intent, combined with a design that generates independent data files in real-time segmentation, accurately matches the actual duration of a single teaching operation, eliminating redundant and incomplete data at the source. It also completely eliminates the tedious manual post-processing and filtering, significantly shortening the iteration cycle from data acquisition to model training and substantially improving data production efficiency. Simultaneously, through pre-setting metadata and real-time injection of operation results, teaching data is associated with key semantic information such as task type and execution effectiveness at the source of acquisition. Downstream systems can directly achieve automated classification based on data identifiers. The screening process lays the foundation for the full-chain automation of data management and model training. In addition, the introduction of the dual-process collaborative architecture and finite state machine ensures the parallel and stable operation of instruction listening and data recording, and effectively shields against operator errors. This avoids data recording lag or file corruption, and prevents data failure caused by process disorder, further ensuring the integrity and high quality of data assets. Ultimately, it realizes a comprehensive upgrade of robot teaching data collection from passive recording to active control, and from manual dependence to automated management. It is suitable for various robot teaching scenarios such as industry and collaboration, and provides key support for the efficient implementation of robot imitation learning technology.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0082] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0084] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0085] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for real-time segmentation of event-driven robot teaching data, characterized in that, Includes the following steps: Listen for event commands issued by the operator, which include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. Upon receiving the start command, a data recording process is initiated to record the teaching data stream generated during the robot's teaching operation. Upon receiving the termination command, the data recording process is terminated. Based on the start-to-end time period of the data recording process, an independent data file precisely corresponding to the start and end times of the teaching operation is generated, thus completing the real-time physical segmentation of the teaching data.

2. The method according to claim 1, characterized in that, The step of listening to the event instruction also includes receiving metadata input by the operator, the metadata including at least task type information; when starting the data recording process, the initial identification information of the independent data file is generated using the metadata.

3. The method according to claim 1, characterized in that, The main management thread works in conjunction with independent recording sub-processes. The main management thread is used to listen for event commands and control the recording logic, while the recording sub-processes are dedicated to data stream recording. The main management thread starts and terminates the recording sub-processes in a non-blocking manner.

4. The method according to claim 3, characterized in that, The main management thread has a built-in finite state machine, which includes at least an idle state and a recording state. The method also includes the following sub-steps: When the finite state machine is in an idle state, it only responds to the start instruction and ignores other event instructions; When the finite state machine is in the recording state, it only responds to the end instruction and ignores other event instructions; Upon responding to the start command, the finite state machine is switched from the idle state to the recording state; Upon responding to the end command, the finite state machine is switched from the recording state back to the idle state.

5. The method according to claim 1, characterized in that, The termination instruction includes descriptive information about the teaching operation result; after terminating the data recording process, it also includes a metadata injection step: according to the operation result information, the identifier of the independent data file is updated to associate the semantic information of the operation result.

6. The method according to claim 5, characterized in that, Based on the operation result information, the independent data file is identified and updated to associate the semantic information of the operation result, specifically including the following sub-steps: Obtain the current identification information of the independent data file; The description information is encoded into the current identification information to generate updated identification information; Based on the updated identification information, a naming update operation is performed on the independent data file.

7. The method according to any one of claims 1 to 6, characterized in that, The event command receiving method includes at least one of keyboard input, graphical user interface operation, voice command recognition, or physical handle button triggering; the robot teaching data stream includes at least one communication topic data corresponding to robot joint status and sensor data.

8. An event-driven real-time segmentation device for robot teaching data, characterized in that, The device includes: The monitoring module is used to monitor event commands issued by the operator. The event commands include at least a start command to trigger the start of data recording and an end command to trigger the termination of data recording. The recording module is used to start a data recording process when the start command is heard, so as to record the teaching data stream generated during the robot's teaching operation; The generation module is used to terminate the data recording process when the end command is detected, and generate an independent data file that precisely corresponds to the start and end time of the teaching operation based on the start to end time period of the data recording process, thereby completing the real-time physical segmentation of the teaching data.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the event-driven real-time segmentation method for robot teaching data as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the event-driven real-time segmentation method for robot teaching data as described in any one of claims 1 to 7.

Images