WO2020005164A1

WO2020005164A1 - Task management method and system thereof

Info

Publication number: WO2020005164A1
Application number: PCT/SG2019/050323
Authority: WO
Inventors: Renjun LI; Boon Hwa TAN
Original assignee: Senserbot Pte. Ltd.
Priority date: 2018-06-29
Filing date: 2019-06-28
Publication date: 2020-01-02
Also published as: JP2022500722A

Abstract

The present invention relates to a task management method and system thereof that enables planning of tasks for task management by autonomous systems, in particular but not exclusively for managing task by recovering from failure for completion of an assigned task and/or increase the likelihood of task completion. The system generates an execution plan based on defined task goals for executing the task and enables continuous management of a plurality of tasks in the case of failure.

Description

TASK MANAGEMENT METHOD AND SYSTEM THEREOF

FIELD OF THE INVENTION

The present invention relates to a task management method and system thereof, in particular, but not exclusively to a task management method and system thereof that enables recovery when failure occurs for completing a task or increase the likelihood of task completion.

BACKGROUND TO THE INVENTION

The following discussion of the background to the invention is intended to facilitate an understanding of the present invention. However, it should be appreciated that the discussion is not acknowledgement or admission that any of the material referred to was published, known or part of the common general knowledge in any jurisdiction as at the priority date of the application.

Unlike traditional machines with a limited range of capabilities, autonomous systems can perform more demanding and more complex tasks in unstructured environments without continuous human intervention. Autonomous systems can sense and adapt to their environment, thus enabling them to work for extended period without intervention. This translates to increased cost savings, efficiency, and productivity.

Autonomous systems generally work well within well-defined and controlled situations. In performing a task, an autonomous robot may encounter a variety of unforeseen circumstances which prevent successful completion of the task. This is mainly due to the dynamic environment that the robot operates in that cannot be exactly characterized, hence resulting in sensor and actuator failures when the robot moves through their environment. Furthermore, when failure occurs, the robot is unable to recover rapidly and efficiently which inevitably causes interrupts.

Conventional systems implement failure reason analysis in handling failures, there is a need for knowledge to determine the cause of failure so as to devise a recovery plan. However, extending the failure reason analysis to handle dynamic worlds could be difficult since little is known about how the autonomous robots deal with activities of the other agents who may or may not cooperate in the execution of the tasks. Furthermore, such systems also require constant monitoring of the state of the robot system to detect failure to diagnose the cause of the failure or collect fault context data which typically requires complex software analysis and reasoning.

Therefore, the present invention seeks to overcome at least in part some of the aforementioned disadvantages. In particular, to provide a method and system for managing tasks that enables rapid and efficient recovery when failure occurs for completing an assigned task and/or increase the likelihood of task completion.

SUMMARY OF THE INVENTION

Throughout this document, unless otherwise indicated to the contrary, the terms “comprising”,“consisting of’, and the like, are to be construed as non-exhaustive, or in other words, meaning“including, but not limited to”.

In accordance with a first aspect of the present invention, there is provided a task management method for executing a task having task goal for managing an assigned task autonomously. The method comprises: receiving task information defining a set of actions having one or more actions for executing the task; determining a computed time based on the defined set of actions; determining whether the task goal is achieved by determining whether the computed execution time exceeds actual execution time; retrieving one or more recovery responses when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal; generating an execution plan to obtain an updated set of actions reflecting the one or more recovery responses to manage the task.

Preferably, the task information may comprise characteristic of a sequence of events. The set of actions is associated with a selected sequence of events for executing the task.

Preferably, the method comprises executing the generated execution plan for continuous execution of the sequence of events in case of failures. Based on a selection criteria that is determined for a given situation, one or more sets of the instructions associated with recovery responses is retrieved and implemented to perform the task.

Preferably, the method further comprises developing expert knowledge based on observation of a dynamic response to the case of failures.

Preferably, the method further comprises ranking a plurality of recovery response based on the task goal to derive the recovery response for managing the failures.

Preferably, the recovery response comprises one or more of the following: implementing an alternative mode of execution, reverting to an earlier non-failure state, re-executing the task.

Preferably, the task goal may comprise confirming information previously obtained from a user or a previous event in the sequence.

Preferably, the method further comprises determining an indication of likelihood of localization by calculating a covariance function based on the following formula: pf = ParticleFilter(robot, sensor, q, L, np) wherein, q = covariance of diffusion noise added to the particles, L = covariance for probability of sensor model, and np = number of particles.

Preferably, the task information further comprises characteristics for a plurality of tasks, wherein implementing the execution plan enables executing a plurality of tasks. The plurality of tasks may nested or cascaded.

In accordance with a second aspect of the present invention, there is provided a task management system for executing a task having task goal for managing the assigned task autonomously. The system comprises a control module, a storage module, and a task manager. Each of the modules is interconnectable to another and is operable to communicate with one another. Preferably, hardware modules are provided to implement the tasks.

(i) the control module and the task manager are operable to perform the following: receiving task information defining a set of actions having one or more actions for executing a task; determining a computed time based on the defined set of actions; determining whether the task goal is achieved by determining whether the computed execution time exceeds actual execution time;

(ii) the control module and the memory module are operable to perform the following:

retrieving one or more recovery responses when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal;

(iii) the control module and the task manager are operable to perform the following: generating an execution plan based on the one or more recovery responses to obtain an updated set of actions reflecting the one or more recovery responses to manage the task.

Preferably, the task information may comprise characteristic of a sequence of events.

The task manager is configured to execute the generated execution plan for continuous execution of the sequence of events in case of failures.

The control module is configured to retrieve an appropriate recovery response by applying expert knowledge based on observation of a dynamic response to failures.

The control module is configured to rank a plurality of recovery responses based on the task goal to derive the appropriate recovery response.

The control module is configured to confirm information previously obtained from a user or a previous event to determine whether the task goal is achieved. The memory module is configured to transmit the retrieved recovery responses to the control module comprising one or more of the following: implementing an alternative set of actions, reverting to an earlier non-failure state, re-executing the task.

The system further determines an indication of likelihood of localisation of the system by calculating a covariance function based on the following formula: pf = ParticleFilter(robot, sensor, q, L, np) wherein, q = covariance of diffusion noise added to the particles, L = covariance for probability of sensor model, and np = number of particles.

Wherein the covariance function provides an indication whether the system is well localized and ensuring that its location is correct when the covariance is below a threshold.

Preferably, the system receives task information comprising characteristics for a plurality of tasks. The plurality of tasks is nested or cascaded.

In accordance with a third aspect of the present invention, there is provided a computer program product comprising instructions, which when the program is executed by a computer, causes the computer to carry out the steps as listed in the first aspect of the invention.

In accordance with a fourth aspect of the present invention, there is provided a computer- readable medium having stored thereon the computer program product according to the third aspect of the invention.

The present invention has at least the following advantages:

1) The present invention offers a robust autonomous system (e.g. robot, physical host) for performing tasks in a dynamic environment that effectively reduces/avoids the situation of complete failure when failure occurs. Advantageously, this reduces the need for human intervention when performing assigned tasks.

2) The present invention provides a failure recovery system which minimises downtime or inaccessibility caused by a state of complete failure. This enables continuous operation for task execution by responding to failure modes thereby increasing the likelihood of task completion during occurrences of failure.

3) The present invention offers a response framework which allows the robot to autonomously interact with the environment to manage failures encountered while performing the assigned tasks. Advantageously, the failure state of the system is managed without having to diagnose the cause of the failure or collect fault context data which typically requires complex software analysis and reasoning.

Other aspects and advantages of the invention will become apparent to those skilled in the art from a review of the ensuing description, which proceeds with reference to the following illustrative drawings of various embodiments of the invention.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will now be described, by way of illustrative example only, with reference to the accompanying drawings, of which:

Figure 1 is a schematic diagram of a task management system in accordance to an embodiment of the present invention;

Figure 2 is a flow diagram of a task management process of the task management system of Figure 1; Figure 3 is a flow diagram for managing a task by repeating the assigned task;

Figure 4 is a flow diagram for managing a task by reverting to a previous failure-free state;

Figure 5 is a flow diagram for managing a task by undertaking an alternative task.

Figure 6 illustrates an operational process for managing a task by combining various approaches of Figures 3 and 5. Figure 7 illustrates an operational process for managing a task by combining various approaches of Figures 3 and 4.

Figure 8 illustrates an operational process for managing a task by combining various approaches of Figures 3, 4 and 5. DETAILED DESCRIPTION OF THE EMBODIMENTS

Particular embodiments of the present invention will now be described with reference to the accompanying drawings. The terminology used herein is used for the purpose of describing particular embodiments only and is not intended to limit the scope to the present invention. Additionally, unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skilled in the art to which this invention belongs.

The use of singular forms“a”,“an”, and“the” include both singular and plural referents unless the context clearly indicates otherwise.

The use of“or”,

means“and/or” unless stated otherwise. Furthermore, the use of terms “including” and“having” as well as other forms of those terms, such as“includes”, “included”,“has”, and“have” are not limiting.

The term“failure” as used herein refers to inability of a system or component to perform a required function as specified.

With reference to Figures 1 to 5, there is described a task management system and method for an autonomous system or a robot to manage a task autonomously in a dynamic environment for coordinating an execution plan comprising task execution information, and may provide failure recovery information remotely. Advantageously, the task management system and method incorporate recovery events/responses in the execution plan which effectively reduces/avoids the situation of complete failure when failure occurs.

The task management method and system of the present invention have various applications; for example, to a method of conducting autonomous operations in manufacturing and logistics applications. For logistics applications, the invention may be employed to facilitate the transportation of goods in relation to autonomous systems which advantageously eliminates and/or minimizes system failures.

Figure 1 shows a schematic diagram of a task management system 100 in accordance with an embodiment of the present invention. The system 100 comprises a control module 102, a task manager 104, and a memory module 106. The control module comprises one or more processors (not shown) for controlling and managing the task manager 104 and memory module 106. The control module 102 initiates task by sending a set of instructions to the task manager 104. On receiving the set of instructions, the task manager 104 performs the task. Thereafter, the task manager 104 reports the task outcome by sending a report on task performance to the control module 102. The control module 102 processes the report on task performance and retrieves a required response from the memory module 106.

Each of the control module 102, the task manager 104, and the memory module 106 may be implemented on an autonomous system. An autonomous system includes a robot or autonomous vehicle. In this embodiment, the autonomous system is in the form of a robot.

The control module 102, the task manager 104, and the memory module 106 interconnect via a communication means. The communication means can be a dedicated network and any network suitable for interconnecting the control module 102, the task manager 104, and the memory module 106. Upon receiving the task input by the control module 102, instructions will be sent to the task manager 104 and the memory module 106 where it is processed. Subsequently, the processed instructions which also includes the recovery response is sent to the task manager 104.

The control module 102 and the task manager 104 are operable to perform the following:

• Receiving task information defining a set of actions for executing the task.

The task may be defined as a sequence of events for executing the task. Depending on the situation, there may be one or more defined sequences for the task. All the sequences may be compared to determine the correct, or best sequence, if one exists. Depending on the sequence of events, a set of actions may be defined to execute the event. There mat be one or more actions in the set of actions.

• Determining computed execution time based on the defined set of actions, which is dependent on, task route and the defined sequence of events.

• Determining whether task goal is achieved by determining whether the computed execution time exceeds actual execution time. If the actual execution time exceeds the computed execution time, a failure state exists, and the task goal is not achieved. The task goal may comprise one or more sub task goals.

The control module 102, and the memory module 106 are operable to perform the following:

• Retrieving one or more recovery responses when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal.

• Generating an execution plan based on the one or more sets of instructions to obtain a set of actions reflecting the recovery responses for executing the defined sequence of events to manage the task.

• Executing the execution plan, such that the defined sequence of events continuously executes by adapting the recovery responses for managing the task in the case of failures.

Referring to Figure 2, in accordance with an embodiment of the present invention, there is described a task management method. The task management method comprises:

• Receiving task information defining a set of actions for executing a task.

The task may be defined as a sequence of events for executing the task. Depending on the situation, there may be one or more defined sequences for the task. All the sequences may be compared to determine the correct, or best sequence, if one exists. Depending on the sequence of events, a set of actions may be defined to execute the event. The set of actions may comprise one or more actions, depending on the assigned task.

• Retrieving one or more recovery response when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal.

• Generating an execution plan based on the one or more recovery response to obtain an updated set of actions reflecting the one or more recovery response to manage the task.

Wherein when the execution plan is executed by a task manager 104, the defined sequence of events continuously executes by adapting recover responses to manage the task in the case of failures.

An execution plan is created by the control module 102 for an assigned task. Such tasks may relate to transportation of goods, sorting of goods or shelving goods. The execution plan consists a set of one or more discrete tasks (or subtasks). The discrete tasks may be performed by different entities, such as multiple hardware modules. The discrete tasks are grouped to achieve a common goal.

The execution plan may include the following information:

• The target position for the robot;

• A set of discrete tasks to be carried out; and

• A set of actions for carrying out the execution plan.

The control module 102 receives a task input from and transforms the task into a series of actions that would satisfy it. This set of actions is passed on to the task manager 104 for execution by the hardware modules (not shown). A hardware module includes a sensor, an actuator and the like for executing the tasks. The control module 102 creates an execution plan for an assigned task. The control module 102 generates the plan according to various constraints, including environment constraints (e.g. where physical barriers in certain areas hinder operations), task constraints (e.g. when the nature of the task, such as task complexity affects the operation). Each discrete task is passed on to a task manager 104 for further processing. The task manager 104 coordinates the execution of the hardware modules in performing the tasks. The task manager 104 allocates each discrete task for execution by the respective hardware module. The task manager 104 ensures that each discrete task is executed before moving on to the subsequent discrete task, thereby ensuring the reliability of task performance.

Figures 3, 4, 5 are high-level flow diagrams illustrating how the recovery response is triggered to manage an assigned task in an autonomous system in accordance with an embodiment of the present invention. The recovery response is initiated when the autonomous system encounters a failure state, which cannot handle the task and/or subtask. A recovery response includes undertaking an alternative mode, repeating the first mode of operation, reverting to a failure-free state prior to the failure state, or a combination thereof, depending on the situation and the task at hand.

Figure 3 illustrates an operational process in which the autonomous system undergoes recovery by repeating the assigned task in an attempt to achieve the initial goal of task. The repetition approach may give different outputs. The autonomous system receives a request to perform Task A. In process step 301, the system initiates Task A and recognizes a success state when the Task A is completed in step 302. The system moves on to a next task.

In process step 303, the system recognizes a failure state when Task A is not performed successfully. For example, the failure state may result when Task A is not performed within a predetermined time interval which may be an expected execution time for that task. The system re-attempts Task A and may re-attempt multiple times. Repeating Task A increases the likelihood of completing the task. A task will be considered a“failed” task when the system has failed to perform the same task after attempting it n times in step 304. The system monitors the task output when Task A finishes in step 305. Ideally, recovery by repetition may be suitable for tasks that may give different output each time the task is executed.

Figure 4 illustrates an operational process in which the autonomous system undergoes recovery by returning the system to a previous state, which is a failure-free state. Reverting to a previous state prepares the system to take on a next task/subtask. The autonomous system receives a request to perform Task A. In process step 401, the system initiates Task A and recognizes a success state when the Task A is completed. The system moves on to a next task. In process step 402, the system recognizes a failure state when Task A is not performed successfully. For example, the failure state may result when Task A is not performed within a predetermined time interval which may be an expected execution time for that task. The system resets and reverts to a previous failure-free state. This enables the system to take on another assigned task (Task B). The system monitors the task output for Task A. This reset approach may be suitable for tasks that may give the same result each time the task is performed. Ideally, undergoing recovery by reset relieves the failure state that may be encountered when a particular task is carried out.

Figure 5 illustrates an operational process in which the autonomous system undergoes recovery by undertaking an alternative task to accomplish the task. In this case, alternative tasks are not available or assigned. The autonomous system receives a request to perform Task A. In process step 501, the system initiates Task A and recognizes a success state when the Task A is completed. The system moves on to a next task.

In process step 502, the system recognizes a failure state when Task A is not performed successfully. For example, the failure state may result when Task A is not performed within a predetermined time interval which may be an expected execution time for that task. The system coordinates one or more alternative tasks (Task B in this case) to try to complete the initial task to achieve the initial task objective. This alternative approach may be suitable for tasks that may be achieved through different ways.

The task management system reduces labour-intensive tasks for employees, therefore improving efficiency and time saving. These heavily process-oriented situations, such as consolidating books for shelving or cataloguing are classified as simple contexts, characterized by the cause-and-effect relationships. In this case, there is a command-and- control style for setting parameters for response in coordinating the management of a task. If for example, problem arises, the problem could be easily identified, categorized, and responded to appropriately.

An application of the task management system includes an autonomous system for order processing and fulfilment for delivering of goods autonomously. For example, a first attempt to deliver the goods may not be successful as the recipient is not home. Subsequent delivery attempt(s) would likely ensure task completion, thereby minimising failure of service. The task management system may take the form of an autonomous system or an autonomous robot to navigate through a library a library or bookstore to locate a shelf to scan RFID tags on the books. In some instances, tasks would involve positioning to appropriate height for the antenna to scan the books on the shelves. Repetitive tasks such as navigating through obstacles (e.g. shelves), localisation, as well as adjusting and/or readjusting antenna would be necessary for completing a sequence of tasks, which may include many discrete intermediate tasks.

Hybrid Frameworks

The operational process as illustrated in Figures 3, 4 and 5 above provide the fundamental structure for coordinating the appropriate responses for managing a task.

The task management system and method of the present invention enables managing of nested task, by layering one task over another. Tasks may be nested in this manner to many levels. Tasks may be managed by way of cascading, by passing on the task successively. The generated execution plan that incorporates one or more of the models to give a robust system for managing complex tasks.

Hybrid Framework 1 :

A goal is achieved by completing the task or subtasks defined in a complex task. The goal may comprise one or more subtask goals.

Assume Task FA is a task in Framework A (Figure 3). If Task FA is put into Framework B (Figure 4), the system tries n times before attempting another method to achieve the goal. Task FA is managed using the recovery by repetition approach (in Figure 3). Different approaches may be combined. In this case, the approaches of repetition and reset may be combined for executing the task multiple times (or n times) before using an alternative method to achieve the goal. If Task FA is put into Framework B (alternative approach in Figure 4), the approaches of repetition and reset may be combined for executing the task multiple times. The system may perform a recover action to a previous non-failure state after multiple failed attempts. Thereafter, it may then attempt the task again using the same method, however, with a higher chance of success. Assume Task FB is a task in Framework B (Figure 4). This new Task FB can be put into Framework A (repetition approach). This allows the system to retry both Task A and Task B multiple times if they fail.

Task FB can be put into Framework B (reset approach) to cascade another alternative action, Task C. The system will try to finish the task using Task A first. If failed, the system will re-attempt to complete the task using Task B. If it failed too, it will move on to Task C, until all possible methods are tried.

The above hybrid frameworks are examples that make use of the fundamental approaches to manage a task. There are infinite combinations one could use to plan a task, to be implemented by a shelf scanning robot comprising multiple RFID antennas, a telescopic arm to project the antennas up and down, a mobile base that moves the telescopic arm structure around.

Example 1 : Move up antennas near a book shelf. In some instances, the antennas are required to be directed to a specific height for accurate scanning. For a robot may be close by to the book shelf, the antennas could be obstructed by the books on the shelf. Sensors (contact sensor) have been built onto the antennas to detect such obstacles.

Objective: Move up the antenna to a specific height. Actions required:

1. Move up antenna.

• Result: Success (height reached) / Failure (Obstacle detected)

2. a) Rotate out (move antenna away from obstacle) b) Move up antenna

• Result: Success (height reached) / Failure (Obstacle detected) c) Rotate back The task in this example is managed by identifying potential failures before the execution of an action. The above task is performed with the assumption that simple subtasks such as moving in and out (step a and c) will not fail and will achieve success. Example 2: Hybrid Framework 1

In this example, Action 1 is the default action to achieve the objective. If the system reports on failure, the system tries 3 times to avoid false alarm from sensors. Action 2 is an alternative to Action 1. The task management system is shown in Figure 6.

Case 2: Auto Docking When the robot is low in battery or below a pre-defined threshold, e.g. 20%, an auto docking task may be initiated.

Objective: Dock into the docking station for charging Actions:

1. Navigate to a point (Navigation Point) in front of the docking station · Result: Assume Success

2. Dock

• Result: Success (Docked) / Failure (Not docked properly)

In this example, robot will not be able to produce a different Dock result if it failed the first attempt. Therefore, Recovery by Repetition will not work. However, if robot position is reset to a Navigation Point, the Dock task can be executed again.

Example 3: Hybrid Framework 2

Robot perform Action 1 and Action 2 in sequence. If Action 2 fails, reset the robot state to the end of Action 1. Repeat the sequence for n times. This is illustrated in In Figure 7. Case 3: Point to point navigation

Objective: To navigate from one location to another.

Actions: Navigate to target location

1. Result: Success (target reached) / Failure (target not reachable) 2. Rotate on the spot

3. Reset memory of obstacles

When the space is close the minimum limit of what the robot requires, navigation algorithm may not be able find a path all the time. Action 2 may introduce perturbation to the robot location which may result in different path being planned.

Action 3 is used to clear obstacles in the robot memory, forcing robot to only consider obstacles that is being detected currently. This will allow robot to plan a path via obstacles that has been detected before, but does present any more.

Action 2 and 3 are alternative methods to reset the navigation task if it fails and allow a subsequent attempt to yield a different result.

Example 4: Hybrid Framework 3

Figure 8 illustrates task management framework for Robot to perform Action 1. If failed, perform Action 2 and retry. If failed, perform Action 3 and retry.

The present invention may be integrated into an autonomous system, such as a robot, which advantageously allows lifting up/down of a telescopic arm to enable an antenna to scan books placed at different heights on shelves. The antenna may be blocked when books are protruding from the shelves and may hinder the task of scanning. Furthermore, the antenna may be damaged should there be forceful movement by the telescopic arm to cause collision with the books.

Example 5

The task management system is implemented into an autonomous robot for navigating from one point to another. An autonomous robot can get stuck at a location as a result of nearby obstacles blocking its path in a localised area, in which a feasible path to its destination cannot be planned. For example, when the path from robot’s current location to the destination is blocked, robot will not be able to plan a path. If a static obstacle is too near, robot will never find a path.

When path planning fails, the navigation node will automatically send out a signal notifying that task has failed. The robot may be integrated with a mechanism to notify failure of the task. The mechanism may include a limit switch to be added to on the top that is turned on when a spring-held top cover hits an object at the top. A similar limit switch can be added at the bottom, when a spring-held bottom cover hits an object at the bottom. This creates a signal that notifies the robot that the task cannot be completed.

In addition, a recovery action can be undertaken. The recovery action encompasses attempting and re-attempting to move the arm a number of times, and removing the robot and try again. When the arm can be successfully moved up/down to scan the RFID tags, the task is considered successful.

In another embodiment of the invention, a change in the robot’s current location can be effected. A reset task, such as rotate on the spot could be used to rescue the robot in this situation. After rotating, it will update its locations again, which may result in a slight change in location on the global map. Therefore, it would be able to find a path to the destination.

Example 6

The autonomous robot is assigned a task of ensuring that its location is correct when performing any movement. With robot localization, robot detection may be lost in an environment with low scan matching sensor. Without correct location information, the robot cannot be detected and could not help to make decisions about future actions for moving around the environment. The lost detection mechanism would stop the robot from navigating in a lost environment and will only release the robot when robot has a correct localization.

An algorithm is used to estimate the pose of a robot via the formula below: pf = ParticleFilter(robot, sensor, q, L, np)

This estimates the state of the robot via scan matching sensor q is the covariance of the diffusion noise added to the particles, L is the covariance for the probability of the sensor model and np is the number of particles.

Hence, to detect whether a robot is well localized, the covariance of the particle filter function can be used. As long as the elements in the covariance matrix is below a certain threshold, the robustness of the localization can be justified.

For example, the covariance above a threshold of about 1000 times higher than a nominal value, the localisation task will be considered failed. This nominal value is the covariance for a robot operating under normal operating conditions, without implementing failure recovery.

In other instances, a machine learning method may be implemented to automate the process of detecting whether the robot is well localized. This may be implemented by using the covariance of correct locations (Ln) as the training data for producing a nominal value; and using the covariance of the wrong locations (Lw) as the training date for determining the threshold. A well localized robot would demonstrate Ln > Lw.

While the above demonstrates that the determined threshold may be an absolute value, it would be appreciated that the threshold depends on various factors, including the sensors used in the robot, the environment that the robot operates. As such, ratio of Lw and Ln provides an indication for the threshold. The value is typically 100 and above.

In another embodiment of the present invention, a recovery task is triggered so that the robot would reset itself to a known pose in the environment via past navigation trajectory. Once the robot is able to localize itself in the predefined map, the robot would be allowed to navigate for subsequent task.

For tasks managed by Recovery by Reset and Recovery by Alternatives frameworks, the tasks may be performed autonomously or manually. For example, a Health Monitoring system may be developed and embedded into the system where human actions will act as recovery tasks to manage the failure state. When a certain task fails, the user may provide the next course of actions so that work flow will not be interrupted.

In a further embodiment, the system may employ a ranking of the recovery frameworks A, B, C (in Figures 3, 4, 5 respectively) to determine a recovery framework that best provide task management to achieve the objective of the task. For example, in the framework of Recovery by Alternatives, where Task A takes a higher priority to achieve the objective, the system may be configured to try Task B only if Task A fails. However, the sequence of executing the alternatives could be altered if Task A have a higher chance to fail compared with Task B. Therefore, system efficiency could be improved.

It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto, as would be apparent to persons skilled in the relevant art, are deemed to fall within the broad scope and ambit of the present invention described herein. It is further to be understood that features from one or more of the described embodiments may be combined to form further embodiments.

Claims

1. A method for task management for executing a task having task goal, comprising: receiving task information defining a set of actions having one or more actions for executing a task; determining a computed time based on the defined set of actions; determining whether task goal is achieved by determining whether the computed execution time exceeds actual execution time; retrieving one or more recovery responses when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal; generating an execution plan based on the one or more recovery responses to obtain an updated set of actions reflecting the one or more recovery responses to manage the task.

2. The method according to claim 1 , wherein the task information comprises characteristic of a sequence of events.

3. The method according to claim 1 or 2, further comprising executing the generated execution plan for continuous execution of the sequence of events in case of failures.

4. The method according to claim 1, wherein retrieving the one or more recovery responses further comprises developing expert knowledge based on observation of a dynamic response to failures.

5. The method according to claim 4, further comprising ranking a plurality of recovery responses based on the task goal to derive the recovery response for managing the failures.

6. The method according to any of the preceding claims, wherein the recovery response comprises one or more of the following: implementing an alternative set of actions, reverting to an earlier non-failure state, re-executing the task.

7. The method according to claim 1, wherein the task goal comprises confirming information previously obtained from a user or a previous event.

8. The method according to claim 1, further comprising determining an indication of likelihood of localisation by calculating a covariance function based on the following formula:

pf = ParticleFilter(robot, sensor, q, L, np) wherein, q = covariance of diffusion noise added to the particles, L = covariance for probability of sensor model, and np = number of particles.

9. The method according to any of the preceding claims, wherein the task information further comprises characteristics of a plurality of tasks.

10. The method according to claim 9, wherein the plurality of tasks is nested or cascaded.

11. A system for task management for executing a task having task goal, comprising: a control module;

a memory module; and

a task manager; wherein the control module, the memory module and the task manager interconnect via a communication means, and wherein

(iv) the control module and the task manager are operable to perform the following: receiving task information defining a set of actions having one or more actions for executing a task; determining a computed time based on the defined set of actions; determining whether the task goal is achieved by determining whether the computed execution time exceeds actual execution time;

(v) the control module and the memory module are operable to perform the following: retrieving one or more recovery responses when the task goal is not achieved, wherein the one or more recovery responses is associated with the task goal;

(vi) the control module and the task manager are operable to perform the following: generating an execution plan based on the one or more recovery responses to obtain an updated set of actions reflecting the one or more recovery responses to manage the task.

12. The system according to claim 11, wherein the task information comprises characteristics of a sequence of events.

13. The system according to claim 11, wherein the task manager is configured to execute the generated execution plan for continuous execution of the sequence of events in case of failures.

14. The system according to claim 11, wherein the control module is configured to retrieve an appropriate recovery response by applying expert knowledge based on observation of a dynamic response to failures.

15. The system according to claim 14, wherein the control module is configured to rank a plurality of recovery responses based on the task goal to derive the appropriate recovery response.

16. The system according to claim 14 or 15, wherein the control module is configured to confirm information previously obtained from a user or a previous event to determine whether the task goal is achieved.

17. The system according to claim 11, wherein the memory module is configured to transmit the retrieved recovery responses to the control module comprising one or more of the following: implementing an alternative set of actions, reverting to an earlier non failure state, re-executing the task.

18. The system according to claim 11, further comprising determining an indication of likelihood of localisation of the system by calculating a covariance function based on the following formula:

19. The system according to any of the preceding claims, wherein the task information further comprises characteristics of a plurality of tasks.

20. A computer program product comprising instructions which, when the programme is executed by a computer, cause the computer to carry out the method of claims 1 to 10.

21. A computer-readable medium having stored thereon the computer programme product of claim 20.