Method and apparatus for online task planning and robot motion control

Abstract

The disclosed technology embodies a favorable approach for online task and motion planning of robots, based on decomposing robot tasks into subtasks and assigning attributes to each subtask. These attributes indicate whether dynamic trajectory correction is permitted during subtask execution. This decomposition and attribute assignment enables hybrid motion control during task execution. For example, some subtasks may be allowed reactive motion planning for collision avoidance, while others may not. Collision avoidance for non-reactive subtasks may include, for example, adjusting spatial reservations within the relevant robot work cell to prevent other robots from interfering with a robot engaged in a subtask designated as non-reactive. The decision of which subtasks are non-reactive depends on information contained in the input task specification and is based on user analysis or automated analysis of the relevant robot application.

Description

Technical Field

[0001] The subject matter disclosed herein relates to robots, particularly to online task planning and robot motion control.

Background Art

[0002] Automation by robots enables a variety of applications in industrial environments, such as assembly, welding, palletizing, deburring, inspection, etc. To achieve automation by robots, robot task planning and scheduling are necessary.

[0003] Generally, a robot automation application consists of one or more tasks. Examples of tasks include pick-and-place of parts. Each task may include one or more subtasks. Examples of subtasks include movement to a pre-pick position and movement from the pre-pick position to a pick position. Tasks and subtasks may have associated properties, objectives, and constraints such as paths and speeds that change during execution. These may be specified or unspecified (flexible). For example, an industrial robot used for assembling machine parts needs to pick up parts, inspect the parts, and then perform actions such as welding, deburring, or bonding of the parts. Each of these tasks must be executed in a specific order and may involve multiple individual operations by the robot's actuators and motors.

[0004] Normally, the user manually specifies the tasks of the robot and a related sequence of operation sequences so that the robot can complete the tasks while avoiding collisions with other objects or the robot in the environment. It is possible to manually program the robot offline, but such an approach is not suitable for some application scenarios and may require a great deal of cumbersome manual work for setting, integration, and verification.

[0005] Manual configuration of an application becomes particularly difficult when variable factors are present. These variable factors include cycle-by-cycle variations in the robot's task sequence, start and target positions, start timing, and duration. For example, in a deburring application, parts may arrive on the conveyor belt at irregular timings and positions, or the size and shape of the parts may change from cycle to cycle. Furthermore, potential inspection steps before deburring can lead to branching of the task sequence, for example, whether or not a part is discarded after inspection. Such variations can potentially number in the hundreds or even thousands in an application, making manual task assignment and trajectory programming extremely complex and error-prone.

[0006] Furthermore, many applications require multiple robots. When multiple robots operate in a shared workspace, the effort involved in task assignment and behavioral programming becomes even more complex. For example, users must manually ensure collision avoidance between the robots and other objects in the environment, often using interlocking techniques. Creating, verifying, and validating such manual techniques is prohibitively difficult and expensive to implement.

[0007] The complexity and challenges of task and motion planning described above are increasing interest in and use of automated online task planning and robot motion control. In this context, "task planning" can be understood as the process of combining and sequencing basic robot operations into a structured plan to achieve a given objective, given specifications for the robot and environment. These basic robot operations can be further broken down into one or more discrete robot operations.

[0008] Executing a task plan requires precise and accurate control of the robot's movements. This means controlling the robot's position, velocity, and acceleration to ensure it follows a planned trajectory precisely. Such motion control takes into account various factors, including the robot's dynamics, the state of its environment, and any obstacles it may encounter during task execution. Therefore, online motion planning can be understood as a process that generates discrete robot movements immediately before (or during) the start of a movement, satisfying the constraints of the movement and, in some cases, optimizing certain aspects of the movement. Often, these discrete robot movements arise from the decomposition of a desired basic robot operation, such as the movement from a pre-pick position to a pick position.

[0009] Online task and motion planning offers high flexibility, enabling the handling of variable factors and automatic collision avoidance in multi-robot environments. In particular, some conventional approaches to automated online task and motion planning utilize reactive motion control. This allows robots to react in real time to changes and variations in the environment. "Reactive" motion planning allows robots to adjust their trajectory in real time in response to obstacles, themselves, other robots, or other environmental considerations.

[0010] Despite the advantages that existing online motion planning approaches offer to robot automation, there are applications where the usefulness of existing online task and motion planning approaches is limited or completely incompatible. Incompatibility arises, for example, when certain subtasks within an application have incompatible objectives, constraints, or properties, making the use of online motion planning impossible. For instance, a subtask might require a robot to follow a strictly straight path at a specified speed for functional success. This is required for tasks such as applying fluids like adhesive beads.

[0011] In such subtasks, dynamic trajectory corrections from the reactive motion planning unit to ensure collision avoidance are likely to lead to application failure. Therefore, there is a discord between conflicting functional and operational objectives: collision avoidance and task / application success. Similar problems occur in a wide variety of real-world robot applications, and multiple robotic environments can be particularly challenging. [Overview of the Initiative]

[0012] The techniques described herein enable the assignment (dynamically or pre-assigned) of one or more tasks or subtasks to one or more robots in multiple robot applications for functionality and / or performance. In some embodiments, two or more subtasks can be bundled so that these bundled subtasks run without interruption.

[0013] The disclosed technology embodies a favorable approach for online task and motion planning of robots, based on decomposing robot tasks into subtasks and assigning attributes to each subtask. These attributes indicate whether dynamic trajectory correction is permitted during subtask execution. This decomposition and attribute assignment enables hybrid motion control during task execution. For example, some subtasks may be allowed reactive motion planning for collision avoidance, while others may not. Collision avoidance for non-reactive subtasks may include, for example, adjusting spatial reservations within the relevant robot work cell to prevent other robots from interfering with a robot engaged in a subtask designated as non-reactive. The decision of which subtasks are non-reactive depends on information contained in the input task specification and is based on user analysis or automated analysis of the relevant robot application.

[0014] One embodiment includes a method for online task planning and robot motion control for robot control. The method includes (a) processing an input task specification that specifies a robot task, wherein the input task specification decomposes the robot task into subtasks and distinguishes between reactive motion (RM) subtasks that allow dynamic trajectory correction and non-reactive motion (NRM) subtasks that do not allow dynamic trajectory correction; (b) sequentially generating subtask commands according to the subtask dependencies determined from the input task specification, wherein the subtask commands are distinguished between the RM subtasks and the NRM subtasks; (c) determining a robot trajectory for executing the subtask commands according to an online motion plan that allows dynamic trajectory correction during the execution of the RM subtasks and does not allow dynamic trajectory correction during the execution of the NRM subtasks; and (d) outputting position commands to one or more robot controllers to execute robot motion.

[0015] One related embodiment includes a computer system for online task planning and robot motion control. This computer system comprises an interface circuit and a processing circuit. The processing circuit is configured to (a) process an input task specification that specifies a robot task, the input task specification breaking down the robot task into subtasks and distinguishing between reactive motion (RM) subtasks that allow dynamic trajectory correction and non-reactive motion (NRM) subtasks that do not allow dynamic trajectory correction; (b) sequentially generate subtask commands according to the subtask dependencies determined from the input task specification, the subtask commands distinguishing between the RM subtasks and the NRM subtasks; (c) determine robot trajectories for executing the subtask commands according to an online motion plan that allows dynamic trajectory correction during the execution of the RM subtasks and does not allow dynamic trajectory correction during the execution of the NRM subtasks; and (d) output position commands to one or more robot controllers to execute the robot's motion.

[0016] Of course, the present invention is not limited to the features and advantages described above. Those skilled in the art will recognize additional features and advantages by reading the following detailed description and looking at the accompanying drawings. [Brief explanation of the drawing]

[0017] [Figure 1] This is a block diagram of an online task planning and operation control framework according to one embodiment. [Figure 2] This figure shows a block diagram of a computer system implementing the online task planning and motion control framework of Figure 1 according to one embodiment, and further shows an example of a robot under control. [Figure 3] A block diagram showing examples of robot actuators that are commanded during robot control. [Figure 4] This block diagram shows a detailed example of implementing the processing circuit of the computer system shown in Figure 2. [Figure 5] This is a logical flowchart of an operation method for online task planning and operation control according to one embodiment. [Figure 6] This diagram shows an example of a task graph, which illustrates the set of tasks included in a robot application. [Figure 7] This figure shows an example of parameterizing individual tasks, including subtask decomposition and corresponding subtask classification. [Figure 8] This diagram shows the space reserved between starting position A and target position B. [Figure 9] This diagram illustrates an example of a pick operation, showing the robot in various positions corresponding to different subtask categories. [Figure 10] This diagram illustrates an example of a task specification for an application involving two robots, and shows examples of subtask decomposition and subtask bundling. [Figure 11] This diagram shows two 6-axis robots, illustrating an example scenario where the target areas of both robots overlap. [Figure 12] It is a logical flow diagram showing an example of a pick and place application with a corresponding subtask decomposition. [Figure 13] It is a logical flow diagram showing an example of an adhesive bead application with a corresponding subtask decomposition.

Embodiments for Carrying out the Invention

[0018] The embodiments disclosed herein provide a comprehensive framework that enables the achievement of functional objectives embodied in robotic applications while achieving operational objectives such as collision avoidance in single and multi-robot workcells. This comprehensive framework enables the incorporation of a variety of motion planning techniques for the execution of robotic applications, including both manual techniques such as reactive motion planning and automated motion planning techniques. By allowing different types of motion planning at the subtask level, refined automatic responses to application-specific and operation-specific constraints are possible in a wide range of practical applications, including single robots or multiple robots operating in a multi-robot workcell.

[0019] In this context, a "task" is a goal-oriented functional block of a larger application, such as a placement operation in robotic assembly. A "subtask" is a basic component of a larger application. One or more subtasks (e.g., discrete robot motions from a pre-position to a placement position within a placement task) can be combined to form a task.

[0020] FIG. 1 shows an example of an online task planning and operation control framework 10 (the "framework 10" or the "system 10"). In this framework, the operation control is based on an online operation plan. The framework 10 is instantiated depending on physical processing circuits, memories, and interface circuits, but the framework 10 may be implemented in a virtual computing environment based on underlying computing hardware.

[0021] The control framework includes an online task planning unit 12 that receives an input task specification 14, such as by reading a data file from a computer file system, and a robot interface subsystem 16 that is composed of an operation planning unit and, in one or more embodiments, a work cell cooperation function for a multi-robot environment. The robot interface subsystem 16 converts a subtask command into a position command and outputs it to one or more robot controllers 18. The position command is based on an online operation plan. Although shown separately from the framework 10, one or more robot controllers 18 may be integrated into the framework 10. For example, the overall computer system configuration may include processing circuits and related interfaces for instantiating the framework 10 and the robot controller 18 as an integrated system.

[0022] Each robot controller 18 converts the received position command into a corresponding robot command. This can be understood as a command to a motor or other form of actuator that moves the link of the related robot according to the position command. There may be a robot controller 18 for each robot 20, or one robot controller 18 may interface with and control multiple robots 20.

[0023] The illustrated operations may be performed continuously. For example, the task planning unit 12 may sequentially issue subtask commands, the robot interface subsystem 16 may issue corresponding position commands, and the robot controller 18 may issue corresponding robot commands to move or otherwise control one or more of the involved robots 20. For example, in addition to, or in conjunction with, issuing commands to move the robots 20, there may be commands to control end effectors or other control actions for grasping or releasing objects, or for controlling attached tools.

[0024] Figure 2 shows a computer system 30 according to one embodiment. This computer system implements the framework 10 and robot controller 18 described in Figure 1. Figure 2 also shows an example of one embodiment of the robot 20. In accordance with the flexibility described above, the reader should understand that Figure 2 represents only one example configuration. For example, there may be multiple robots 20, each robot 20 having its own robot controller 18. Furthermore, the robot controller 18 may be implemented separately from the framework 10. The computer system 30 shown in Figure 2 communicates with an external robot controller 18, which issues robot commands to the robot 20.

[0025] The computer system 30 includes a processing circuit 32. This processing circuit 32 may include a storage 34 or be communicatively connected to the storage 34. In one or more embodiments, the storage 34 stores one or more computer programs 36 ("CP" in the figure) along with one or more types of data 38. In at least one embodiment, the stored data 38 includes a task specification 14 and / or the results of processing the task specification 14, which are read by the computer system 30.

[0026] The interface circuit 40 of the computer system 30 connects the processing circuit 32 to one or more external entities, systems, or devices in a communicative manner. For example, the interface circuit 40 includes a first transceiver circuit (indicated as transmitter (TX) 42-1 and receiver (RX) 44-1) for interface with a local area network (LAN) or other data network. In a non-limiting example, TX42-1 and RX44-1 may be implemented as an Ethernet-based interface circuit. Of course, such a circuit may also be a wireless circuit for wireless communication, either as an alternative to or in addition to a wired connection.

[0027] The illustrated interface circuit 40 further comprises a second transceiver circuit (indicated as transmitter (TX) 42-2 and receiver (RX) 44-2) for directly interface with the robot 20 or with the corresponding robot controller 18. Note also that in some embodiments, a single communication interface, such as a data network interface, is used to connect the computer system 30 communicably to receive the task specification 14 and to control the robot 20 or to interact with its associated robot controller 18.

[0028] Therefore, the interface circuit 40 may include a digital or analog signal circuit, or both, for outputting control commands to the robot controller 18 or the robot 20 and receiving corresponding feedback (corresponding measurements). This is used for responsive and dynamic control of the robot 20. The computer system 30 is shown separately from the example of the robot 20, but in one or more other embodiments it is integrated into the robot.

[0029] Figure 2 also shows a detailed example of one robot embodiment. Again, there may be multiple robots 20, such as two or more robots 20, within a shared work cell. A scenario with multiple robots may involve two or more instances of the same type of robot, or instances of different types of robots.

[0030] The illustrated configuration example of the robot 20 in Figure 2 includes a base 50 having a first rotation axis via a first rotation joint 52. A second rotation joint 54 connects a first arm 56 to the base 50. The other end of the first arm 56 is terminated by a third rotation joint 58. The third rotation joint 58 connects the first arm 56 to a second arm 60. The second arm 60 is divided into two segments 60A and 60B, and a fourth rotation joint 62 allows segment 60B to rotate relative to segment 60A. A fifth rotation joint 64 connects segment 60B to the third arm 66. A sixth rotation joint 68 connects an end effector 70 to the end of the third arm 66.

[0031] Returning to Figure 1, the subtask command is converted into a position command. The position command is converted into a robot command. The robot command includes, for example, control signals to the actuators of the associated robot 20. More specifically, the generated subtask command results in one or more position commands if the associated subtask is an action subtask, while the generated subtask command for a non-action subtask usually does not result in the generation of a position command but may result in the generation of an action command (e.g., open gripper, close gripper, etc.).

[0032] Figure 3 shows an example of signal transmission between a robot controller 18 and an actuator 80 associated with a specific joint of a particular robot 20. The actuator 80 includes, for example, a DC rotary actuator, but the robot of one or more embodiments may include a linear actuator or a mixture of linear and rotary actuators. In any case, the actuator 80 responds to input commands that control, for example, the direction of joint movement, the speed of movement, and the range of movement. In the case of rotational movement, such commands drive changes in joint angles and determine the posture of the robot 20 by controlling the joint angles between each link / overall of the robot 20. "Posture" refers to the specific position and orientation of all links of the robot 20.

[0033] The operation of the robot 20 is performed, for example, in connection with the execution of one or more "applications." An application can be embodied, for example, as a computer program, and defines specific actions and end-effector operations to be performed by the robot 20 to perform one or more tasks. An example of a task is a pick-and-place task in which the robot 20 picks up items from one location and places them in another location. In one example application, the robot 20 retrieves items from a conveyor belt and sequentially packs them onto pallets, into boxes, etc. The tasks described in Input Task Specification 14 can be understood as defining applications.

[0034] The processing circuit 32 of the computer system 30 is configured to process the input task specification 14 and generate corresponding subtask commands which are converted into motion and action commands for one or more robots 20, as described above. In the implementation example shown in Figure 4, the processing circuit 32 may be implemented as a microprocessor 90 that executes computer program instructions held in the associated memory 92. In other words, the microprocessor 90 is specifically adapted to operate in accordance with the description of the processing circuit provided herein, based on the execution of computer program instructions.

[0035] More generally, the processing circuit 32 can be implemented as a fixed circuit, a programmatically configured circuit, or a combination of both. Furthermore, instead of a single microprocessor, two or more microprocessors may be used, or a multi-core microprocessor may be used. Additionally or alternatively, the implementation of the processing circuit 32 may be based on essentially any type of digital processing circuit, such as one or more field-programmable gate arrays (FPGAs), system-on-a-chip (SoCs), application-specific integrated circuits (ASICs), composite programmable logic devices (CPLDs), or digital signal processors (DSPs).

[0036] The storage 34 may include one or more types of computer-readable media, including volatile memory as working memory for program execution and associated data storage, and non-volatile memory for long-term storage of computer programs and configuration data such as one or more user configuration parameter values. Examples include dynamic random access memory (DRAM), static RAM (SRAM), non-volatile RAM (NV-RAM), FLASH or solid-state disk (SSD), and electrically erasable programmable read-only memory (EEPROM).

[0037] Regardless of the specific implementation details, the computer system 30 is configured for online task planning and corresponding robot motion control, and in one embodiment includes an interface circuit 40 for receiving data including an input task specification 14 that specifies a robot task, and further includes a processing circuit 32.

[0038] The processing circuit 32 is configured to process the input task specification 14 that specifies the robot task. In particular, the input task specification 14 decomposes the robot task into subtasks and distinguishes between reactive operation (RM) subtasks, which allow dynamic trajectory correction, and non-reactive operation (NRM) subtasks, which do not allow dynamic trajectory correction.

[0039] The processing circuit 32 is further configured to: sequentially generate subtask commands according to the subtask dependencies determined from the input task specification 14, where subtask commands are distinguished between RM subtasks and NRM subtasks; determine the robot trajectory for executing the subtask commands according to an online motion plan that allows dynamic trajectory correction during the execution of RM subtasks and does not allow dynamic trajectory correction during the execution of NRM subtasks; and output position commands to one or more robot controllers 18 via the interface circuit 40 to execute robot movements.

[0040] Subtask commands are distinguished between RM subtasks and NRM subtasks by including subtask attributes. Each subtask listed in the input task specification 14 belongs to a corresponding subtask category, which includes multiple subtask categories recognized by the computer system 30. Recognized categories include one or more categories of non-operational subtasks and two or more categories of operational subtasks, including RM and NRM categories. Each subtask command includes attributes that indicate the corresponding subtask category to be considered in the online operation plan.

[0041] In at least one embodiment, an idle category is defined. An idle is a special category of motion subtasks, specifically a reactive motion subtask. The idle subtask is characterized by requiring the robot to maintain a desired posture for a given period of time, except when it needs to react to avoid a collision (which involves robot movement), and the robot returning to the desired posture once the reactive avoidance is complete.

[0042] The category definition may also include one or more Non-Operational Action (NMA) categories in which dynamic trajectory correction is not permitted. The processing circuit 32 is configured to output action commands corresponding to NMA tasks, represented by subtask commands, to one or more robot controllers 18. For example, an NMA task may involve an action of the robot's end effector. The action commands are end effector control commands such as grip and release.

[0043] In at least one embodiment, the two or more motion categories include, in addition to the RM and NRM categories, a predictive motion category in which the movement of the robot 20 is repeatedly planned over a predetermined time range, and a manual mode motion category in which the movement of the robot 20 is manually defined according to a number of waypoints, and a trajectory along the waypoints is generated using an interpolation algorithm.

[0044] In one or more embodiments, an online motion planning unit instantiated via the computer system 30 determines corresponding trajectory constraints using attributes of motion subtasks. Determining constraints includes determining, at the subtask granularity, whether dynamic trajectory corrections are permitted. Among the advantages embodied in the operation of the computer system 30 is the ability to have both reactive and non-reactive operation, and since the determination is made at the subtask level, a given task can be executed using a mixture of reactive and non-reactive operation. This mixture maximizes the flexibility of path planning while still allowing non-reactive operation when deviations from nominal or required trajectories are incompatible with the execution of the relevant subtasks.

[0045] The input task specification 14 relates in at least one embodiment to two or more robots operating in a shared workspace. The online motion plan includes dynamic trajectory correction for collision avoidance with the remaining one or more robots 20 for a specific robot 20 performing an RM subtask. The processing circuit 32 is configured to perform collision avoidance via cooperative spatial reservation for the specific robot 20 performing an NRM subtask. This ensures that the remaining one or more robots 20 do not perform robot trajectories that interfere with the specific robot 20's performance of the NRM subtask.

[0046] In the same or another example where the input task specification 14 relates to two or more robots operating in a shared workspace, the processing circuit 32 is configured to identify related tasks to be performed by the same one of the two or more robots 20, and to assign the subtasks that make up the related tasks to the same robot 20.

[0047] In at least one embodiment, the processing circuit 32 is configured to recognize and process “subtask bundles.” That is, the input task specification 14 may represent one or more subtask bundles. Each subtask bundle contains two or more subtasks of a corresponding task, which should be executed by the robot 20 to which the corresponding task is assigned, without interruption by other robots 20. Here, the processing circuit 32 is configured to coordinate operations between two or more robots 20 in order to provide uninterrupted execution of each subtask bundle.

[0048] In at least one embodiment including a subtask bundle, one or more tasks or subtasks are pre-assigned for execution by a specific robot 20 of two or more robots 20 that collaboratively share a work area, while one or more tasks or subtasks listed in the input task specification 14 remain unassigned. With respect to the unassigned tasks or subtasks, the processing circuit 32 is configured to determine the robot assignment. The assignment may be made at the task level and may be determined based on availability, load balancing, the status of the candidate robots 20, or other considerations.

[0049] Figure 5 shows a method 500 for online task planning and robot motion control by a computer system, for example, the computer system 30 described above. Method 500 includes processing an input task specification 14 that specifies a robot task (block 502). Such processing includes, for example, reading the input task specification 14 as a stored computer file or receiving a signal indicating the input task specification 14. In either case, the input task specification 14 breaks down the robot task into subtasks and distinguishes between reactive motion (RM) subtasks, which allow dynamic trajectory correction, and non-reactive motion (NRM) subtasks, which do not allow dynamic trajectory correction.

[0050] Method 500 further includes sequentially generating subtask commands according to the subtask dependencies determined from the input task specification (block 504). Subtask commands are distinguished between RM subtasks and NRM subtasks. Method 500 further includes determining the robot trajectory for executing the subtask commands according to an online motion plan that allows dynamic trajectory correction during the execution of RM subtasks and does not allow dynamic trajectory correction during the execution of NRM subtasks (block 506). Furthermore, Method 500 includes outputting position commands to one or more robot controllers 18 to execute the robot's motion (block 508). Method 500 may further include any of the additional or alternative operations described above for the processing circuit 32 for implementation of the framework 10.

[0051] Figure 6 shows an example of a task graph representing a single or multi-robot application. The task graph shows that the application consists of multiple tasks. The interconnections between tasks indicate task dependencies (e.g., Task 1 must be executed before Task 2). An important aspect of the task graph is that it represents a real-world application that requires both reactive and non-reactive actions for the execution of the entire application. As a mere example, Task 2 includes a set of subtasks, some of which include subtasks in the RM category and subtasks in the NRM category. Task 4 includes at least subtasks in the RM or NMA category. Task 5 includes at least NRM subtasks.

[0052] Unlike conventional online task and action planning, the framework 10 described herein allows for subtask-level granularity to control whether to use reactive action (where dynamic trajectory correction is permitted) or non-reactive action (where dynamic trajectory correction is not permitted). This level of granularity increases flexibility for dynamic collision avoidance during at least some actions, while still allowing deterministic path following for actions where dynamic path correction is inappropriate.

[0053] The disclosed approach links attributes to subtasks. The attributes linked to each subtask are subtask categories. The relevant behavior planning unit is configured to recognize which subtask categories allow reactive behavior and which do not. Of course, additional information, such as properties and constraints added at the task or subtask level, may be specified in the input task specification 14. Also, as noted, the input task specification 14 may indicate a subtask bundle, where bundling is a specific method of constraining tasks / subtasks. The framework 10 recognizes the task / subtask specification and controls the runtime to automatically assign the task / subtask bundle to one or more specific robots 20, ensuring that the subtask bundle is executed in order and without interruption or overwriting through subtask generation and ordering, and overall integrated control.

[0054] From another perspective, the decomposition of application tasks into subtasks, and the recognition and use of attributes at the subtask level, allows task-specific constraints and objectives to be imposed on the online motion planning unit in an ad-hoc manner. This type of advantageous control can be generalized to any application, including those with multiple robots or those that inherently have all kinds of variable factors. Here, "ad-hoc" refers to the seamless change of motion control from reactive to non-reactive, or vice versa, at the subtask level granularity.

[0055] Returning to Figure 1, the framework 10 can be understood as a robot motion control system having several functional components, comprising an online execution system consisting of at least a task planning unit 12 and a robot interface subsystem 16. These components can be implemented by executing one or more computer programs (e.g., computer program 36 shown in Figure 2) via one or more computer systems (e.g., computer system 30). If multiple computer systems are involved, they may be configured to communicate via a network such as Ethernet, EtherCAT, or Firewire. The robot interface subsystem 16 may also include a programmable logic controller (PLC) for the implementation of the robot controller 18 shown in Figure 1.

[0056] The task planning unit 12 sequentially provides a series of subtask commands to be executed by the robot interface subsystem 16. The robot interface subsystem 16 transmits position commands to the robot controller 18 that drives one or more controlled multi-axis robots 20.

[0057] The robot interface subsystem 16 includes a global path planning unit that generates a viable collision-free path for one or more robots 20 based on input from the task planning unit 12 (including the configuration of the start and target, a desired path with speed constraints, and multiple sub-targets). The robot interface subsystem 16 also includes a local optimization-based reactive planning unit. This planning unit takes a viable collision-free path as input, generates a time-parameterized collision-free trajectory, and transmits it to the corresponding robot controller 18 to execute the generated trajectory. The robot interface subsystem 16 also includes a support module that enables coordinated operation between multiple robots to resolve situations including target competition and deadlocks. Here, the support module can be understood as a logical function realized by the execution of computer program instructions.

[0058] As shown in Figure 2, the robot 20 may be a multi-axis robot arm having end effectors at the ends of the arms. The arms include multiple joints. The end effectors may include a two-finger gripper, vacuum suction, adhesive device, etc. The position of the robot is defined by the angles of each joint of the robot. A specific position and orientation of the robot can correspond to one or more joint configurations of the robot. During execution, the robot interface subsystem 16 sends position commands to the associated robot controller 18 and receives the corresponding measured position as a reply.

[0059] In one embodiment, the user provides an input task specification 14 that covers an entire application to be performed by a specific robot 20 or one or more robots 20, prior to execution operations performed by a system called an online task planning and motion planning framework. The task specification 14 identifies a set of tasks, one or more of which encapsulate subtasks. A subtask contained within a task may be just one, but typically encompasses a sequence of multiple subtasks that produce an intermediate result, such as a pick operation, after which a subsequent operation, such as a placement operation, may or may not be definitively selected. A sequence may contain tasks performed by multiple authorized robots. Tasks are treated herein as goal-oriented functional components of a larger application, such as robot assembly.

[0060] Task specification 14 may be provided as a structured text document such as XML, or as a logical flowchart. Task planning unit 12 processes task specification 14 to construct a corresponding directed graph. Information conveyed in task specification 14 includes task parameters. Task parameters indicate the dependency on the completion of other tasks in the list, the number of robots permitted to perform the task and their unique identifiers (IDs), whether subtasks are bundled or unbundled, and a display of subtask breakdown per task.

[0061] A directed graph maintains the order in which tasks should be executed and respects task dependencies. In the directed graph shown in Figure 6, task 5 depends on the completion of tasks 2, 3, and 4. This dependency restricts the task planning unit 12 from sending requests for task 5 or any of its subtasks to the robot interface subsystem 16 until tasks 2, 3, and 4 are completed. Depending on the application constraints, multiple dependencies can be defined. The graph is traversed using breadth-first search to find the next task for the robot 20.

[0062] Multiple robots 20 may perform a task. These robots 20 can be identified by robot number and ID information included in the task specification 14. Accordingly, the robot interface subsystem 16 automatically assigns the task to a single robot and handles prioritization. A task can have any number of task dependencies. The task planning unit 12 restricts the execution of the current task until all dependent tasks have been successfully completed. Completion information may be provided to the task planning unit 12 as feedback from the robot interface subsystem 16. Furthermore, subtasks may be bundled within a given task. Conversely, a task may include additional or alternative unbundled subtasks. In at least one embodiment, the robot interface subsystem 16 is configured to automatically switch unbundled subtasks of a particular robot 20 in order to manage coordination with other robots 20.

[0063] In one or more embodiments, subtasks are characterized into several categories based on the properties of the subtask and associated constraints that may be specified as part of the task specification 14. Examples of properties that a subtask may have include: (1) reactivity: when the robot's motion plan changes during execution to react to and avoid other dynamic objects; (2) duration: when a particular subtask must be completed within a specified period; (3) kinematic constraints: when a particular subtask must adhere to a given boundary of joint motion including position, velocity, acceleration, jerk, or the orientation of the robot tool center point; and (4) tool: when a particular subtask is associated with a particular end-effector tool, and this tool changes from one subtask to another.

[0064] The proposed task specification 14 allows for the specification of various subtasks having predetermined properties. An example of a subtask framework for a specific task "x" specified in task specification 14 is shown in Figure 7.

[0065] As an example of a subtask category specified in Task Specification 14 and favorably recognized and acted upon by Framework 10, the first example category is Reactive Motion. In reactive motion, the robot 20 moves from one position to another (for example, from a starting position to a target position). The robot interface system automatically replans the trajectory to avoid collisions with other objects in the environment or with the robot 20. Subtasks belonging to the Reactive Motion (RM) category have attributes that indicate the RM category. The corresponding subtask command may specify a starting joint configuration and a target joint configuration.

[0066] Framework 10 also allows, in one or more embodiments, to specify the initial position and orientation of the end effector, as well as the target position and orientation. This category of operation may be achieved by trajectory optimization or an artificial potential field, but is not limited to these.

[0067] The second example category of subtasks is non-reactive motion (NRM). In the NRM subtask, the robot 20 moves from a starting position to a predetermined target position along a predefined path and / or velocity, without reacting to other objects or robots in the environment. In at least one embodiment, the robot interface subsystem 16 first assigns priority to the robot 20 performing the non-reactive motion, calculates the space that the body of the robot 20 sweeps during the non-reactive motion, and reserves this space to automatically handle collision avoidance by preventing other objects or robots from entering it until the robot 20 completes the non-reactive motion. This space reservation is sometimes called cooperative space reservation because it involves coordinating the control of multiple robots 20.

[0068] The "actions" of an end effector may be classified into two categories based on the required spatial reservation: 1) actions that do not require a change in spatial reservation (classified as NMA (Non-Operational Actions)), and 2) actions that require a change in spatial reservation (classified as NRM (Non-Reactive Actions)).

[0069] Here, "representation" refers to the shape used to represent an object (e.g., for collision avoidance purposes). "Reservation" refers to the space protected from intrusion (this is based on the representation and the space swept during the action). This distinction usually depends on a) the size of the end effector's spatial reservation (e.g., "tight" or "oversized") and b) the amount of action associated with the end effector's action (e.g., no action / minor action vs. large action). For example, consider the following case: Case A: A vacuum gripper that does not move during operation and does not require any changes to the spatial reservation of the end effector. Therefore, actions involving vacuum grippers fall under the NMA category. Case B: A small-movement two-finger gripper with an "oversized" end-effector space reservation. The gripper's fingers move but remain within the oversized space reservation. Therefore, actions involving this fingered gripper fall into the NMA category. Case C: A large-action two-finger gripper with a "tight" end-effector spatial reservation. When the gripper's fingers move, they exceed the original "tight" end-effector spatial reservation. Therefore, actions involving this fingered gripper are in the NRM category.

[0070] These considerations are particularly important because it is not uncommon for robots to have complex and large-motion end effectors, and the techniques described herein take all such cases into account. Finally, this also applies to the workpiece held by the end effector. Regardless of whether it is covered by the arm's spatial reservation, a combination of the arm and end effector's spatial reservations, or a combination of the arm, end effector, and workpiece's spatial reservations, the spatial reservation (however formulated) must cover the arm, the end effector, and the workpiece (if any). Overall, this approach is based on the idea that, at least for the purposes of tasks and motion planning such as collision avoidance, the end effector (and workpiece, if any) is not distinguished from the robot arm.

[0071] Figure 8 shows a specific robot 20 moving from position A to position B via non-reactive motion. This motion causes the robot 20 to sweep a specific space. The specific space is calculated and reserved by cooperative space reservation by the robot interface subsystem 16. In embodiments where the robot interface subsystem 16 issues all position commands for all involved robots 20, not just the specific robot 20, this coordination can be understood as an internal coordination of when and to which robot position commands are issued. In other embodiments, where one or more of the involved robots 20 respond to position commands issued by another entity, this coordination includes the robot interface subsystem 16 communicating with those other entities.

[0072] Subtasks within an NRM category are specified by an attribute (e.g., ID) that indicates the NRM category. Each NRM subtask may specify a starting joint configuration and a target joint configuration. A nonlinear (e.g., circular) path may also be specified. Velocity constraints along such a path can also be specified.

[0073] Another example of a subtask category is the Non-Moving Action (NMA) category. In an NMA subtask, the body of the robot 20 does not move, but the end effector may perform some action, such as opening or closing. NMA subtasks are designated by an ID that indicates the NMA category. Each NMA subtask may specify the time for a gripping, holding, or releasing operation of the end effector. In at least one embodiment, the robot interface subsystem 16 automatically handles collision avoidance during the execution of NMA subtasks. For example, it calculates the space that the robot sweeps during an NMA subtask that includes the movement of the end effector and reserves the swept space so that no other objects or the robot 20 itself enter it until the robot 20 completes the NMA subtask.

[0074] Another subtask category is the idle category. The idle category is a special category of action subtasks. While an idle subtask is running, the robot remains stationary at a specific location but in a reactive state. Idle subtasks are parameterized based on a specified time (i.e., idle time). Idle subtasks allow robot 20 to wait at a specific location before or after starting a task due to application-specific timing constraints, and also allow robot 20 to remain reactive as needed while waiting.

[0075] Furthermore, the defined subtask categories may include predictive motion categories. In predictive motion subtasks, the robot's movement from a specific start to a target is iteratively planned over a limited time range, while estimating the movement of other dynamic objects in the environment. Subtasks in the predictive motion category explicitly predict and plan the robot's movement over a longer time range compared to subtasks in the RM category, which have a limited time range of a single time step.

[0076] For planning over longer time ranges, it is possible to consider dynamic changes in the environment and ensure collision avoidance in uncertain environments. Predictive motion subtasks are identified using corresponding IDs and specify the starting joint configuration, target joint configuration, and planning time range. Framework 10 also allows for the specification of the starting position and orientation of the end effector, as well as the target position and orientation. While this category of motion can be achieved through model predictive control, the implementation is not limited to this approach.

[0077] Another defined subtask category in at least one embodiment is the manual mode operation category. In the manual mode operation subtask, the robot's movement is specified by the user based on a number of waypoints. These waypoints may be specified in Cartesian space or joint space. In this category, the movement may be interpolated between waypoints using fitting techniques such as splines, linear motion, or polynomials. This subtask category is specified by an ID indicating the MM (Manual Mode Operation) category. Each MM subtask specifies a starting joint configuration and a target joint configuration, and may include multiple intermediate waypoints. The robot's velocity at these intermediate waypoints may also be specified, and additionally or alternatively, the starting position and orientation of the end effector and the target position and orientation may be specified.

[0078] Accordingly, any subtask listed in Input Task Specification 14 may be parameterized by an ID indicating its subtask category and additional information indicating one or more of the following: start and target configuration in articular or Cartesian space, end effector operation, duration (only required if the subtask is idle or if acquisition time for grippers, etc., is specified), time range (required for predictive operation), intermediate waypoints provided in articular or Cartesian space (for manual mode operation), or robot speed at intermediate waypoints (for manual mode operation).

[0079] As a more detailed example of subtask bundling, consider a case where a robot's end-effector must follow a straight path toward an object, then the robot must grasp the object, and then the robot must move backward along the same straight path toward a specific location. These three subtasks must be completed by the same robot, and the sequences of approaching the object, grasping it, and moving away from the grasped object must occur in that order without interference. Interference can occur if a second robot in the environment takes priority toward overlapping target areas, interrupting the first robot's task sequence. Figure 9 shows an example of such movement by robot 20.

[0080] The type of robot-to-robot interference described above can lead to application failure. To prevent such events, one or more embodiments of the disclosed framework enable subtask bundling. Figure 10 shows an example of how a user can prepare a task specification 14 using subtask bundling in the context of a two-robot application. The different robots are shown as robot R1 and robot R2.

[0081] The task specification includes RM, NRM, and NMA subtasks, as well as TS (Task Start), TE (Task End), BS (Bundle Start), and BE (Bundle End) commands. Task specification 14 specifies the correct task sequence. The task planning unit 12 recognizes this sequence. Each command generated by the task planning unit 12 is added to the internal queue in the specified order.

[0082] Subtasks bundled in TS and TE are considered a set of commands for the same task. This recognition of subtask bundling is used to determine the prioritization of R1 and R2. For example, if a reactive action by R1 conflicts with a reactive action by R2, such as when target locations overlap, the reactive action by R1 takes precedence. Of course, there may be other instances within the same overall application where prioritizing R2 is appropriate.

[0083] Commands bundled in BS and BE are considered "sequential non-reactive actions." In this case, framework 10 reserves the entire space occupied by the relevant robot for the execution of the bundled subtask, preventing other robots from interfering with the pre-programmed non-reactive actions. The swept space diagram shown in Figure 8 includes a robot moving from configuration A to B. The shaded reserved area is represented by the voxels occupied by the robot during the movement.

[0084] Figure 11 shows an example scenario illustrating the need for collaborative space reservation. This example involves a first robot 20-1, indicated as R1, and a second robot 20-2, indicated as R2. The two robots R1 and R2 operate in a shared workspace where space reservation is required. For example, space is reserved for R1 so that R1 can perform NRM and NMA subtasks around a designated target without interference from R2. When the task priority changes to R2, R1 must move to a safe, collision-free location, and space is reserved at that target for R2 to perform the NRM and NMA subtasks. While the target is reserved and until R2 has completed its bundled subtasks, other robots are not allowed to enter the reserved space. As the process progresses, completed subtask commands are removed from the queue, and the framework 10 changes the active command to the next top-level command for the target robot 20. In this way, the framework 10 automatically handles all robots 20 without conflict, given the properly specified task / subtask information.

[0085] Figure 12 shows an example application involving object pick-and-place by robot 20. Flowchart 1200 divides the application into separate pick and place operations, both of which consist of multiple distinct operations. The operation begins with opening the gripper of robot 20, which is an NMA subtask (block 1202). This operation is followed by an RM subtask (block 1204), where robot 20 reactively moves from a predetermined starting position near the gripping point where the object will be picked up to a desired target position. The third operation is an NRM subtask (block 1206), where robot 20 is constrained to move along a predetermined path with a speed limit to approach the gripping point in a specific orientation. This operation can lead to collisions with the workpiece or other objects in the environment due to interference from other robots. For this reason, this operation cannot be reactive. The fourth operation is an action of the end effector (e.g., gripper) (block 1208), which grips the object and closes the gripper. The gripper's actions can be performed as non-operational or non-reactive actions, depending on whether a change in spatial reservation is required. After the gripper's actions, the robot 20 performs the NRM subtask and moves to the pre-grasp position (block 1210). This movement completes the pick operation.

[0086] Next, the placement operation begins. This starts with an RM subtask (block 1212) in which the robot 20 moves towards the pre-placement point, followed by an NRM subtask (1214) in which the robot 20 moves towards the part drop position. At the part release position, the robot performs an end-effector action to release the part (block 1216). This type of action can be a non-action subtask if it does not require a change in the spatial reservation, or a non-reactive action subtask if it does. The robot 20 then performs an NRM subtask (block 1218), which returns it to the pre-grasp position.

[0087] Many industries require multi-axis robots for dispensing tasks. For example, the automotive industry uses multi-axis robots to dispense various materials such as adhesives, lubricants, and sealants. Window and door manufacturers also use multi-axis robots to apply adhesives and gaskets.

[0088] An example of an adhesive bead application using advantageous task decomposition and bundling techniques is shown in flowchart 1300 in Figure 13. This application includes a multi-axis robotic manipulator, a dispenser that can be mounted in a fixed position, workpiece components, an inspection area, and an input / output conveyor for picking and placing workpiece components. This application is divided into sequential tasks. These tasks are further decomposed into subtasks, and the subtasks are classified and bundled as described herein.

[0089] This application includes the following tasks: Task 1 (Pick): The robot moves from its initial position to a defined pre-pick position, uses a speed-constrained approach along a path to pick a part from the conveyor, and then returns to the pre-pick position along the constrained path at the constrained speed. See blocks 1302, 1304, 1306, and 1308 for subtask classification. Task 2 (Approaching the Feeder): The robot, holding the gripped workpiece, moves from its pre-pick position on the conveyor to a predetermined position, and then makes a path and speed-constrained approach to the dispenser position. See blocks 1310 and 1312 for related subtasks. Task 3 (Adhesion): The robot moves the workpiece under path and velocity constraints so that the dispenser can apply the bead to the part. Note that this type of motion is typically parameterized in Cartesian space. This task may consist of several non-reactive actions during adhesive bead dispensing. See blocks 1314 and 1316 for related subtasks. Task 4 (Inspection): The robot moves the completed parts to the inspection area. See blocks 1318, 1320, and 1322 for related subtasks. Task 5a (Object Acceptance): If the quality is acceptable (YES from block 1324), the robot moves from the inspection position to the placement position, releases the object, and then returns to the designated location. See blocks 1334, 1336, 1338, and 1340 for related subtasks. Task 5b (Object Rejection): If the quality is unacceptable (NO from block 1324), the robot moves the part from the inspection position to the defective box (see blocks 1326, 1328, 1330, and 1332 for related subtasks).

[0090] With the detailed examples above in mind, the disclosed subject matter embodies a technique for implementing online task planning and robot motion control. This technique is applicable even when the relevant application requires non-reactive operation, while simultaneously providing the flexibility of reactive operation in other instances. The technique involves breaking down a robot application into tasks and subtasks, where the subtasks broken down from a task have associated properties, objectives, constraints, and attributes. Properties may change, for example, from one task to another. Examples of objectives include minimum time operations for a given task, and examples of constraints include task-dependent path and speed limits.

[0091] A specific aspect is the association of attributes with subtasks. Attributes indicate subtask categories, allowing the online motion planning unit to execute motion control using different motion control strategies depending on the subtask category. For example, RM subtasks are executed using dynamic trajectory correction (e.g., for collision avoidance), while NRM subtasks are executed without dynamic trajectory correction to maintain a deterministic path. Other categories include different non-motion categories that allow or disallow reactive behavior by the robot for different non-motion actions.

[0092] Modifications and other embodiments of the disclosed invention will be conceivable to those skilled in the art who benefit from the teachings presented in the above description and the accompanying drawings. Therefore, it should be understood that the invention is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of this disclosure. Certain terms are used herein, but they are used in a general and descriptive sense only and not for limiting purposes.

Claims

1. A method for online task planning and robot motion control, A step of processing an input task specification that specifies a robot task, wherein the input task specification decomposes the robot task into subtasks and distinguishes between RM (Reactive Action) subtasks that allow dynamic trajectory correction and NRM (Non-Reactive Action) subtasks that do not allow dynamic trajectory correction. A step of sequentially generating subtask commands according to the subtask dependencies determined from the input task specifications, wherein the subtask commands are distinguished between the RM subtask and the NRM subtask, The steps include determining a robot trajectory for executing the subtask command according to an online motion plan that allows dynamic trajectory correction during the execution of the RM subtask and does not allow dynamic trajectory correction during the execution of the NRM subtask, The steps include: outputting position commands to one or more robot controllers in order to perform robot movements; Methods that include...

2. The method according to claim 1, wherein the subtask command is distinguished from the RM subtask and the NRM subtask by including subtask attributes.

3. The method according to claim 1, wherein each subtask described in the input task specification belongs to a corresponding subtask category, and there are a plurality of subtask categories recognized by the process, the plurality of subtask categories include one or more categories of non-operational subtasks and two or more categories of operational subtasks, including RM categories and NRM categories, and each subtask command includes an attribute indicating the corresponding subtask category to be considered in the online operation plan.

4. The method according to claim 3, wherein the categories of two or more operational subtasks include an idle category in which dynamic trajectory correction is permitted, and the categories of one or more non-operational tasks include a non-operational action (NMA) category in which dynamic trajectory correction is not permitted.

5. The method according to claim 4, further comprising the step of outputting an action command corresponding to the NMA task represented by the subtask command to one or more robot controllers.

6. The method according to claim 5, wherein the NMA task involves an action of the robot's end effector, and the action command is an end effector control command.

7. The method according to claim 3, wherein, in addition to the RM category and the NRM category, the two or more motion categories include a predictive motion category in which the robot's movement is repeatedly planned over a predetermined time range, and a manual mode motion category in which the robot's movement is manually defined according to a plurality of waypoints, and a trajectory along the waypoints is generated using an interpolation algorithm.

8. The method according to claim 3, wherein the online motion plan determines corresponding trajectory constraints using the attributes of motion subtasks, the determination of which includes determining at the subtask granularity whether dynamic trajectory corrections are permitted.

9. The aforementioned input task specification relates to two or more robots operating in a shared workspace, The online motion plan includes, with respect to a specific robot performing the RM subtask, dynamic trajectory correction to avoid collisions with one or more other robots. The collision avoidance described above is based on the specific robot performing a cooperative spatial reservation when executing the NRM subtask. The method according to claim 1, wherein the remaining one or more robots do not perform robot trajectories that interfere with the execution of the NRM subtask by the particular robot.

10. The aforementioned input task specification relates to two or more robots operating in a shared workspace, The method according to claim 1, further comprising the steps of identifying related tasks to be performed by the same one of the two or more robots, and assigning subtasks constituting the related tasks to the same robot.

11. The aforementioned input task specification indicates one or more subtask bundles, Each subtask bundle must contain two or more subtasks of the corresponding task, and the corresponding task must be executed by the robot to which it is assigned without interruption by one or more other robots. The method according to claim 10, further comprising coordinating the operation of the two or more robots to provide uninterrupted execution of each subtask bundle.

12. One or more tasks or subtasks are pre-assigned for execution by a specific robot among two or more robots that collaboratively share a work area, and one or more tasks or subtasks are unassigned. The method according to claim 1, further comprising the step of determining the assignment of a robot to the unassigned task or subtask.

13. A computer system for online task planning and robot motion control, wherein the computer system is An interface circuit for receiving data including input task specifications that specify robot tasks, A processing circuit is provided, The aforementioned processing circuit is The system processes an input task specification that specifies the robot task, and the input task specification decomposes the robot task into subtasks and distinguishes between reactive motion (RM) subtasks that allow dynamic trajectory correction and non-reactive motion (NRM) subtasks that do not allow dynamic trajectory correction. Subtask commands are generated sequentially according to the subtask dependencies determined from the input task specifications, and these subtask commands are distinguished between the RM subtask and the NRM subtask. The robot trajectory for executing the subtask command is determined according to an online motion plan that allows dynamic trajectory correction during the execution of the RM subtask and does not allow dynamic trajectory correction during the execution of the NRM subtask. The interface circuit outputs position commands to one or more robot controllers in order to perform robot movements. A computer system configured in such a way.

14. The computer system according to claim 13, wherein the subtask command is distinguished from the RM subtask and the NRM subtask by including subtask attributes.

15. The computer system according to claim 13, wherein each subtask described in the input task specification belongs to a corresponding subtask category, and there are a plurality of subtask categories recognized by the computer system, the plurality of subtask categories include one or more categories of non-operational subtasks and two or more categories of operational subtasks, including RM categories and NRM categories, and each subtask command includes an attribute indicating the corresponding subtask category to be considered in the online operation plan.

16. The computer system according to claim 15, wherein the categories of two or more operational subtasks include an idle category in which dynamic trajectory correction is permitted, and the categories of one or more non-operational subtasks include a non-operational action (NMA) category in which dynamic trajectory correction is not permitted.

17. The computer system according to claim 16, wherein the processing circuit is configured to output action commands corresponding to the NMA tasks represented by the subtask commands to one or more robot controllers.

18. The computer system according to claim 17, wherein the NMA task involves an action of the robot's end effector, and the action command is an end effector control command.

19. The computer system according to claim 15, wherein, in addition to the RM category and NRM category, the two or more motion categories include a predictive motion category in which the robot's movement is repeatedly planned over a predetermined time range, and a manual mode motion category in which the robot's movement is manually defined according to a number of waypoints, and a trajectory along the waypoints is generated using an interpolation algorithm.

20. The computer system according to claim 15, wherein the online motion planning unit instantiated by the computer system determines corresponding trajectory constraints using the attributes of motion subtasks, the determination of which includes determining at the subtask granularity whether or not dynamic trajectory correction is permitted.

21. The aforementioned input task specification relates to two or more robots operating in a shared workspace, The online motion plan includes, with respect to a specific robot performing the RM subtask, dynamic trajectory correction to avoid collisions with one or more other robots. The processing circuit is configured to perform collision avoidance through cooperative spatial reservation when the specific robot performs the NRM subtask. The computer system according to claim 13, wherein the remaining one or more robots do not perform robot trajectories that interfere with the execution of the NRM subtask by the particular robot.

22. The aforementioned input task specification relates to two or more robots operating in a shared workspace, The computer system according to claim 13, wherein the processing circuit is configured to identify related tasks to be performed by the same one of the two or more robots, and to assign subtasks constituting the related tasks to the same robot.

23. The aforementioned input task specification indicates one or more subtask bundles, Each subtask bundle contains two or more subtasks of the corresponding task, and the corresponding task must be executed by the robot to which it is assigned without interruption by one or more other robots. The computer system according to claim 22, wherein the processing circuit is further configured to coordinate the operation of the two or more robots to provide uninterrupted execution of each subtask bundle.

24. One or more tasks or subtasks are pre-assigned for execution by a specific robot among two or more robots that collaboratively share a work area, and one or more tasks or subtasks are unassigned. The computer system according to claim 13, wherein the processing circuit is configured to determine the assignment of a robot to the unassigned task or subtask.

25. A method for online task planning and robot motion control, A step of processing input task specifications related to two or more robots operating in a shared workspace, wherein the input task specifications indicate a plurality of tasks to be performed, The steps include identifying related tasks to be performed by the same robot among the two or more robots, The steps include assigning the subtasks constituting the aforementioned related task to the same robot, Methods that include...

26. The aforementioned input task specification indicates one or more subtask bundles, Each subtask bundle contains two or more subtasks of the corresponding task, and the corresponding task must be executed by the robot to which it is assigned without interruption by one or more other robots. The method according to claim 25, further comprising coordinating the operation of the two or more robots to provide uninterrupted execution of each subtask bundle.

Images