A humanoid robot batch behavior sequence precomputation method based on arbitration flow generator

Abstract

The application discloses a humanoid robot batch behavior sequence precomputation method based on an arbitration flow generator. In an offline scene without a real hardware environment, a candidate behavior pool, an emotion vector sequence and a fixed environment snapshot are received, a complete arbitration process is simulated through memory level joint occupation simulation (occupation state is tracked by using a set data structure), and a judgment result is iteratively outputted per tick. Joint occupation information is simulated by software instead of hardware motor feedback, complete decoupling with hardware is realized, and offline pre-rehearsal and CI / CD regression testing of a behavior sequence can be completed under the condition without a robot entity.

Description

Technical Field

[0001] This invention relates to the field of humanoid robot behavior scheduling technology, specifically to a method for pre-computing batch behavior sequences of humanoid robots based on an arbitration flow generator. Under the condition of a given candidate behavior pool and a known emotion sequence, the generator pattern executes the complete arbitration process tick by tick and collects the judgment results, supporting offline pre-playing and scripted arrangement of behavior sequences. Background Technology

[0002] The humanoid robot's behavior arbitration module adopts an event-driven architecture in online operation mode: sensors trigger a state update every 33 milliseconds (30Hz), the arbitration pipeline responds to state change events, selects the best behavior from the current candidate behavior pool based on the latest sensor fusion results, and sends it to the joint controller. This mode is naturally suited to the robot's real-time interaction needs, but it exposes a lack of offline capabilities in the following three application scenarios: The first type involves online frame-by-frame decision-making that does not support offline previewing. In the workflow of robot behavior orchestration, the orchestrator needs to preview the effect of a behavior sequence driven by an emotional script in order to adjust the script. The script written by the orchestrator consists of 10 emotional state nodes arranged chronologically over 30 seconds (gradually changing from neutral to joy to surprise), and the expected corresponding behavior sequence is "still gaze → smile → nod → wide eyes → take a half step back". Existing online frame-by-frame solutions require the orchestrator to manually operate the robot simulator, clicking the "next frame" button tick by tick to trigger arbitration. Each of the 10 emotional nodes requires 10 independent arbitration calls, and each call requires manual input of PAD coordinates and environmental parameters and waiting for the result. A 30-second preview orchestration can take 25 to 40 minutes. The root cause is that the online arbitration module is designed to respond to external sensor events and lacks an internal interface for receiving complete emotional sequences and executing them in batches. The second type involves joint occupancy modeling that relies on real hardware feedback. Online arbitration of joint occupancy management depends on real-time status feedback from motor drivers—when a "right arm swing" action is selected, the arbitration module queries the bus for the current angle and duty cycle flags of the right shoulder pitch and right elbow servo motors, adding these two joint identifiers to the occupied set. In an offline simulation environment, without bus responses from real motor drivers, the joint occupancy modeling function throws a timeout exception due to the lack of hardware status callbacks, preventing the offline arbitration pipeline from completing properly. The root cause lies in the fact that the joint status query is hard-coded as a synchronous call to the hardware I / O driver, failing to provide an alternative path for software state machine simulation. The third type is the unserialized batch output interface. Online arbitration only produces one arbitration decision object per iteration (containing the winning behavior identifier, confidence level, timestamp, and a list of occupied joints), preventing the caller from obtaining the behavior sequence of multiple consecutive iterations at once. When an orchestrator needs to perform "behavior-emotional consistency" analysis on a 5-minute script, they need to write an outer loop script to record the structured text of the arbitration decision object at each step, generating approximately 9000 independent files (sampling frequency of 30 times / second for 5 minutes). Then, another script is written to parse these 9000 files one by one and import them into the analysis tool. This fragmented workflow makes the preparation time for data analysis far exceed the analysis itself. The root cause is that the arbitration module exposes a single-instance call interface for each iteration, lacking the ability to batch aggregate multiple arbitration decisions. In summary, existing behavior arbitration systems cannot meet the actual needs of behavior orchestration and offline analysis in terms of offline pre-playing, hardware-independent joint occupancy simulation, and serialized batch output. Summary of the Invention

[0003] This invention provides a method for pre-computing batch behavior sequences of humanoid robots based on an arbitration flow generator. It encapsulates the complete arbitration process iteration logic through a generator pattern. After receiving a candidate behavior pool and a known emotion sequence, it generates arbitration judgment result tuples in each iteration using a lazy evaluation method. It supports behavior sequence pre-playing and scripted arrangement in offline environments. The technical solution of the method corresponds to the following independent steps: Step one involves receiving three input parameters: a candidate behavior pool (a list of candidate behavior objects, each containing metadata such as behavior identifier, set of requirement joint identifiers, estimated energy consumption, and risk level), a time-ordered sequence of emotion vectors (a list of emotion vector objects, each element containing the PAD 3D coordinates and signal strength values ​​for each modality in the corresponding iteration round), and an environmental snapshot (an environmental snapshot object containing read-only environmental parameters such as ambient light, human-computer distance, and user arousal level). The environmental snapshot remains unchanged throughout the iteration process, simulating a typical script scenario where "the environment is static while emotions flow." Step 2: Initialize state variables. The set of occupied joints is initialized to an empty set, and the iteration counter is initialized to 0. The set of occupied joints maintains its state throughout the generator's lifetime, simulating the physical process of "behavior execution → holding occupation → timeout release" of joint motors in real hardware. Step 3: Iterate through the sentiment vectors, executing the complete arbitration process for each iteration. Using the current sentiment vector as the sentiment input, the environment snapshot as the environment input, the candidate behavior pool as the behavior pool, and the set of occupied joints as the current occupancy state, the complete arbitration process is invoked. This arbitration process internally executes three stages: the first stage involves three-boundary candidate selection; the second stage involves fuzzy inference scoring and ranking; and the third stage involves conflict resolution and occupancy update. Step four: Collect the results of this round of arbitration. If the arbitration process produces a selected action, the result is encapsulated into an arbitration decision tuple, with fields including: iteration round number, timestamp offset, selected action identifier, confidence score, and a list of requirement joint identifiers for that action. This tuple is then produced element by element through a lazy production mechanism, which the caller can receive element by element. Step 5: Update the occupied joint set. If a selected behavior is generated in this round, add all the required joint identifiers for that behavior to the occupied set. This means that in subsequent iterations, other candidate behaviors occupying the same joints will be excluded in the third-stage conflict resolution phase. Step Six: Periodic Joint Release. Every 5 iterations, the occupied joint set is cleared. This mechanism simulates the automatic release of a real servo motor after the action is completed—the typical action duration of a family emotional companion robot is 100 to 200 milliseconds, corresponding to 3 to 6 servo control cycles (ticks) of 33 milliseconds each. The median of 5 ticks (165 milliseconds) is used as the default clearing interval. After clearing, the occupied joint can be reused for a new action in the next tick, simulating the physical state transition of "action completed → joint idle". Step seven: After the iteration is complete, the generator terminates naturally. The caller collects all arbitration decision tuples at once, obtaining the complete offline behavior sequence. Beneficial effects and causal chain: First, a qualitative leap in offline pre-playing efficiency. Traditional tick-by-tick manual invocation requires manual input of parameters for each node and waiting for results sequentially, with previewing and arranging an emotional script taking tens of minutes. This solution's generator returns all arbitration decision tuples at once after invocation, with the total time being only the sum of the arbitration times for each iteration. Arrangers can preview the behavioral sequence corresponding to an emotional script in a very short time, achieving a rapid iterative workflow of "modify script → instant preview → further modification → further preview." The causal chain is: batch input of emotional sequences → one-time generator iteration → automatic internal state management → one-time output of all decisions → arrangement iteration cycle shortened from minutes to milliseconds. Second, hardware-independent joint occupancy simulation. The generator uses in-memory data structures to track joint occupancy states in memory, without relying on the controller LAN bus or motor driver application interface. The only dependency for running the generator offline is the pure software arbitration module source code, requiring no connection to robot hardware, simulators, or middleware. In one offline regression test, a large number of test cases ran in hardware-free mode and all passed—while the old solution relying on hardware simulation required a connection to a dedicated simulation server, significantly increasing the testing cycle. The causal chain is: in-memory data structures → memory-level occupancy tracking → zero hardware dependency → direct operation in continuous integration environment → significantly shortened testing cycle. Third, the memory efficiency of lazy evaluation. The generator's lazy evaluation mechanism means that only one arbitration decision object for the current iteration is kept in memory at a time, rather than temporarily storing all decisions in a list throughout the entire loop. For long-duration emotional scripts, the peak memory usage of the generator pattern is the memory usage of a single decision object plus the data structure overhead of the already occupied joint set, which is extremely small. In contrast, if a pre-allocated list scheme is used, decision objects for all iterations need to be stored in memory, and the memory usage increases linearly with the number of iterations. The causal chain is: lazy evaluation mechanism → on-demand element-by-element production → caller consumes on demand → constant peak memory usage → can handle scripts with extremely long time spans. Attached Figure Description Figure 1 This is a schematic diagram of the batch behavior sequence pre-computation process based on the arbitration flow generator. The diagram is labeled as follows: 101-Input candidate behavior pool and sentiment vector sequence, 102-Execute the complete arbitration process iteratively for each sentiment vector, 103-When the selected behavior is produced, it is incorporated into the demand joint to the occupied set, 104-Clear the occupied set every 5 iterations, 105-Output all arbitration decision tuples. Figure 2 This is a schematic diagram of the state changes of the joint occupancy set in consecutive iterations. The diagram is labeled as follows: 201 - Initial empty state of the occupancy set, 202 - Normal occupancy accumulation state, 203 - Conflict saturation state, 204 - Periodic release state. Figure 2 The complete lifecycle of the joint occupancy set during the simulated arbitration process is demonstrated, from empty set → accumulation → conflict saturation → clearing → re-availability. Detailed Implementation like Figure 1 As shown below, this method will be explained using a typical emotional script rehearsal scenario. A behavior programmable engineer wrote a 3-node emotional script called "Good Morning Wake-up" for a family emotional companion robot. The emotional sequence and environmental snapshot set in the script are as follows: Emotional sequence: Contains three emotional vector nodes—Iteration 0: Pleasure = -0.30, Arousal = 0.55, Dominance = -0.10, Vision = 0.42, Hearing = 0.68, Touch = 0.05 (User has just woken up and is slightly irritable); Iteration 1: Pleasure = 0.10, Arousal = 0.30, Dominance = 0.00, Vision = 0.55, Hearing = 0.35, Touch = 0.10 (Gradually calming down); Iteration 2: Pleasure = 0.65, Arousal = 0.45, Dominance = 0.20, Vision = 0.88, Hearing = 0.72, Touch = 0.35 (Smiling at the robot, in a pleasant mood). Environmental snapshot: Illuminance 180.0 lux, human-machine distance 1.8 meters, time of day: morning. The candidate behavior pool contains 6 candidate behaviors: 1. Gaze following face (Gaze type, requires joints {neck pitch, neck yaw}, energy consumption 3J, risk 1) 2. Gentle nod (expressive, requires joint {neck flexion / extension}, energy consumption 5J, risk 1) 3. Avoid turning (expression type, requires joints {neck yaw, shoulder pitch}, energy consumption 12J, risk 2) 4. Smiling and nodding (expressive, requiring joints {neck tilt, mouth light}, energy consumption 8J, risk 1) 5. Take a step back (Movement type, requires joints {hip pitch, knee}, energy consumption 55J, risk 3) 6. Warm Lighting Caution (Caution Class, Requirement Joint {Chest Light}, Energy Consumption 1J, Risk 1) The orchestrator calls the generator ( Figure 1 As shown in mark 101, the input behavior pool, emotion sequence and initial joint occupancy set are used to obtain all arbitration judgment results through a one-time collection operation. Generator internal execution flow ( Figure 1 As shown in mark 102, arbitration is performed iteratively round by round. Iteration round 0 (pleasure = -0.30, arousal = 0.55, dominance = -0.10, user frustration): — The set of occupied joints is initialized to an empty set.

[0004] — Phase 1 Three-Boundary Screening: Illumination 180 lux, no illumination boundary triggered. Human-machine distance 1.8 meters, no safety boundary triggered. All 6 candidates passed Phase 1.

[0005] — Second stage fuzzy reasoning: Pleasure level = -0.30, Arousal level = 0.55. Anger rule condition: Pleasure level < -0.3? -0.30 is not strictly less than -0.30 (fuzzy membership boundary case), membership output 0.0.

[0006] Activation levels for each rule: Pleasure = 0.28, Sadness = 0.12, Anger = 0.00, Surprise = 0.42, Neutrality = 0.31.

[0007] Surprise won by a narrow margin with a score of 0.42 (because the arousal score of 0.55 is close to the high arousal threshold of surprise, and the membership score is 0.42).

[0008] — Phase 3 Conflict Resolution: All joint requirements for the six behaviors are checked for occupancy conflicts. The set of occupied joints is empty, indicating no conflict.

[0009] The behavior with the highest matching degree of the surprise tag is to avoid turning around (avoiding / turning around corresponds to the physical reaction of surprise).

[0010] — Output arbitration decision: Iteration round 0, timestamp 0 milliseconds, selected behavior "avoid turning", confidence level 0.42, required joints {neck yaw, shoulder pitch}.

[0011] — Update occupied set ( Figure 1 As shown in the middle mark 103, (included in the occupied set): Occupied joint set = {neck yaw, shoulder pitch}. First iteration (pleasure = 0.10, arousal = 0.30, dominance = 0.00, mood calming): — Phase 1: All passed.

[0012] — Phase Two: Activation levels for each rule: Pleasure = 0.30, Sadness = 0.10, Anger = 0.00, Surprise = 0.18, Neutral = 0.55. Neutral wins.

[0013] — Phase 3: Candidate behavior gaze following facial requirements {neck pitch, neck yaw} — Neck yaw has been occupied by iteration 0, resulting in a conflict. Gaze following the face is excluded.

[0014] The candidate behavior for gentle nodding (neck tilt) is available as it is not currently in use.

[0015] The most conflict-free behavior with the highest neutral label matching degree is a gentle nod.

[0016] — Output arbitration decision: Iteration round 1, timestamp 33 milliseconds, selected behavior "gentle nod", confidence level 0.55, required joint {neck pitch}.

[0017] — Update occupied set ( Figure 1As shown in the middle label 103, (included in the occupied set): Occupied joint set = {neck yaw, shoulder pitch, neck pitch}. Second iteration (pleasure = 0.65, arousal = 0.45, dominance = 0.20, user is happy and smiling): — Phase 1: All passed.

[0018] — Phase Two: Pleasure activation score = the smaller of visual intensity 0.88 and PAD matching value 1.0 = 0.88. All other rule activation scores are less than 0.88. Pleasure wins with a high score of 0.88.

[0019] — Phase 3: Candidate behaviors: smiling and nodding requirements {neck tilt, mouth light} — Neck tilt has been occupied by the first iteration, resulting in a conflict.

[0020] Candidate behavior: Warm lighting, attention required {chest lighting} – Chest lighting is not occupied and is available.

[0021] However, the match between warm lighting attention and the pleasant label was only 0.25 (lighting cues do not express pleasant emotions).

[0022] Since the smiling nod was excluded due to joint conflict, the system selected the suboptimal matching behavior gaze following facial needs {neck pitch, neck yaw}, but at this time both neck pitch and neck yaw were occupied.

[0023] Check the condition of clearing the occupied set every 5 iterations. Figure 1 (As shown in mark 104): Iteration counter = 2, no clearing is triggered.

[0024] Conclusion: All pleasurable emotion matching behaviors in this iteration had occupancy conflicts. The system records a behavior blocking log and generates an empty decision.

[0025] — Output arbitration decision: Iteration round 2, timestamp 66 milliseconds, selected behavior none, confidence level 0.0, requirement joint empty. The generator outputs a complete sequence of behaviors: in iteration 0, "avoid turning around" is selected with a confidence level of 0.42; in iteration 1, "gentle nod" is selected with a confidence level of 0.55; and in iteration 2, no behavior is selected with a confidence level of 0.0. The scriptwriters discovered a behavior blockage in the second iteration based on the preview results—the "smiling nod" could not be executed due to joint occupancy. The scriptwriters adjusted the script by inserting a neutral buffer frame (adding a 33-millisecond interval) between the first and second iterations, allowing the occupancy set time to release neck pitch after the fifth frame is cleared, thus enabling the "smiling nod" to execute smoothly after the second iteration. like Figure 2As shown, the joint occupancy set experiences a complete lifecycle consisting of four states in consecutive iterations. The initial state (e.g.) Figure 2 As shown in mark 201), the occupied set is initially empty. After the first iteration produces the selected behavior, the demand joint for that behavior is incorporated into the occupied set, completing the first transition from an empty set to an accumulated set. Normal occupied accumulation state (e.g.) Figure 2 As shown in mark 202), in subsequent iterations, the occupancy set contains the identifiers of already occupied joints. New candidate behaviors that conflict with the occupied joints are excluded during the conflict resolution phase; only conflict-free behaviors are selected, and the occupancy set continues to accumulate newly occupied joints. Conflict saturation state (e.g., Figure 2 As shown in mark 203, when the occupancy set contains multiple joints and all the demand joints of the candidate behaviors conflict with the occupancy set, this iteration round produces an empty decision, and the occupancy set remains unchanged. Periodic release state (e.g.) Figure 2 As shown in mark 204, after every 5 iterations, the clearing condition is triggered, and the occupied set is cleared to an initial empty set state. All joints are then available again for new behavior scheduling, and the occupied set enters a new lifecycle cycle. This closed-loop process of simulating "empty set → accumulation → conflict saturation → periodic release → return to empty set" in memory completely replicates the physical process of a joint motor in real hardware from being occupied by a behavior, holding the occupation, to timeout release, making the offline pre-simulation results consistent with the online running results. It should be noted that the specific parameter values, platform interface names, and system component names in the above embodiments are merely illustrative examples. Those skilled in the art will understand that adjustments can be made in actual deployments based on specific application scenarios and platform environments, but the core technical solutions of the present invention are not limited to the specific examples described above. The above description is merely a typical implementation scenario of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for pre-computing batch behavior sequences of a humanoid robot based on an arbitration flow generator, used for pre-simulating behavior sequences in offline scenarios without a real hardware environment, comprising at least the following steps: Step 1, receiving a candidate behavior pool, a sequence of emotion vectors arranged in chronological order, and an environmental snapshot as input parameters; the environmental snapshot remains unchanged throughout the iteration process, simulating a script scene where the environment is static but emotions flow; Step 2, initializing a set-type data structure in memory with an empty set of occupied joints, used to simulate the real-time occupancy status of each joint motor, without relying on bus feedback from the real hardware motor driver or application programming interface status query; Step 3, ... Step 3: Iterate through the sentiment vectors. For each iteration, use the current set of occupied joints, the current sentiment vector, and the candidate behavior pool as input to execute a complete arbitration process. The complete arbitration process includes candidate behavior selection, fuzzy inference scoring and ranking, conflict resolution, and occupation update. Step 4: If a selected behavior is generated in this round, merge the set of demand joint identifiers for the selected behavior into the set of occupied joints. Step 5: After every preset number of iterations, perform a clearing operation on the set of occupied joints to empty the set, simulating the automatic release of the joint motor after the action is completed. Step 6: After the iteration is complete, output the tuple sequence of all arbitration decisions. The joint occupancy status management in steps two through five is entirely performed in software memory. All joint identifiers are purely software identifiers and do not involve any real-time status queries of hardware motors or bus communication.

2. The method according to claim 1, characterized in that, The preset quantity threshold is 5 iterations, which corresponds to the median value of the servo control cycle for the typical duration of a humanoid robot's action.

3. The method according to claim 1, characterized in that, The arbitration process uses a generator pattern to implement lazy evaluation. Each arbitration decision is generated in real time through a lazy output mechanism when iterates to the corresponding round, rather than pre-calculating the entire sequence.

4. The method according to claim 1, characterized in that, The arbitration decision tuple includes the following fields: iteration round number, timestamp offset, selected behavior identifier, confidence score, and a list of requirement joint identifiers for that behavior.

5. The method according to claim 1, characterized in that, When no selected action is produced in this round of arbitration, an action blocking log is recorded and an empty decision is produced. In the empty decision, the action identifier is empty and the confidence level is zero.

6. A pre-computation system for batch behavior sequences of humanoid robots based on an arbitration flow generator, comprising: The input receiving module is used to receive the candidate behavior pool, the sentiment vector sequence arranged in chronological order, and the environmental snapshot; The generator module is used to iteratively execute the complete arbitration process for each sentiment vector, and to produce arbitration decision tuples round by round through lazy evaluation. The occupation management module is used to merge the set of demand joint identifiers for each selected behavior into the set of occupied joints after each round of production, and to clear the set of occupied joints according to a preset number of rounds. The output module is used to collect all arbitration decision tuples and output the complete action sequence.

7. A humanoid robot comprising a processor and a memory, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 5.

9. The system according to claim 6, characterized in that, The occupancy management module uses a memory data structure to track the joint occupancy status in software memory, without relying on the hardware motor's controller area network bus or driver application interface, thus achieving hardware-independent offline simulation.

Images