A robot teaching logic construction method based on hierarchical text configuration

Abstract

This invention provides a method and apparatus for constructing robot teaching logic based on hierarchical text configuration. It aims to achieve the direct definition of logical operations at arbitrary depths through text configuration, support dynamic context data binding, and possess configuration inheritance capabilities, thereby improving development efficiency and system maintainability. The method includes the following steps: S1, configuration loading and inheritance merging; S2, context namespace initialization; S3, recursive logic tree construction: traversing the condition list defined in the final configuration tree, identifying configuration keys starting with a preset logical operator prefix; when a corresponding configuration key is identified, creating the corresponding logical node to form a multi-branch structure; S4, dynamic path pre-compilation; S5, logic execution.

Description

Technical Field

[0001] This invention relates to the field of robot control and autonomous driving teaching software development technology, specifically to a method and apparatus for constructing robot teaching logic based on hierarchical text configuration. Background Technology

[0002] In the development of robot control and autonomous driving teaching software, it is often necessary to determine the current scene based on sensor data and execute corresponding logic. For example, in teaching reversing into a parking space, the system prompts the user to stop after detecting that the vehicle has entered the parking space. To improve software flexibility and configurability, developers often use configuration files (such as INI, XML, JSON, and YAML formats) to store variable parameters, such as distance thresholds and timeout periods. These parameters are read and assigned to variables in the code when the program starts.

[0003] Currently, more advanced configuration schemes are typically based on Behavior Trees or Finite State Machines (FSMs). The existing methods generally follow these steps: First, a JSON or XML file is defined to describe the node structure; then, the program reads this file and instantiates the corresponding programming language object (e.g., C++, Python object) based on the predefined node type (e.g., Sequence node, Selector node); finally, specific nodes are statically bound to program variables in the code, i.e., "node A bound to variable B". The structure of this scheme mainly consists of a parser and a node library.

[0004] However, existing technical solutions have the following drawbacks: Limited logical expressiveness: Existing configuration files can typically only store flat key-value pairs of parameters. When complex nested logic needs to be expressed (e.g., "(A and B) or (C and (D or E))"), it is difficult to describe directly through configuration files, and the complex logic often still needs to be hard-coded into the source code, reducing the flexibility of configuration.

[0005] Rigid data binding: In existing solutions, variable names referenced in configuration files are usually fixed strings. It is difficult to dynamically reference "private variables of the current task instance" or "specific indices in historical data sequences" (such as referencing data from the previous frame of a sensor) in the configuration, resulting in poor reusability of configuration templates.

[0006] Lack of template inheritance mechanism: Different teaching projects (such as "left reverse parking" and "right reverse parking") often contain a large number of identical logical judgments. Existing technologies usually require copying and modifying the entire configuration file, which is costly to maintain and prone to inconsistencies in multiple copies.

[0007] Therefore, there is an urgent need for a teaching logic construction method that can support complex logic recursive definition, dynamic data binding, and configuration reuse. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and device for constructing robot teaching logic based on hierarchical text configuration. It aims to enable the direct definition of logical operations at arbitrary depths through text configuration, support dynamic context data binding, and have configuration inheritance capabilities, thereby improving development efficiency and system maintainability.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A method for constructing robot teaching logic based on hierarchical text configuration includes the following steps: S1. Configuration Loading and Inheritance Merging: Read the main configuration file. If a basic configuration reference field is detected, load the basic configuration pointed to by that field and overwrite and merge the contents of the main configuration file into the basic configuration to generate the final configuration tree. S2. Context namespace initialization: Parse the variable definition fields in the final configuration tree, and establish corresponding independent data storage areas in memory based on the unique identifiers defined therein; S3. Recursive Logic Tree Construction: Traverse the condition list defined in the final configuration tree and identify configuration keys that start with the preset logical operator prefix; when the corresponding configuration key is identified, create the corresponding logical node and recursively parse the child configuration list under the key until the leaf node is parsed, and attach the parsed child node to the parent logical node to form a multi-branch structure. S4. Dynamic path pre-compilation: Parses the data access paths defined in the leaf nodes, replaces the dynamic placeholders in them with the identifiers of the current context, and parses the index tags contained in the path to generate access handles that can directly access memory data at runtime. S5. Logic Execution: During the operation of the robot's teaching task, condition judgment and logical operation are performed based on the structure of the logic operation tree and the access handle, driving the execution of the corresponding teaching logic.

[0010] Preferably, the configuration file is in YAML, XML, or JSON format.

[0011] Preferably, the dynamic placeholder is {code}.

[0012] Preferably, the index tags include non-negative indexes and negative indexes.

[0013] Preferably, negative indexes are used to access historical sequence data.

[0014] Preferably, the logical operator begins with AND. OR .

[0015] Preferably, if there is no basic configuration reference field, the main configuration file is used directly as the final configuration tree.

[0016] Preferably, the storage structure of the independent data storage area is shared_data.data[{code}], where {code} is the unique identifier parsed from the variables field, and the storage areas corresponding to different codes are isolated from each other.

[0017] Preferably, the access handle is a direct access pointer to a memory object or a lambda expression, used to skip the string matching process at runtime and directly access the target data.

[0018] Compared with the prior art, the beneficial effects of the present invention are: Strong logical expressiveness: Developers do not need to modify or compile the source code. They can intuitively define nested business logic trees of arbitrary depth and complexity simply by editing the indentation structure and specific tags of hierarchical text configuration files (such as YAML), which greatly improves the flexibility and readability of logic configuration.

[0019] High operating efficiency: Through the "dynamic path pre-compilation" technology, the path described in the text is parsed into a handle (such as a pointer or closure) that can be directly accessed in memory during the configuration loading stage, avoiding the overhead of repeatedly parsing strings and looking up dictionaries at runtime, and improving the execution speed of logical judgments.

[0020] High reusability and maintainability: It supports the inheritance and overriding of configuration files through the `text_config_path` field, allowing the creation of reusable logical templates and differentiated customization through derived files, reducing configuration redundancy and lowering maintenance costs. Simultaneously, by utilizing the `variables` field and placeholder mechanism, it achieves dynamic decoupling between logic and specific data context, further improving the template's versatility. Attached Figure Description

[0021] Figure 1 This is a flowchart of one embodiment of the present invention. Detailed Implementation

[0022] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings.

[0023] like Figure 1 As shown in the figure, the robot teaching logic construction method based on hierarchical text configuration provided in this embodiment of the invention has the following specific implementation steps: S1. Configuration Loading and Inheritance Merging When the system starts, it reads the specified main configuration file. The parser checks if the `text_config_path` field exists in this file. Assuming the value of this field is "base_parking_logic.yaml", the system will continue reading this base configuration file. Then, all configuration items in the main configuration file are merged with those in the base configuration file.

[0024] The merging rule is as follows: items in the main configuration override items with the same name in the base configuration, and items unique to the main configuration are added. Ultimately, a complete "final configuration tree" is generated, containing all inherited configurations. If the `text_config_path` field does not exist, the main configuration file is directly parsed into the final configuration tree. This mechanism enables configuration templating; for example, "left reverse parking" and "right reverse parking" can inherit the same "reverse parking" basic logic template, modifying only some parameters or conditions.

[0025] Step S2: Initialize the context namespace.

[0026] The `variables` field in the final configuration tree is parsed. This field defines a set of key-value pairs containing a key `code` whose value is a unique identifier, such as "left_parking_001". The system creates a dedicated data storage area in the shared data area of ​​memory (e.g., a global dictionary `shared_data.data`) with this `code` value as the key. This storage area is used to store private variables and real-time data during the execution of this specific teaching task instance, achieving data isolation between different task instances.

[0027] Step S3: Construction of the recursive logic tree Iterate through the list of conditions in the final configuration tree. This is an array where each element defines the logical decision structure.

[0028] Identify logical operators: When a key is encountered with "AND" _ or "OR When an item begins with an underscore (_), the system creates a logical node object.

[0029] Recursive parsing: AND The values ​​corresponding to the keys (a sublist) are used as a new list of conditions, and this step (S3) is recursively called for parsing.

[0030] Constructing leaf nodes: When encountering a tuple of the form ["source", "path", "op", "value"], perform path resolution on it; Mounting nodes: The child nodes obtained from the recursive parsing are mounted under their parent logical nodes. Through this depth-first recursive traversal, a complete multi-branch logical operation tree is finally built in memory, whose structure completely corresponds to the hierarchical relationship expressed by indentation in the configuration file.

[0031] Step S4: Dynamic path pre-compilation.

[0032] Precompile the data path strings within all leaf nodes constructed in step S3.

[0033] Placeholder replacement: Assuming the path string of the leaf node is "sensor_data.{code}.distance", the system will replace {code} with the actual identifier of the current context, such as "left_parking_001", to get the new path "sensor_data.left_parking_001.distance".

[0034] Index resolution: The path may contain an index, such as sensor_data.left_parking_001.history[-1]. The system will resolve -1 and mark it as "accessing the last element of this historical data list (i.e., the latest data)".

[0035] Generating an access handle: The replaced and resolved path (such as sensor_data["left_parking_001"]["distance"]) is transformed into an access handle that can be executed efficiently. For example, in Python, this might be a pre-compiled lambda function: lambda: shared_data.data["left_parking_001"].get("distance",0); in C++, this might be a pointer to a specific memory address. This step configures the text to be "compiled" into an efficient executable unit.

[0036] Step S5: Logic execution.

[0037] When the robot system is running, it triggers the corresponding teaching logic assessment.

[0038] Logical operations: Execution begins at the root node of the logical operation tree. If a logical AND node (AndNode) is encountered, all its child nodes are executed sequentially. The node only returns true if all its child nodes return true. If a logical OR node (OrNode) is encountered, the node returns true as long as at least one of its child nodes returns true.

[0039] Condition judgment: When the execution reaches the leaf node (ConditionLeaf), the pre-compiled access handle in step S4 is called directly to instantly obtain the latest real-time data (e.g., the current distance value), and then it is calculated with the comparison value (e.g., 10) and operator (e.g., <) defined in the configuration, and the judgment result is returned.

[0040] Driven Behavior: Based on the final output result (true or false) of the logic operation tree, drive the robot to execute the corresponding teaching instructions, such as playing voice prompts or performing the next action.

[0041] Through the above steps, this invention enables the construction of complex runtime logic through declarative hierarchical text configuration, combining flexibility, efficiency, and maintainability.

[0042] The following is a specific implementation process of one embodiment of the present invention: variables (basic variable definitions) Configuration architecture design: 1. Basic Configuration 1.1 Basic Configuration Key variables (basic variable definitions) Define unique identifiers for each teaching module. This includes: `code` (unique code), `name` (display name), `id` (task code), and `sub_id` (subtask code).

[0043] base_data (basic state data) Define the state variables that need to be maintained during the teaching process, supporting types such as boolean, integer, floating-point number, string, list, and dictionary. They can be dynamically updated and restore their initial values ​​upon reset.

[0044] base_data_update_requirements (basic status data update requirements) Define the update conditions and update values ​​for the basic state data. The state variables are automatically updated when the conditions are met, checking the conditions sequentially and using the first update value that meets the condition.

[0045] public_base_data (public base data) Define common state variables shared across teaching modules for coordination and communication between modules.

[0046] public_base_data_update_requirements (public base data update requirements) Define the update conditions and update values ​​for public basic data, with the same format as the update requirements for basic status data.

[0047] 2. Sequence data configuration key sequential_data_keys (list of sequence data keys) Define a list of variables that need to record historical sequences, and store historical values ​​in time series format. Access historical values ​​by index (-1 for the latest value, -2 for the previous value).

[0048] sequential_data_update_requirements (sequential data update requirements) Define the update conditions and the source of the update value for the sequence data. Updates are always performed when the condition is empty; otherwise, a new value is appended only when the condition is met.

[0049] 3. Timer configuration key time_record_keys (list of timer keys) Define a list of timers that need to be maintained to record the duration of a certain state.

[0050] timer_update_requirements (timer update requirements) Define the start and stop conditions for the timer. A single condition starts the timer if it is met and stops it if it is not met; two conditions start the timer if the first condition is met and stops it if the second condition is met.

[0051] 4. Trip Record Configuration Key itinerary_record_keys (list of trip record keys) Define a list of trip records that need to be maintained, used to accumulate the distance traveled in a certain state.

[0052] itinerary_update_requirements (Itinerary record update requirements) Define the start and stop conditions for trip recording, with the same format as the timer update requirements.

[0053] 5. Counter configuration key counter_keys (list of counter keys) Define a list of counters that need to be maintained to record the number of times a certain event occurs. The initial value is 0, and it can be automatically increased by updating the requirements.

[0054] counter_update_requirements (counter update requirements) Define the update conditions and step size for the counter. The counter increments by the specified step size when the condition is met. A reset condition can be defined to clear the counter to zero.

[0055] 6. Random number configuration key random_number_requirements (random number generation requirements) Define the conditions and range for generating random numbers. This includes: `conditions` (generation conditions), `type` (integer or floating-point number), and `range` (range).

[0056] 7. Conditional Configuration Key init_conditions (initialization conditions) Define the trigger conditions for the teaching module; the teaching module is activated when these conditions are met. It supports multiple data sources, comparison operators, and logical combinations (AND, OR).

[0057] break_conditions (interrupt conditions) Define the interruption conditions for the teaching module. When these conditions are met, the teaching module is interrupted, the system executes the interrupt text, and resets the state.

[0058] reset_conditions (Reset conditions) Define the reset conditions for the teaching module. When these conditions are met, all states are restored to their initial values, and the teaching module can be restarted.

[0059] stage_requirements (stage requirements) Define the completion conditions for each teaching stage to divide the teaching process. Check the stages in sequence and find the first incomplete stage as the current stage.

[0060] 8. Text configuration key checkpoint_text Define the prompt text and its triggering conditions for each teaching stage. This includes: `conditions`, `texts`, `text_variable`, `record`, `error_code`, `vehicle_control_command`, etc. If the condition is empty, return the first text; otherwise, return the first text that meets the condition.

[0061] checkpoint_level (checkpoint priority) Define the priority of texts for each teaching stage for multi-module coordination. The higher the value, the lower the priority.

[0062] break_text (break text) Define the message text to display when an interruption occurs; the format should be the same as the checkpoint text.

[0063] summary_conditions Define and summarize the relevant error tags and their priorities.

[0064] summary_text (summary text) Define the content of the summary text, with the key being the error flag and the value being the summary text.

[0065] 9. Auxiliary configuration key log_list (log list) Define a list of debug information to be printed for debugging and status monitoring. Use with caution in production environments.

[0066] 10. Conditional Expressions and Usage Principles Data sources: `shared_data`, `sensor_data`, `switch_data`, `field_status`, `time_record`, `itinerary_record`, `counter`, `random_number`, `reached`.

[0067] Path access: string (attribute / key), integer (list index, negative numbers from back to front), tuple (nested path), placeholder `{code}`.

[0068] Comparison operators: `equal`, `not_equal`, `greater`, `less`, `greater_equal`, `less_equal`, `between`, `not_between`, `in`, `not_in`.

[0069] Logical combinations: `AND_X` (all conditions are met), `OR_X` (at least one condition is met), which can be nested.

[0070] Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for constructing robot teaching logic based on hierarchical text configuration, characterized in that, Includes the following steps: S1. Configuration Loading and Inheritance Merging: Read the main configuration file. If a basic configuration reference field is detected, load the basic configuration pointed to by the field and overwrite and merge the contents of the main configuration file into the basic configuration to generate the final configuration tree. S2. Context namespace initialization: Parse the variable definition fields in the final configuration tree, and establish corresponding independent data storage areas in memory based on the unique identifiers defined therein; S3. Recursive logic tree construction: Traverse the condition list defined in the final configuration tree and identify configuration keys that begin with a preset logical operator prefix; When the corresponding configuration key is identified, the corresponding logical node is created, and the sub-configuration list under the key is recursively parsed until the leaf node is parsed. The parsed child nodes are then attached to the parent logical node to form a multi-branch structure. S4. Dynamic path pre-compilation: The data access path defined in the leaf node is parsed, the dynamic placeholders in it are replaced with the identifier of the current context, and the index tags contained in the path are parsed to generate an access handle that can directly access memory data at runtime. S5. Logic Execution: During the operation of the robot teaching task, condition judgment and logical operation are performed based on the structure of the logic operation tree and the access handle to drive the execution of the corresponding teaching logic.

2. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The configuration file can be in YAML, XML, or JSON format.

3. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The dynamic placeholder is {code}.

4. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The index tags include non-negative indexes and negative indexes.

5. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 4, characterized in that, The negative index is used to access historical sequence data.

6. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The logical operators begin with AND or OR.

7. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that... If the aforementioned basic configuration reference field does not exist, the main configuration file will be used directly as the final configuration tree.

8. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The storage structure of the independent data storage area is shared_data.data[{code}], where {code} is the unique identifier parsed from the variables field, and the storage areas corresponding to different codes are isolated from each other.

9. The method for constructing robot teaching logic based on hierarchical text configuration according to claim 1, characterized in that, The access handle is a direct access pointer to a memory object or a lambda expression, used to skip the string matching process at runtime and directly access the target data.

Images