Improving Message Synchronization in CASPER

1
Improving Message Synchronization in CASPER

• Jon Beckham

2
Motivation

• NASA is forced to produce more with less money.
• Strategy is to lower number of support crew
  needed to run a mission, and use autonomous deep
  space agents to complete mission objectives in
  space.

3
CASPER

• Continuous Activity Scheduling Planning Execution
  and Replanning
• Interleaves planning and execution.
• Uses continuous planning instead of batch
  planning.
• Uses multiple processes to allow for continuous
  planning.
• Planner process
• Execution process
• State determination process
• Synchronization process

4
CASPER Architecture
5
The Synchronization Process

• Controls messages sent to and from the planner.
• Currently a simple FIFO request queue.
• Every message has the same urgency, whether its
  a drastic update to the world state or an
  activity commit.

6
Improving the Queue

• If we can figure out a more intelligent way to
  control the messages for the planner, the planner
  can spend more time where it needs to, when it
  needs to.
• Activity commits are vital.
• State estimations and replan requests are of
  varying urgency depending on how much of a change
  the message provides to the planner.

7
Priority Queuing

• A simple queue, but insertions are made at
  different positions depending on how important
  the object being inserted is.
• Popping off the queue is the same as normal.

8
Priority Queue with Volatile Layers
9
How It Works

• Activity commits are pushed through immediately.
• State estimations are pushed through immediately
  if it incorporates enough of a change to demand
  immediate attention.
• Replan requests are pushed through immediately if
  it incorporates enough of a change to demand
  immediate attention.

10
How It Really Really Works

• In order to lower the number of messages sent to
  the planner, new state estimations and replan
  requests are combined into one message. The
  weight of the message is defined by the
  difference between the planners knowledge and
  the knowledge contained in the message.

11
Why It Works

• Preprocessing messages allows the planner to
  spend more time planning.
• If two state updates come in a row in CASPER, two
  planner processes are invoked. By combining
  those two updates, the first process is not
  required, so more time can be spent on the first.
• Each planning invocation can have more
  information a priori to produce a better plan.

12
Domain Description

• Traveling Salesman Problem
• Randomized number and location of destinations in
  a two dimensional plane.
• Randomized number of salesmen generated in random
  locations on the plane.
• At any point, salesmen or destinations can be
  spawned or removed, approximating conditions in
  real world applications of CASPER.

13
Testing

• 10x10 continuous field.
• 5 20 salesmen.
• Random speed from 0.0 4.0 spaces per iteration.
  
• 40 100 destinations.
• Maximum of 30 iterations.
• 50 scenarios run with both unmodified (CASPER)
  and modified (CASPER-mod) synchronizer.

14
Results (Iterations Required)

• Clearly, the fewer iterations until completion
  (all destinations reached) the better.
• CASPER-mod is slightly better in completion speed
  than CASPER. Difference is small due to small
  domain.

15
Results (Goals Reached)

• More goals is obviously better.
• CASPER-mod reached more goals than CASPER, but
  was not enough to make any difference.

16
Results (Idle Time)

• Because there were multiple salesmen, each
  required its own plan to be generated by the
  planner (equates to controlling multiple
  actuators in parallel).
• CASPER-mod is much better at keeping parallel
  actuators working, thus wasting less time
  reaching goals.

17
Study Limitations

• Not integrated into the CASPER architecture.
• Not tested on the actual domain, but a toy
  example that simplified the task of iterative
  repair greatly.
• Not studied in enough detail to determine optimal
  thresholds for determining importance of queue
  insertions.