Action-based control system and omnidirectional forklift task scheduling method thereof

Abstract

The application relates to the technical field of industrial vehicle automatic control and task scheduling, and discloses a control system based on action primitives and an omnidirectional forklift task scheduling method. The omnidirectional forklift task instruction and operation state are acquired, action input parameters are formed, and action primitives carrying initial action context are generated. Action sequences and completed action sets are generated based on the input-output dependency relationship between the action primitives, and sequence version identifiers are updated after the position of the action sequence is changed, so that rearrangement influence records are formed. The current action primitive is executed, and action output parameters are generated through attribution verification. Context validity verification is performed before a subsequent action primitive reads historical action output parameters, a reuse permission result is formed, and action input parameters are updated, so that the historical action output parameters are prevented from being incorrectly reused after task insertion, avoidance or review, and the execution reliability and control constraint of the omnidirectional forklift task scheduling are improved.

Description

Technical Field

[0001] This application relates to the field of automatic control and task scheduling technology for industrial vehicles, and in particular to a control system based on motion primitives and a task scheduling method for omnidirectional forklifts. Background Technology

[0002] As the frequency of material flow in smart warehousing and flexible manufacturing scenarios continues to increase, omnidirectional forklifts are gradually taking on complex operations such as narrow aisle transfer, warehouse docking, pallet handling, temporary avoidance, and multi-workstation connection. Compared with traditional unidirectional vehicles, omnidirectional forklifts need to coordinate underlying execution resources such as vehicle movement, fork lifting and extension, and environmental perception during lateral movement, in-situ turning, and low-speed alignment. In actual warehouses, the task scheduling system may insert emergency handling tasks during vehicle movement, and avoidance actions may be triggered in the aisle due to personnel, moving shelves, or other vehicles entering. When approaching shelves or pallet holes, the vehicle also needs to perform coordinate alignment and fork status verification based on the perception results. Therefore, the task execution process of omnidirectional forklifts is usually no longer a fixed sequence of single action chains, but requires the establishment of a reconfigurable, traceable, and feedback-enabled scheduling mechanism between high-level task logic and low-level control actions.

[0003] Existing omnidirectional forklift control solutions typically break down task instructions into several low-level actions and control vehicle movement, fork movements, and perception confirmation through action queues or state machines. These solutions support sequential execution, action feedback, and exception handling, and have good engineering applicability in scenarios with stable task flows and minimal environmental changes. However, as the number of tasks inserted, aisle avoidance, and verification actions increases in warehouse operations, changes in the position of the action queue during operation become more common. In implementations lacking historical output parameter context verification mechanisms, the positioning results, perception results, or fork status results generated by completed actions may still be read by subsequent actions according to the completion time sequence or execution record index. Because these results generate… The corresponding task object, vehicle pose, coordinate reference, and underlying control resource status may have changed. If subsequent actions do not verify the correspondence between their source context and current input requirements, there may be a mismatch between the output parameters of historical actions and the input requirements of current actions. For example, after the vehicle's posture is changed by avoiding a passage, if the pallet alignment result formed before the avoidance continues to be used as the fork action input, it may affect the fork alignment. After an emergency task is inserted, if the execution results of different task objects lack source boundaries, it may also interfere with the input reception of the current task. Therefore, an omnidirectional forklift task scheduling scheme is needed that can perform source verification and access control on the output parameters of historical actions after the position of the action sequence changes. Summary of the Invention

[0004] This application proposes a control system based on motion primitives and a method for scheduling omnidirectional forklifts to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, this application adopts the following technical solution: a control system based on motion primitives, comprising:

[0006] The context building module obtains the omnidirectional forklift task instructions, collects the operation status corresponding to the omnidirectional forklift task instructions, encapsulates the task object ownership relationship and action execution conditions into action input parameters, generates action primitives carrying the initial action context based on the action input parameters, and configures the underlying control handles that match the execution type for the action primitives.

[0007] The version scheduling module obtains action primitives, generates action sequences and a set of completed actions according to the input-output dependencies between action primitives, updates the sequence version identifier after the position of the action sequence changes, and forms a reordering impact record.

[0008] The execution feedback module determines the current action primitive from the action sequence, and executes the current action primitive by combining handle dispatch, event triggering and frequency limiting polling. After the execution result passes the attribution verification, it generates action output parameters and writes the action output parameters into the completed action set.

[0009] The parameter admission module obtains the input requirements of the current action primitive and the output parameters of historical actions in the completed action set, uses context validity verification to form a reuse license result, and updates the action input parameters of the current action primitive according to the reuse license result.

[0010] Furthermore, in the context construction module, the specific operations for the action input parameters are as follows: obtain the omnidirectional forklift task instruction, use the task object attribution encapsulation method to extract the operation target information from the omnidirectional forklift task instruction and form the task object attribution relationship; collect the operation status constrained by the task object attribution relationship, and convert the operation status into an initial action context; encapsulate the action execution conditions according to the initial action context to form action input parameters with object source and context source.

[0011] Furthermore, in the context building module, the specific operations for generating action primitives are as follows: read the action input parameters, use the execution object mapping method to convert the action execution conditions in the action input parameters into action primitive types; retrieve the underlying control handle takeover conditions according to the action primitive type; bind the action input parameters and the underlying control handle takeover conditions to the same action primitive, and generate an action primitive carrying the initial action context.

[0012] Furthermore, in the version scheduling module, the specific operation for generating action sequences is as follows: obtain action primitives carrying the initial action context, adopt an input-output dependency orchestration method, identify the upstream results that must be formed first from the input requirements of the action primitives; write action primitives whose upstream results have been satisfied into the pre-execution position, and write action primitives whose upstream results have not been satisfied into the post-waiting position; after the action primitives form action output parameters, transfer the corresponding action primitives into the set of completed actions.

[0013] Furthermore, in the version scheduling module, the specific operation of reordering the impact record is as follows: after a position change occurs in the action sequence, the context offset recognition method is used to limit the offset judgment input to the position change request, the action input parameters before and after the position change, the current synchronous acquisition operation status, and the input requirements of subsequent action primitives; the offset result is formed based on the task object attribution, sequence source, coordinate reference, vehicle pose, fork status, perception context, and the source of the underlying control handle; when the task object attribution is mismatched, or the offset result exceeds the allowable offset range determined by the input requirements of subsequent action primitives, safety operating procedures, and pallet hole size margin, a new sequence version identifier is generated, and the affected output source, offset source, and corresponding review requirements are written into the reordering impact record.

[0014] Furthermore, in the execution feedback module, the specific operations performed by the current action primitive are as follows: the current action primitive is read from the action sequence, and the takeover request of the current action primitive is compared with the occupancy status of the underlying control handle using a handle takeover verification method; when the comparison result meets the takeover conditions, the current action primitive is dispatched to the corresponding underlying control handle; during the execution of the current action primitive, the underlying feedback status is read using a waiting method that combines event triggering and frequency limiting polling; the underlying feedback status is read when the underlying control handle returns a status event, and the underlying feedback status is read once when no status event returns and the polling interval determined by the rated status reporting cycle of the underlying control handle is reached, and the reading result is temporarily stored as process feedback.

[0015] Furthermore, in the execution feedback module, the specific operation for generating action output parameters is as follows: obtain the execution result returned by the underlying control handle, use the execution result attribution verification method to match the source identifier carried by the execution result with the execution context formed by the current action primitive, the underlying control handle, and the sequence version identifier; when the match is successful, convert the execution result into action output parameters, write the current sequence version and execution context into the action output parameters, and then write the action output parameters into the completed action set.

[0016] Furthermore, in the parameter admission module, the specific operations for reusing the license result are as follows: Obtain the input requirements of the current action primitive; extract candidate historical action output parameters from the completed action set according to the input-output dependency relationship; using a context validity verification method, extract the source context from the candidate historical action output parameters; match the output type, coordinate reference source, underlying control handle source, execution context valid range, and attribution verification criteria in the source context with the input context of the current action primitive; when the source context meets the input source conditions of the current action primitive and is not marked as requiring review by the rearranged impact record, a reuse license result that allows reuse is formed; when the source context is marked as requiring review by the rearranged impact record, a reuse license result with a different source is formed; when there is an object mismatch between the source context and the input context of the current action primitive, a reuse license result that prohibits reuse is formed.

[0017] Furthermore, in the parameter admission module, the specific operation for updating the action input parameters is as follows: when the reuse permission result indicates that the candidate historical action output parameters meet the input requirements of the current action primitive, the candidate historical action output parameters are written into the action input parameters of the current action primitive; when the reuse permission result has a source of difference, a review action primitive is generated based on the source of difference, and the review action primitive is written into the action sequence, so that the review action primitive can re-form the action output parameters for the current action primitive to read; when the action output parameters re-formed by the review action primitive still do not form a reuse permission result that allows reuse, a review failure record is generated, the current action primitive is kept in a waiting position and its entry into the execution feedback module is blocked; when the reuse permission result indicates that reuse is prohibited, the writing of the candidate historical action output parameters into the action input parameters of the current action primitive is blocked.

[0018] An omnidirectional forklift task scheduling method based on action primitives includes:

[0019] The context building module obtains the omnidirectional forklift task instructions, collects the operation status corresponding to the omnidirectional forklift task instructions, encapsulates the task object ownership relationship and action execution conditions into action input parameters, generates action primitives carrying the initial action context based on the action input parameters, and configures the underlying control handles that match the execution type for the action primitives.

[0020] The version scheduling module obtains action primitives, generates action sequences and a set of completed actions according to the input-output dependencies between action primitives, updates the sequence version identifier after the position of the action sequence changes, and forms a reordering impact record.

[0021] The execution feedback module determines the current action primitive from the action sequence, and executes the current action primitive by combining handle dispatch, event triggering and frequency limiting polling. After the execution result passes the attribution verification, it generates action output parameters and writes the action output parameters into the completed action set.

[0022] The parameter admission module obtains the input requirements of the current action primitive and the output parameters of historical actions in the completed action set, uses context validity verification to form a reuse license result, and updates the action input parameters of the current action primitive according to the reuse license result.

[0023] The beneficial effects of this invention are as follows:

[0024] 1. This invention first establishes action input parameters carrying the attribution relationship of task objects, and then generates action primitives carrying the initial action context using these action input parameters. It unifies the task source, operation status, and underlying control resources under the same omnidirectional forklift task object for admission, solving the problem that existing action queues are prone to misreading the execution results of other tasks after urgent order insertion or verification action intervention. This ensures that the action primitives have clear object sources and control resource boundaries before entering the action sequence, and enables subsequent action scheduling to be based on the same task object for input reception.

[0025] 2. This invention generates fork end alignment offset results based on vehicle pose, fork execution status, and pallet hole size margin after channel avoidance, coordinate realignment, or fork status verification in the action sequence. This offset result is then written into the rearrangement influence record. This ensures that historical perception results, positioning results, and fork status results no longer enter subsequent actions solely based on completion time or version number, but instead undergo fork end physical suitability access first. This solves the problem of fork insertion offset caused by the pallet alignment result continuing to drive fork insertion after omnidirectional forklift lateral movement or in-place turning. It also binds the version traceability mechanism to the low-speed alignment constraint of the omnidirectional forklift, improving the control reliability of subsequent fork action inputs.

[0026] 3. This invention performs context validity verification before reading historical action output parameters from the current action primitive. It limits the reuse permission of historical action output parameters in the completed action set to conditions that the task object is consistent, the sequence version is traceable, the execution context is corresponding, and the coordinate reference is matched. This solves the problems of delayed return results, cross-sequence results, and inconsistent coordinate reference results being mistakenly written into action input parameters. It transforms historical action output parameters from ordinary completion records into controlled input sources, and provides subsequent walking, sensing, and forklift execution processes with clearer input credibility boundaries. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort:

[0028] Figure 1 This is a system framework diagram of the present invention;

[0029] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Example 1

[0032] like Figure 1 As shown, the present invention discloses a control system based on action primitives, including: a context construction module, a version scheduling module, an execution feedback module, and a parameter admission module.

[0033] The context building module takes the omnidirectional forklift task instructions as the processing object, reads the omnidirectional forklift task instructions issued by the warehouse scheduling system, and collects the operation status corresponding to the omnidirectional forklift task instructions. The omnidirectional forklift task instructions provide the handling target and execution requirements of this omnidirectional forklift operation. The operation status provides the spatial status, execution status and control resource status of the omnidirectional forklift before the start of this task. In this step, the task object ownership relationship is first formed, and then the action input parameters and action primitives are formed based on the task object ownership relationship, so that the subsequent action output parameters can be traced back to the same task object.

[0034] The task object attribution encapsulation method uses the operation target information in the omnidirectional forklift task instruction as the processing object. The operation target information is read from the omnidirectional forklift task instruction and a task object attribution relationship is formed according to the task order generation rules, storage location coding rules, and pallet registration rules of the warehouse scheduling system. When the omnidirectional forklift task instruction contains a unique task code, the unique task code is used as the main identifier of the task object attribution relationship. When the omnidirectional forklift task instruction does not contain a unique task code, the storage location allocation information is bound to the pallet registration information to form a task object attribution relationship pointing to the target pallet and target storage location. If there are situations such as missing storage location allocation information, multiple candidate pallets corresponding to pallet registration information, or storage location allocation information and pallet registration information not being uniquely matched, an exception record is formed, and the source of the task object attribution exception is written in the exception record. No action input parameters are generated to prevent subsequent action primitives from reading the historical action output parameters corresponding to other tasks.

[0035] After establishing the task object attribution relationship, the processing object is the operation state constrained by the task object attribution relationship. The system collects the vehicle pose state, fork execution state, perception availability state, and underlying control handle state corresponding to the current task object. The vehicle pose state originates from the onboard positioning unit and represents the position and orientation of the omnidirectional forklift in the warehouse coordinate reference. The fork execution state originates from the fork control feedback unit and represents the current fork height, extension position, and load holding status. The perception availability state originates from the sensing unit and is formed based on the current sensing mode, sensing unit calibration state, and the identifiable conditions for the target object to enter the sensing field of view. The underlying control handle state originates from the control handle management unit and represents the takeover status of the underlying control resources. The perception availability state serves as the admission criterion for perception execution action primitives. Perception execution action primitives are only allowed to be generated when the current sensing mode is compatible with the current task object, the sensing unit calibration state is valid, and the target object meets the perception field of view constraints. Otherwise, a perception admission anomaly is identified, and the corresponding action primitive enters a waiting-for-review state or its generation is blocked.

[0036] The above-mentioned operational statuses must be acquired within the same synchronous acquisition window. The unit of the synchronous acquisition window is time, preferably ranging from 20ms to 200ms. The lower limit of the synchronous acquisition window is not less than the longest rated status reporting cycle among the key units participating in status acquisition. Key units include the vehicle positioning unit, fork control feedback unit, sensing unit, and control handle management unit. The upper limit of the synchronous acquisition window is determined based on the lateral offset of the fork ends caused by changes in vehicle displacement and vehicle orientation during the low-speed alignment phase, as well as the pallet hole size margin, so that the fork end offset corresponding to the vehicle posture status formed within the same window is within the allowable range of the safe operating procedures.

[0037] For the alignment and coordinate return phases before the fork insertion, the synchronous acquisition window is preferably 20ms to 100ms; for the normal handling phase and the waiting-for-takeover phase, the synchronous acquisition window is preferably 100ms to 200ms. If the rated status reporting cycle of the key unit is greater than the upper limit of the synchronous acquisition window corresponding to the current scenario, an initial action context will not be formed, and re-acquisition will be triggered or the vehicle will be allowed to enter a low-speed alignment state before acquisition. When the on-site debugging records are insufficient, the initial synchronous acquisition window will be determined based on the rated reporting cycle of the vehicle controller, the safety operating procedures, and the pallet hole size margin. After the stable execution output parameters are formed, only the successful execution records that have not been triggered for review and have not failed will be used to correct the synchronous acquisition window configuration. They will not be used to correct the task object ownership rules, the underlying control handle takeover rules, and the action primitive type mapping rules. If the complete operation status cannot be obtained within the synchronous acquisition window, the task object ownership relationship will be retained and the operation status will be re-acquired. The operation statuses of different time batches will not be combined into the same initial action context.

[0038] Subsequently, the collected work status is used as the processing object. An initial action context conversion method is employed to convert the work status into an initial action context. This initial action context conversion method includes task attribution constraints, coordinate reference attribution, execution state attribution, perception context attribution, and control resource attribution. Task attribution constraints are used to bind the collected work status to the current task object's attribution relationship. Coordinate reference attribution is used to convert the position output by the vehicle positioning unit and the vehicle's orientation to the coordinate reference corresponding to the current task object based on the warehouse coordinate calibration records. Execution state attribution is used to convert the forklift control response based on the calibration records of the forklift body coordinates and fork end coordinates. The height feedback and extension feedback output by the feed unit are converted into a fork status description under the current task object; the perception context attribution is used to convert the availability result returned by the perception unit into the perception context under the current task object based on the perception unit installation calibration record and perception mode configuration record; the control resource attribution is used to convert the control resource takeover status into the underlying control handle takeover condition based on the underlying control handle management rules. If the coordinate reference cannot complete the corresponding conversion, or the underlying control handle status cannot meet the execution requirements of this task, an exception record is formed, and the exception source is written in the exception record. The corresponding operation status is not written into the action input parameters.

[0039] After the initial action context is formed, the action execution conditions are processed and the action input parameters are formed using an attribution encapsulation method. The action execution conditions are derived from the omnidirectional forklift task instruction and the initial action context. The omnidirectional forklift task instruction provides the target execution requirements, the initial action context provides the execution pre-constraints, the target execution requirements are written into the target execution part of the action input parameters, the task object attribution relationship is written into the object source part of the action input parameters, the initial action context is written into the context source part of the action input parameters, and the underlying control handle takeover conditions are written into the control resource part of the action input parameters. The action input parameters formed in this way serve as the prerequisite for the subsequent version scheduling module to judge the input and output dependencies of action primitives, the execution feedback module to confirm the takeover status of the underlying control handle, and the parameter admission module to verify the reuse qualification of historical action output parameters.

[0040] Subsequently, using the action input parameters as the processing object, action primitives are generated using an execution object mapping method. This method reads the action execution conditions from the action input parameters and converts them into action primitive types. Action execution conditions involving vehicle movement are mapped to vehicle movement action primitives, those involving fork height and extension control are mapped to fork execution action primitives, and those involving pallet recognition and alignment confirmation are mapped to perception execution action primitives. This mapping relationship is based on the execution object division rules, underlying control handle management rules, and warehouse operation process configuration records of the omnidirectional forklift control system. If an action execution condition cannot be mapped to a unique action primitive type, an exception record is generated and written to the action primitive type exception source. The action execution condition is not encapsulated as an executable action primitive. If the same action execution condition hits multiple execution objects simultaneously, it is split into multiple action primitives according to the prerequisite input requirements and action output parameter interface types in the action execution condition. Input and output dependencies are established for the split action primitives, and mixed action primitives are not generated.

[0041] After the action primitive type is determined, the action primitive to be generated is used as the processing object. The underlying control handle takeover condition matching the action primitive type is retrieved, and the action input parameters and the underlying control handle takeover condition are bound to the same action primitive. The underlying control handle takeover condition is used to limit the control resource state that the action primitive should meet before entering the execution feedback module. Specifically, it is formed by the control handle occupancy record, the control handle return status, and the control handle parameter receiving rules. If the underlying control handle is in an occupied state, the action primitive is generated and marked as waiting for takeover, so that it enters the waiting position in the subsequent version scheduling module. If the underlying control handle return status is inconsistent with the action primitive type, an exception record is formed and the underlying control handle exception source is written, blocking the action primitive from entering the version scheduling module. This process is used to avoid control resource mismatch during the formation stage of the action primitive and to make the underlying control handle takeover condition play an execution admission role in the subsequent action sequence generation.

[0042] An action primitive includes an action primitive identifier, an action primitive type, action input parameters, an action output parameter interface, a lifecycle state, and a low-level control handle takeover condition. The action primitive identifier is formed using the task object primary key, the action primitive type code, and the context batch number, used to distinguish different action instances under the same omnidirectional forklift task instruction. The action primitive type is used to limit the execution object corresponding to the action primitive. The action input parameters are used to provide the basis for execution. The action output parameter interface is used to carry the execution result after the action is executed. The lifecycle state is used to indicate that the action primitive is in one of the following process states: waiting to be taken over, executing, executing, or executing and failing. The low-level control handle takeover condition is used to limit whether the action primitive can be taken over by the execution feedback module. The above contents are bound to the same action primitive, so that the action primitive has an object source, a context source, and a control resource source.

[0043] After the action primitives are generated, the input-output relationship between them is used as the processing object. Input-output dependencies between action primitives are established. The action input parameters and action output parameters of each action primitive are read. The object source, output type, sequence source, and context source of the input requirement are used as matching conditions to identify whether the action primitive depends on the pose confirmation result, perception confirmation result, and fork state confirmation result formed by other action primitives. If a unique upstream action primitive exists, an input-output dependency relationship is established between the upstream action primitive and the subsequent action primitive that reads its output result. If multiple candidate upstream action primitives exist, the task object is selected first. Candidate upstream action primitives with consistent attribution and sequence sources satisfying the current action chain are selected. Then, within this candidate range, the candidate upstream action primitive with matching output type and context batch time closest to the current action primitive's input requirement is selected. If a candidate upstream action primitive still cannot be uniquely determined, the current action primitive is marked as having an input pending completion state. If there is no candidate upstream action primitive and the input requirement cannot be directly satisfied by the initial action context, the action primitive is marked as having an input pending completion state. Through this process, the subsequent version scheduling module can write action primitives whose upstream results have been satisfied into the executable position and write action primitives whose upstream results have not yet been satisfied into the waiting position.

[0044] Through the above processing, an action primitive set carrying the initial action context is output. This action primitive set includes the task object ownership relationship, action input parameters, initial action context, action primitive type, underlying control handle takeover conditions, and input-output dependencies. After entering the version scheduling module, the version scheduling module generates an action sequence and a set of completed actions based on the input-output dependencies between the action primitives. After entering the execution feedback module, the execution feedback module performs handle dispatch and wait combining event triggering and frequency limiting polling based on the underlying control handle takeover conditions carried by the action primitives. After entering the parameter admission module, the parameter admission module performs context validity verification on the historical action output parameters in the completed action set based on the object source and context source in the action input parameters. Thus, the context construction module provides a verifiable object ownership basis, context basis, and control resource basis for the reuse control of historical action output parameters after the position of the action sequence changes.

[0045] The version scheduling module takes the set of action primitives carrying the initial action context output by the context building module as the processing object, reads the action input parameters, action output parameter interfaces, underlying control handle takeover conditions and input-output dependencies of each action primitive, and generates action sequences and sets of completed actions by using input-output dependency orchestration. The action sequences are used to store action primitives that have not yet been executed, and the sets of completed actions are used to store action primitives that have generated action output parameters.

[0046] When generating an action sequence, the action input parameters and action output parameters of the action primitive are read. The object source, output type, sequence source, and context source of the input requirement are used as matching conditions to identify the upstream result that the action primitive needs to obtain before execution. The sequence source is determined by the current sequence version identifier and the action sequence in which the action primitive belongs, used to limit whether the upstream result belongs to the action sequence under the current task object. If the input requirement can be directly satisfied by the initial action context, the corresponding action primitive is written to the pre-execution position of the action sequence. If the input requirement depends on the action output parameters formed by other action primitives, the action primitive is adjusted from the waiting position to the executable position after the corresponding upstream action primitive forms the action output parameters. If the input requirement cannot be satisfied by the initial action context and there is no matching upstream action primitive, the action primitive is written to the waiting position. Thus, the execution position in the action sequence is determined by whether the input source is satisfied, preventing the action primitive from entering the execution process when there is a lack of upstream results.

[0047] In one program implementation, the action sequence uses a double-ended queue to store the action primitives to be executed, and the completed action set uses a vector to store the completed action primitives. The double-ended queue supports the change of the position of the action primitives in the action sequence, and the vector stores the action primitives that have formed action output parameters and their output sources. The above containers are only used as the preferred program implementation of the action sequence and the completed action set, and do not change the input-output dependency relationship between the action primitives.

[0048] After the action sequence is generated, an initial sequence version identifier is generated. The initial sequence version identifier is formed by the task object affiliation, the initial action context, and the initial action sequence. It is used to identify the initial arrangement state of the action sequence under the current task object. When the position of the action sequence has not changed, the action output parameters formed after the action primitive is executed are written into the completed action set along the current sequence version. When the position of the action sequence changes, the sequence version identifier is updated so that the historical action output parameters can be traced back to the sequence version when they were generated.

[0049] When the position of an action sequence changes, the version scheduling module uses a version identifier generation function to generate a new sequence version identifier and simultaneously writes it to the sequence version tracing index. The sequence version tracing index includes the previous sequence version identifier, the new sequence version identifier, the position change operation type, the changed action primitive identifier, the changed sequence position, the current action context summary, and the rearrangement impact record number. The version identifier generation function is only used to generate a deterministic identifier based on the previous sequence version identifier, the position change operation type, the changed action primitive identifier, the changed sequence position, and the current action context summary. The output result is not assigned physical dimension meaning and is not used for dimension conversion, action primitive priority sorting, or low-level control parameter calculation. Tracing between the source sequence version and the current sequence version is completed by searching step by step through the previous sequence version identifier in the sequence version tracing index. If it is possible to trace back from the current sequence version to the source sequence version during the search process, the source sequence version is determined to have a traceable relationship. If the tracing chain is broken, the tracing index is missing, or there is a rearrangement impact record related to the candidate historical action output parameter in the tracing path, the candidate historical action output parameter is determined to be unusable.

[0050] Location changes are processed using the change action primitives in the action sequence. Location changes are triggered by location change requests in the action sequence, which originate from the warehouse scheduling system, environmental perception results, verification requirements generated by the parameter access module, or action status results returned by the execution feedback module. Specifically, urgent order insertion originates from the warehouse scheduling system, aisle avoidance originates from the warehouse scheduling system or environmental perception results, and perception verification, coordinate realignment, and forklift status verification originate from verification requirements generated by the parameter access module or action status results returned by the execution feedback module. The version scheduling module reads the location change operation and action input of the change action primitives. The parameters, action primitive identifier, underlying control handle takeover conditions, and current action context at the time of location change are compared with the sequence version before the location change. If the task object ownership relationship is consistent before and after the location change, the sequence version identifier can be traced from the version before the location change to the version after the location change, and the current action context after the change still meets the input requirements of subsequent action primitives, only the sequence version identifier is updated. If the task object ownership relationship is mismatched, or the current action context after the change cannot meet the input requirements of subsequent action primitives for output source, coordinate reference, and underlying control handle takeover conditions, a rearrangement impact record is formed.

[0051] The context offset recognition method does not use candidate historical action output parameters as offset determination input. Its offset determination input is limited to position change requests, action input parameters before and after position changes, current synchronous acquisition operation status, and input requirements of subsequent action primitives. Offset results include task object attribution offset, sequence source offset, coordinate reference offset, vehicle pose offset, fork state offset, perception context offset, and underlying control handle source offset. Task object attribution offset is determined based on whether the task object's main identifier, target pallet identifier, and target storage location identifier are consistent; sequence source offset is determined based on whether the sequence version tracing index can trace back from the current sequence version to the source sequence version; coordinate reference offset is determined based on whether the coordinate reference identifiers are consistent and whether the residual after coordinate reference transformation is within the allowable residual range corresponding to the current action element input requirements; vehicle pose offset is determined based on whether the difference in vehicle position and vehicle orientation before and after the position change is within the pose range allowed by subsequent action elements; fork status offset is determined based on whether the fork height, extension position, and load holding status meet the input requirements of subsequent action elements; perception context offset is determined based on whether the perception mode, calibration status, and target object field of view constraints still meet the input requirements of subsequent action elements; and underlying control handle source offset is determined based on whether the underlying control handle type, resource identifier, and occupancy / release record correspond to the execution object required by the current action element. The allowable residual for coordinate reference used for fork alignment is preferably 5mm to 30mm, and the allowable deviation for vehicle body orientation is preferably 0.5° to 3°; the allowable residual for coordinate reference used for general handling connections is preferably 30mm to 100mm, and the allowable deviation for vehicle body orientation is preferably 2° to 10°. The values ​​of allowable residuals and deviations are derived from safety operating procedures, pallet hole size allowances, the accuracy of the on-board positioning unit, and on-site debugging records; when on-site debugging records are insufficient, conservative values ​​are determined using safety operating procedures and pallet hole size allowances.

[0052] The rearrangement impact record takes the output source affected by the position change as the processing object. The version scheduling module determines the output source in the completed action set that may be read by subsequent action primitives based on the input-output dependency relationship between action primitives. Then, based on the position change operation and the current action context, it determines whether the output source still meets the input requirements of the subsequent action primitive. If the affected output source no longer meets the input requirements of the subsequent action primitive, the affected output source, offset source, and corresponding review requirements are written into the rearrangement impact record. The offset source is used to characterize the source of change in object ownership, sequence source, or execution context. The corresponding review requirements are used to limit the type of action output parameters that need to be re-formed in the future. If the position change only changes the waiting order and does not change the input source conditions of the historical action output parameters, no corresponding review requirements are formed.

[0053] When an urgent order insertion causes a position change, the version scheduling module determines whether the urgent order action primitive belongs to the current task object. If the urgent order action primitive belongs to a different task object, the change in object affiliation is written into the rearrangement impact record, and the action output parameters generated by the urgent order action are restricted from being directly reused as historical action output parameters of the current task object. When a passage avoidance causes a position change, the version scheduling module determines whether the avoidance action changes the vehicle pose context. If the vehicle pose context shifts relative to the input requirements of subsequent action primitives after the avoidance, the source of the pose shift is written into the rearrangement impact record. When a perception verification, coordinate alignment, and fork status verification cause a position change, the version scheduling module determines whether the corresponding position change changes the applicable context of historical perception results, positioning results, or fork status results. If it changes, the corresponding verification requirement is written into the rearrangement impact record.

[0054] The rearrangement of the impact record does not change the underlying control action, nor does it modify the output parameters of the historical action in the set of completed actions. Its downstream function is to determine whether the output parameters of the historical action are allowed to be reused, whether they need to be reviewed, and whether to block the writing of action input parameters when the parameter admission module performs context validity verification.

[0055] After an action primitive in an action sequence generates action output parameters, the action primitive is transferred from the action sequence to the completed action set. When transferring to the completed action set, the sequence version identifier and the source of the action output parameters corresponding to the action primitive are retained, so that the completed action set records the sequence version corresponding to when the action output parameters were generated. If the action primitive is marked as waiting to be taken over, it is retained in the waiting position of the action sequence. If the action primitive is marked as input to be completed, the parameter admission module generates a reuse permission result based on the historical action output parameters. If the action primitive is blocked due to abnormal recording, it is not written to the completed action set, and the source of the abnormality is retained.

[0056] Through the above processing, the version scheduling module outputs an action sequence with a sequence version identifier, a set of completed actions, and a reordering impact record. After this output enters the execution feedback module, the execution feedback module determines the current action primitive from the action sequence and performs handle dispatch and event triggering combined with frequency limiting polling. After this output enters the parameter admission module, the parameter admission module determines whether the output parameters of the historical actions in the set of completed actions meet the input requirements of the current action primitive based on the reordering impact record. The version scheduling module provides a version basis and a review trigger basis for the reuse control of the output parameters of historical actions after the position of the action sequence changes, through the sequence version identifier and the reordering impact record.

[0057] The execution feedback module takes the action sequence output by the version scheduling module as the processing object, reads the current action primitive in the action sequence, and reads the action input parameters, underlying control handle takeover conditions, sequence version identifier and input-output dependencies carried by the current action primitive. The action sequence is used to limit the action primitive that should be executed. The action input parameters are used to limit the task object, target execution conditions and context source of the current action primitive. The underlying control handle takeover conditions are used to limit whether the current action primitive can enter the underlying execution process. The sequence version identifier is used to limit whether the execution result returned by the underlying layer belongs to the current action sequence version.

[0058] Before executing the current action primitive, the takeover request of the current action primitive is taken as the processing object. A handle takeover verification method is used to determine whether the underlying control handle meets the execution conditions. The handle takeover verification method reads the takeover conditions of the underlying control handle and reads the occupancy status, return status, and parameter receiving status of the underlying control handle. When the underlying control handle is not occupied by other action primitives, the return status is consistent with the action primitive type of the current action primitive, and it can receive the action input parameters of the current action primitive, a takeover verification result that allows dispatch is formed, and the control handle occupancy record corresponding to the current action primitive is written before dispatch; when the underlying control handle is not occupied by other action primitives, the return status is consistent with the action primitive type of the current action primitive, and it can receive the action input parameters of the current action primitive, a takeover verification result that allows dispatch is formed, and a control handle occupancy record corresponding to the current action primitive is written before dispatch; when the underlying control handle is not occupied by other action primitives, the takeover verification method is taken as follows: If the control handle is occupied, the return status is inconsistent with the action primitive type, or the current action input parameters cannot be received, a takeover verification result indicating that dispatch is not allowed is generated. If the underlying control handle does not acknowledge receiving the execution request after the control handle occupancy record is written, the corresponding control handle occupancy record is released, and the current action primitive is kept in the waiting position in the action sequence. If the underlying control handle has acknowledged receiving the execution request but returns a failure result, the corresponding control handle occupancy record is released after the current action primitive enters the execution failure state. This process makes the underlying control handle takeover condition play an execution admission role, avoiding multiple action primitives occupying the same underlying control handle at the same time.

[0059] After a takeover verification result indicating that dispatch is permitted is generated, the current action primitive is used as the processing object. The current action primitive is executed using the handle dispatch method. The handle dispatch method dispatches the current action primitive to the underlying control handle that matches its execution type based on the action primitive type of the current action primitive. The action input parameters, action primitive identifier, and current sequence version identifier are written into the underlying execution request. Vehicle movement action primitives, fork execution action primitives, and perception execution action primitives are dispatched to the underlying control handle that matches their execution type, respectively. The action primitive identifier and current sequence version identifier carried in the underlying execution request serve as the source of subsequent execution result attribution verification and do not participate in action priority sorting.

[0060] During the execution of the current action primitive, the underlying feedback status returned by the underlying control handle is the processing object. A waiting method combining event triggering and frequency-limited polling is used to read the underlying feedback status. Event triggering is used to wake up the execution feedback module when the underlying control handle returns a receive, complete, fail, refuse takeover, or status change event. Frequency-limited polling is used to read the underlying feedback status once at a polling interval when the underlying control handle has not returned a status event. The polling interval is in time, preferably 20ms to 500ms, and is determined by the rated status reporting cycle of the underlying control handle, the equipment safety configuration, and the current action type. The polling interval for vehicle movement action primitives and forklift execution action primitives is preferably 20ms to 200ms, and the polling interval for perception execution action primitives is preferably 100ms to 500ms. The execution feedback module releases processor scheduling resources between two event triggers or two frequency-limited polling, enabling the vehicle controller to continue performing positioning, perception, safety monitoring, and communication tasks. Process feedback is only used for the lifecycle state transition of the current action primitive and is not written to the action output parameters and the set of completed actions before the execution result passes the attribution verification.

[0061] When the rated status reporting period of the current underlying control handle exceeds the preferred range, the status confirmation interval allowed by the equipment safety configuration shall be used, and the current action primitive shall enter the waiting confirmation state. The value of the reading period shall be based on the rated status reporting period of the underlying control handle, the equipment safety configuration, and the on-site debugging record. When the valid successful execution record of the same type of action cannot cover the current action type and the current operation scenario, the rated status reporting period of the underlying control handle shall be used as the initial reading period. The read underlying feedback status shall be temporarily stored as the process feedback of the current action primitive. The process feedback shall only be used for the life cycle status flow of the current action primitive. Before the execution result passes the attribution verification, it shall not be written into the action output parameters and the set of completed actions.

[0062] During the waiting process combining event triggering and frequency limiting polling, the lifecycle state of the current action primitive flows according to the underlying feedback state. After the current action primitive is received by the underlying control handle, it enters the execution state; after the underlying control handle returns a completion result, it enters the execution completed state; when the underlying control handle returns a failure result, a takeover refusal result, or fails to return an execution result after exceeding the action waiting limit, it enters the execution failed state. The unit of the action waiting limit is time. The action waiting limit for vehicle movement action primitives is formed based on the target path length, vehicle speed limit, and safe stopping confirmation time, preferably 3s to 180s; the action waiting limit for fork execution action primitives is formed based on the fork target displacement, fork rated moving speed, and arrival confirmation time, preferably 1s to 60s; the action waiting limit for perception execution action primitives is formed based on the perception mode processing cycle and result confirmation time, preferably 0.5s to 15s.

[0063] The above range is used for waiting control of a single action primitive. When the estimated execution time of a vehicle movement task exceeds the action waiting limit of a vehicle movement action primitive, the vehicle movement task is split into multiple vehicle movement action primitives, and the input-output dependencies between the split action primitives are established according to the path sequence. The parameters of the action waiting limit are derived from the omnidirectional forklift equipment safety configuration, the action type configuration of the underlying control handle, and on-site debugging records. When the valid successful execution records of the same type of action cannot cover the current action type and the current work scenario, the maximum allowed execution time of the corresponding action type in the equipment safety configuration is used as the initial action waiting limit. The equipment safety configuration serves as the hard boundary of the action waiting limit. On-site debugging records are only used to correct the action waiting limit within the hard boundary. The action waiting limit is used to determine whether the current action primitive should continue to wait for the execution result. It is not used to update the action input parameters or modify the set of completed actions.

[0064] After the underlying control handle returns the execution result, the execution result is used as the processing object. The execution result attribution verification method is used to determine whether the execution result belongs to the current action primitive. The execution result attribution verification method reads the source identifier carried by the execution result and matches the source identifier with the execution context formed by the current action primitive, the underlying control handle, and the sequence version identifier. The source identifier comes from the underlying execution request written when dispatching the current action primitive. If the underlying control handle can return the source identifier, the matching is performed directly based on the returned source identifier. If the underlying control handle cannot return the source identifier, the matching is performed based on the underlying execution request, the underlying feedback channel, and the return time. The return time should fall within the action waiting limit of the current action primitive, and the corresponding underlying control handle should only have the current action primitive's control handle occupation record during this time period.

[0065] If the source identifier or corresponding matching result carried by the execution result is consistent with the current execution context, a result of successful attribution verification is formed; otherwise, a result of failed attribution verification is formed. Execution results of failed attribution verification form non-current attribution records and are not written into the process feedback, action output parameters and completed action set of the current action primitive. This process enables attribution verification to play the role of result admission and prevents the execution results of other action primitives, other underlying control handles or other sequence versions from entering the current action primitive.

[0066] After the attribution verification passes, the execution result that passed the attribution verification is used as the processing object. The execution result is converted into action output parameters. The action output parameters are written with the execution result, the action primitive identifier of the current action primitive, the current sequence version identifier, the execution context, and the source of the underlying control handle. The action output parameters corresponding to vehicle movement action primitives include the vehicle arrival status and the position confirmation result under the coordinate reference; the action output parameters corresponding to fork execution action primitives include the fork position status and the fork execution result; the action output parameters corresponding to perception execution action primitives include the perception confirmation result and the corresponding coordinate reference source. The above action output parameters are formed by the execution result returned by the underlying control handle and the execution context of the current action primitive, and are used by the parameter admission module to determine whether the historical action output parameters meet the input requirements of the current action primitive.

[0067] After the action output parameters are generated, the corresponding action primitive and action output parameters are written to the completed action set. When writing to the completed action set, the sequence version identifier and execution context corresponding to the generation of the action output parameters are retained, so that the completed action set records the source version, source action primitive, and source underlying control handle of the action output parameters. If the current action primitive enters the execution failure state, or the execution result fails the attribution verification, the execution result will not be written to the completed action set. If the current action primitive does not enter the execution process due to the underlying control handle being occupied, it will remain in the waiting position of the action sequence. If the input source of the current action primitive is insufficient, the parameter admission module will form a reuse permission result based on the historical action output parameters. Thus, execution failure results and execution results that fail the attribution verification will not enter the completed action set to avoid affecting the reuse verification of subsequent historical action output parameters.

[0068] Through the above processing, the execution feedback module outputs the updated action sequence, the set of completed actions, and action output parameters carrying the execution context. After this output enters the parameter admission module, the parameter admission module performs context validity verification on the historical action output parameters in the set of completed actions based on the sequence version identifier, execution context, and source of the underlying control handle in the action output parameters. The execution feedback module converts the underlying execution process into action output parameters with source, version, and execution context boundaries to avoid mismatch of the underlying execution result to other action primitives after the position of the action sequence changes.

[0069] The parameter admission module takes the input requirements of the current action primitive and the output parameters of historical actions in the completed action set as its processing objects. It reads the input-output dependencies formed by the context building module, the sequence version identifier and rearrangement impact record formed by the version scheduling module, and the action output parameters written into the completed action set by the execution feedback module. The input requirements of the current action primitive are used to limit the upstream results that need to be obtained before execution, the historical action output parameters are used to provide candidate input sources, and the rearrangement impact record is used to limit whether the historical action output parameters still meet the input requirements of the current action primitive after the position of the action sequence changes.

[0070] When the current action primitive needs to read the upstream output, candidate historical action output parameters are extracted from the set of completed actions according to the input-output dependency relationship. The extraction process is constrained by the input requirements of the current action primitive. Historical action output parameters that can provide the corresponding output type are read. The latest write result in the set of completed actions is not used as the default input. If the output type of the historical action output parameter cannot meet the input requirements of the current action primitive, or if it has not been written to the set of completed actions, it is not used as a candidate historical action output parameter.

[0071] After extracting the candidate historical action output parameters, the source context is extracted from the candidate historical action output parameters, and the input context is extracted from the action input parameters of the current action primitive. The source context is formed by the task object ownership relationship, action primitive identifier, sequence version identifier, execution context, source of underlying control handle, source of coordinate reference, and ownership verification criteria written in the candidate historical action output parameters. Its input source is the action output parameters generated by the execution feedback module. The input context is formed by the task object ownership relationship, input requirements, context source, takeover conditions of underlying control handle, and coordinate reference requirements of the current action primitive. Its input source is the action input parameters generated by the context construction module and the current sequence version identifier maintained by the version scheduling module. The source context and input context serve as intermediate judgment results for context validity verification and are not issued as underlying control commands.

[0072] After the source context and input context are formed, a reuse license result is generated using a context validity check. The context validity check is performed in the order of task object attribution, sequence version influence, and input context matching. If the previous check fails, the next check is not performed. Task object attribution is used to exclude historical action output parameters that do not belong to the current task object or whose source is incomplete. Sequence version influence is used to determine whether changes in the action sequence position block the reuse of historical action output parameters. Input context matching is used to determine whether the remaining candidate historical action output parameters meet the input requirements of the current action primitive.

[0073] During task object attribution verification, if the task object corresponding to the source context is inconsistent with the task object of the current action primitive, or if the candidate historical action output parameter lacks an identifiable task object attribution relationship, a reuse permission result prohibiting reuse will be formed, and the writing of the candidate historical action output parameter into the action input parameter of the current action primitive will be blocked.

[0074] When the task object ownership is consistent, the source sequence version in the candidate historical action output parameter is read and compared with the sequence version identifier corresponding to the current action sequence. If the source sequence version can be traced back to the current sequence version and there is no reordering impact record related to the candidate historical action output parameter, the input context matching continues. If the reordering impact record marks the candidate historical action output parameter as needing review, a reuse permission result with the source of difference is formed. If the source sequence version is missing or cannot be traced back to the current sequence version, a reuse permission result prohibiting reuse is formed. The source of difference is determined by the offset source in the reordering impact record, which is used to indicate that the historical action output parameter cannot be directly reused due to changes in object ownership, sequence source, or execution context.

[0075] When the sequence version is not affected by the reordering of records, the source context is matched with the input context of the current action primitive. Matching is performed in the following order: output type matching, coordinate reference matching, underlying control handle source matching, execution context valid range matching, and attribution verification basis matching. Output type matching is based on the action output parameter interface definition. If the output type code of the candidate historical action output parameter matches the input type code in the current action primitive's input requirements, or if there is a compatible relationship between the two in the action output parameter interface mapping table, then the output type is considered to match. Coordinate reference matching is based on the coordinate reference identifier and coordinate transformation residual. If the coordinate reference identifiers match, then a match is considered. If the coordinate reference identifiers do not match, but the transformation can be completed through the coordinate reference attribution relationship formed by the context construction module, and the transformation residual is within the allowable residual range of the current action primitive, then a match is considered. Underlying control handle source matching is based on the underlying control handle type, resource identifier, and occupation / release record. If the underlying control handle source corresponding to the candidate historical action output parameter matches the execution object required by the current action primitive, and no corresponding control resource reset, release anomaly, or cross-task occupation record occurs after the source action primitive completes, then a match is considered. The effective range matching of execution context is based on the task object attribution relationship, sequence version tracing relationship, synchronous acquisition window, and action waiting limit. A match is determined when the source context can be traced back to the current sequence version and has not been marked as requiring review due to being affected by reordering. Attribution verification basis matching is based on the attribution verification basis passed by the action output parameters written by the execution feedback module. If the candidate historical action output parameters lack attribution verification basis, a reuse permission result is generated that prohibits reuse. If all the above matches are true, a reuse permission result is generated that allows reuse. If the task object attribution relationship is consistent, but the coordinate reference, execution context, or underlying control handle source needs to be reconfirmed, a reuse permission result with differing sources is generated. If the source context is missing, lacks attribution verification basis, or the source context cannot establish a correspondence with the current input context, a reuse permission result that prohibits reuse is generated.

[0076] When the reuse permission result indicates that reuse is allowed, the candidate historical action output parameters are written into the action input parameters of the current action primitive. When writing, the source action primitive identifier, source sequence version identifier and execution context of the candidate historical action output parameters are retained, so that the current action primitive can trace its input source when it is executed in the execution feedback module later.

[0077] When the reuse license result has a source of difference, the candidate historical action output parameters are not directly written into the action input parameters of the current action primitive. Instead, a verification action primitive is generated based on the source of difference, and the verification action primitive is written into the action sequence. If the source of difference points to a change in vehicle pose or coordinate reference, a verification action primitive for re-forming the position confirmation result is generated. If the source of difference points to a change in the context applicable to the perception confirmation result, a verification action primitive for re-forming the perception confirmation result is generated. If the source of difference points to a change in the fork state, a verification action primitive for re-forming the fork execution result is generated. The above mapping relationship comes from the input requirements in the action input parameters, the offset source in the rearrangement influence record, and the output type in the action output parameter interface. The verification action primitive follows the action primitive generation method in the context construction module and enters the action sequence according to the action sequence position change rules of the version scheduling module. After the verification action primitive is executed, new action output parameters are generated in the execution feedback module. The newly generated action output parameters are then entered into the parameter admission module for context validity verification.

[0078] When the reuse permission result indicates that reuse is prohibited, the writing of candidate historical action output parameters into the action input parameters of the current action primitive is blocked, and the source of the prohibited reuse is retained. The source of the prohibited reuse is used to indicate that the candidate historical action output parameter is blocked due to inconsistent task object ownership, incomplete source context, lack of ownership verification basis, or source context not corresponding to the current input context. The candidate historical action output parameter that is prohibited from reuse is not written into the action input parameters of the current action primitive, does not enter the action primitive generation process for review, and is not used as a substitute source for other candidate historical action output parameters.

[0079] When multiple candidate historical action output parameters exist for the same current action primitive, conflict handling is performed according to the input requirements of the current action primitive, prioritizing the candidate historical action output parameter that forms a reuse license result that allows reuse. When multiple candidate historical action output parameters all form reuse license results that allow reuse, the candidate historical action output parameter corresponding to the upstream action primitive specified by the input-output dependency relationship is prioritized. If multiple candidates still meet the condition, the candidate historical action output parameter that does not have a reordering effect record that blocks reuse between the source sequence version and the current sequence version, and whose execution context is consistent with the current input context, is selected. If a reusable candidate still cannot be uniquely determined, no candidate historical action output parameter is written into the action input parameter of the current action primitive, and a reuse license result with a different source is generated to trigger the generation of a review action primitive.

[0080] If all input requirements of the current action primitive are met through reuse permission results, or if the action output parameters re-formed by the reviewed action primitive re-enter the parameter admission module and form a reuse permission result, the action input parameters of the current action primitive are updated, and the current action primitive is allowed to enter the subsequent execution feedback process. If the re-formed action output parameters of the reviewed action primitive still form a reuse permission result with a source of difference after re-entering the parameter admission module, the parameter admission module determines whether to allow further review based on the source of difference; the number of further reviews is preferably no more than 2, and the number is derived from equipment safety configuration, on-site debugging records, and warehouse operation procedures. If a reuse permission result cannot be formed after reaching the upper limit of the number of further reviews, a review failure record is generated, the current action primitive is kept in the waiting position in the action sequence, the current action primitive is blocked from entering the execution feedback module, and a manual takeover prompt or task replanning request is output to the warehouse scheduling system. When the regenerated action output parameters of a review action primitive result in a reuse permission result that prohibits reuse, no new review action primitive is generated. Instead, a review failure record is generated directly, and the corresponding historical action output parameters are blocked from being written into the action input parameters of the current action primitive. The review failure record is not written into the completed action set, nor is it used as a candidate historical action output parameter for subsequent action primitives.

[0081] Through the above processing, the parameter admission module outputs the reuse permission result, the updated action input parameters, and the verification action primitive. The reuse permission result is used to identify the status of historical action output parameters as allowed to be reused, requiring verification, or prohibited from being reused. The updated action input parameters are used for the current action primitive to enter the execution feedback module for execution. The verification action primitive is used to regenerate action output parameters that meet the input requirements of the current action primitive. The parameter admission module restricts the historical action output parameters in the completed action set to be the input source of action input parameters only after the context validity is verified, in order to avoid the historical action output parameters being incorrectly reused after the position of the action sequence changes.

[0082] Example 2

[0083] like Figure 2 As shown, this invention discloses an omnidirectional forklift task scheduling method based on action primitives, including:

[0084] Obtain omnidirectional forklift task instructions, collect the operation status corresponding to the omnidirectional forklift task instructions, encapsulate the task object ownership relationship and action execution conditions into action input parameters, generate action primitives carrying initial action context based on action input parameters, and configure underlying control handles matching the execution type for action primitives;

[0085] Obtain action primitives, generate action sequences and a set of completed actions according to the input-output dependencies between action primitives, and update the sequence version identifier after the position of the action sequence changes, forming a rearrangement impact record;

[0086] The current action primitive is determined from the action sequence. The current action primitive is executed using a waiting method that combines handle dispatch, event triggering and frequency limiting polling. After the execution result passes the attribution verification, the action output parameters are generated and written into the set of completed actions.

[0087] Obtain the input requirements of the current action primitive and the output parameters of historical actions in the completed action set, use context validity verification to form a reuse license result, and update the action input parameters of the current action primitive according to the reuse license result.

[0088] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A control system based on motion primitives, characterized in that, include: The context building module obtains the omnidirectional forklift task instructions, collects the operation status corresponding to the omnidirectional forklift task instructions, encapsulates the task object ownership relationship and action execution conditions into action input parameters, generates action primitives carrying the initial action context based on the action input parameters, and configures the underlying control handles that match the execution type for the action primitives. The version scheduling module obtains action primitives, generates action sequences and a set of completed actions according to the input-output dependencies between action primitives, updates the sequence version identifier after the position of the action sequence changes, and forms a reordering impact record. The execution feedback module determines the current action primitive from the action sequence, and executes the current action primitive by combining handle dispatch, event triggering and frequency limiting polling. After the execution result passes the attribution verification, it generates action output parameters and writes the action output parameters into the completed action set. The parameter admission module obtains the input requirements of the current action primitive and the output parameters of historical actions in the completed action set, uses context validity verification to form a reuse license result, and updates the action input parameters of the current action primitive according to the reuse license result.

2. The control system based on action primitives according to claim 1, characterized in that, In the context construction module, the specific operations of the action input parameters are as follows: obtain the omnidirectional forklift task instruction, use the task object attribution encapsulation method to extract the operation target information from the omnidirectional forklift task instruction and form the task object attribution relationship; collect the operation status constrained by the task object attribution relationship, and convert the operation status into the initial action context; encapsulate the action execution conditions according to the initial action context to form action input parameters with object source and context source.

3. The control system based on action primitives according to claim 1, characterized in that, In the context building module, the specific operations for generating action primitives are as follows: read the action input parameters, use the execution object mapping method to convert the action execution conditions in the action input parameters into action primitive types; retrieve the underlying control handle takeover conditions according to the action primitive type; bind the action input parameters and the underlying control handle takeover conditions to the same action primitive, and generate an action primitive carrying the initial action context.

4. A control system based on action primitives according to claim 1, characterized in that, In the version scheduling module, the specific operation for generating action sequences is as follows: obtain action primitives carrying the initial action context, adopt an input-output dependency orchestration method, identify the upstream results that must be formed first from the input requirements of the action primitives; write action primitives whose upstream results have been satisfied into the pre-execution position, and write action primitives whose upstream results have not yet been satisfied into the post-waiting position. After the action primitive generates the action output parameters, the corresponding action primitive is transferred to the set of completed actions.

5. A control system based on action primitives according to claim 1, characterized in that, In the version scheduling module, the specific operation of rearranging the impact record is as follows: after the action sequence generates a position change, the context offset recognition method is used to limit the offset judgment input to the position change request, the action input parameters before and after the position change, the current synchronous acquisition job status, and the input requirements of subsequent action primitives. The offset result is generated based on the task object's affiliation, sequence source, coordinate reference, vehicle pose, fork status, perception context, and the source of the underlying control handle. When a task object is mismatched, or when the offset result exceeds the allowable offset range determined by the input requirements of subsequent action primitives, safety operating procedures, and pallet hole size margin, a new sequence version identifier is generated, and the affected output source, offset source, and corresponding review requirements are written into the rearrangement impact record.

6. A control system based on action primitives according to claim 1, characterized in that, In the execution feedback module, the specific operations performed by the current action primitive are as follows: the current action primitive is read from the action sequence, and the takeover request of the current action primitive is compared with the occupancy status of the underlying control handle using a handle takeover verification method; when the comparison result meets the takeover conditions, the current action primitive is dispatched to the corresponding underlying control handle; during the execution of the current action primitive, the underlying feedback status is read using a waiting method that combines event triggering and frequency limiting polling; the underlying feedback status is read when the underlying control handle returns a status event, and the underlying feedback status is read once when no status event returns and the polling interval determined by the rated status reporting cycle of the underlying control handle is reached, and the reading result is temporarily stored as process feedback.

7. A control system based on action primitives according to claim 1, characterized in that, In the execution feedback module, the specific operation for generating action output parameters is as follows: obtain the execution result returned by the underlying control handle, use the execution result attribution verification method to match the source identifier carried by the execution result with the execution context formed by the current action primitive, the underlying control handle, and the sequence version identifier; when the match is successful, convert the execution result into action output parameters, write the current sequence version and execution context into the action output parameters, and then write the action output parameters into the completed action set.

8. A control system based on action primitives according to claim 1, characterized in that, In the parameter admission module, the specific operation of reusing the license result is as follows: obtain the input requirements of the current action primitive, and extract the candidate historical action output parameters from the set of completed actions according to the input-output dependency relationship; A context validity verification method is adopted to extract the source context from the output parameters of candidate historical actions. The output type, coordinate reference source, underlying control handle source, execution context validity range, and attribution verification criteria in the source context are matched with the input context of the current action primitive. When the source context meets the input source conditions of the current action primitive and is not marked as requiring review by the rearranged impact record, a reuse license result that allows reuse is formed. When the source context is marked as requiring review by the rearranged impact record, a reuse license result with a difference source is formed. When there is an object mismatch between the source context and the input context of the current action primitive, a reuse license result that prohibits reuse is formed.

9. A control system based on action primitives according to claim 1, characterized in that, In the parameter admission module, the specific operation for updating action input parameters is as follows: when the reuse permission result indicates that the candidate historical action output parameters meet the input requirements of the current action primitive, the candidate historical action output parameters are written into the action input parameters of the current action primitive; when the reuse permission result has a source of difference, a review action primitive is generated based on the source of difference, and the review action primitive is written into the action sequence, so that the review action primitive can regenerate action output parameters for the current action primitive to read; when the action output parameters regenerated by the review action primitive still do not form a reuse permission result that allows reuse, a review failure record is generated, the current action primitive is kept in a waiting position and its entry into the execution feedback module is blocked; when the reuse permission result indicates that reuse is prohibited, the writing of candidate historical action output parameters into the action input parameters of the current action primitive is blocked.

10. A method for scheduling omnidirectional forklift tasks based on motion primitives, employing a control system based on motion primitives as described in any one of claims 1-9, characterized in that, include: The context building module obtains the omnidirectional forklift task instructions, collects the operation status corresponding to the omnidirectional forklift task instructions, encapsulates the task object ownership relationship and action execution conditions into action input parameters, generates action primitives carrying the initial action context based on the action input parameters, and configures the underlying control handles that match the execution type for the action primitives. The version scheduling module obtains action primitives, generates action sequences and a set of completed actions according to the input-output dependencies between action primitives, updates the sequence version identifier after the position of the action sequence changes, and forms a reordering impact record. The execution feedback module determines the current action primitive from the action sequence, and executes the current action primitive by combining handle dispatch, event triggering and frequency limiting polling. After the execution result passes the attribution verification, it generates action output parameters and writes the action output parameters into the completed action set. The parameter admission module obtains the input requirements of the current action primitive and the output parameters of historical actions in the completed action set, uses context validity verification to form a reuse license result, and updates the action input parameters of the current action primitive according to the reuse license result.

Images