Example of how ROGUE Handles Side-effects

Occasionally, suspending one task for a second one will mean that work done for the first will be undone by work done for the second. ROGUE needs to detect these situations and plan to re-achieve the undone work. Consider a simple situation that illustrates this re-planning process:

Task one:	Task two:
1a. goto 5301	2a. goto 5409
1b. pick up mail	2b. pick up fed-ex package
1c. goto 5315	2c. goto 4320
1d. drop off mail	2d. drop package off

Many possible interleaved planning and execution scenarios may occur; below are two possibilities.

• [Normal:] Executes 1a and 1b. While executing, the request for two arrives. ROGUE decides that task two is more important. Task two is suspended; step 1c is pending. Plans for and executes task two. Returns to step 1c, verifies that it is still needed to complete the task and can still be done, then does 1c and 1d.

• [Undone Action:] Executes 1a. While executing 1b, the request for task two arrives. 1b times-out, indicating that the mail-room person wasn't there to give the robot the mail. ROGUE decides task two is more important, and suspends task one; step 1b is pending. ROGUE plans for and executes task two. PRODIGY4.0 returns to step 1b, discovers that a precondition is not true: (robot-in-room <5301>). PRODIGY re-plans to achieve it, and then re-executes step 1a, and then finishes the task as expected.