O2S Planning Technology

1
O2S Planning Technology

• JustPlay
• 4 November 2005
• Justin Mazzola Paluska
• jmp_at_mit.edu

2
Overview

• System Model
• JustPlay Music Demo
• Model Details

3
Approach

• Make application adaptation points explicit
• Provide mechanism to choose, startup, teardown,
  and swap alternatives.
• Evaluation-based
• Very little analysis
• Exploit contexts or cached results to learn
  what should be done
• Reduce ad-hoc decision making
• How well can you make do with what you have?

4
System Model
5
Components

• Goal parameterized intent or representation of
  a desired condition
• Technique code that implements a Goal
• Planner runtime system that matches Goals to
  Techniques

6
Planner

• Recursively bind Techniques to Goals
• AND/OR tree
• At each OR node, choose a node for execution.
• based on the satisfaction property
• Execute the chosen nodes
• Maintain the tree over time
• Re-execute relevant stages
• Propagate property updates

7
(No Transcript)
8
Model Details
9
Goals

• parameterized specification of a class of intents
  or desires
• input parameters
• types and names of returned Properties
• Goal names the specification used.

from http//o2s.csail.mit.edu/system.html
10
Goal Instances

• Goal bound with parametersSendText(jmp,
  Meeting Time!)
• Return value of call is a Solution
• Properties mirror that of the chosen Technique.
• A Goal Instance persists until it is told to
  shutdown.

11
Techniques

• parameterized template for satisfying a
  particular Goal
• Both declarative and imperitive code
• subgoals
• Technique Instances satisfy Goal Instances
• parameters bound to Goal Instance's
• fill in Properties of Solutions

12
Technique Code

• Partitioned into Stages
• write stage N1 as though stage N has completed
• All state is stored in Solution objects
• subgoal properties
• one's own properties

13
(No Transcript)
14
Technique Stages

• only exec is required
• The Planner keeps track of stage dependencies.
• evaluation stages must be idempotent
• are time limited!

• evaluation stages
• first
• subgoals
• eval
• foreground
• execution stages
• exec
• update
• shutdown

15
A Few Examples
16
PlayMusic via MP3 Technique
to PlayMusic(criteria) via MP3s
subgoals source FindMusicStream(criter
iagoal.criteria,
stream_format"MP3") sink
FindAudioSink(stream_format"MP3") fader
AudioFader(in_stream_format"MP3",
out_stream_format"MP3") ...

• Don't want a new Technique for each and every
  format.

17
PlayMusic via GenericStream
to PlayMusic(criteria) via GenericStream
subgoals source FindMusicStream(criter
iagoal.criteria) sink
FindAudioSink() subgoals fader
AudioFader(in_stream_typesource.stream_format,
out_stream_typesink.stre
am_format)

• Choose an AudioFader that matches the inputs and
  outputs.

18
Making the Best Choices
OutputAV()
via Monitor/AudioSink
.50
VideoSink()
AudioSink()
.75
.75
.75
.50
.75
.25
via TV
via Monitor
via TV Speaker
via Receiver

• Given two subgoals, the best of each may not be
  the best pair.

19
Free Communication

• Use parameters to influence the choices of the
  Planner
• pass down information
• fail if a choice is not good enough

• to FreeTeleconference(person_a,
• person_b)
• via RequireFree
• subgoals
• tc Teleconference(goal.person_a,
• goal.person_b,
• cost0)
• ...

to FreeTeleconference(person_a,
person_b) via CheckFree subgoals
tc Teleconference(goal.person_a,
goal.person_b) eval
if tc.cost gt 0 fail(No free
teleconference!") ...
20
Limits to Parameter Passing

• Passing down ? needs to be specified
• Passing up ? needs to be calculated

G1(cost)
via T1
G2()
via T2

G3()

via T3
21
Questions?

• Planner in o2s/planner
• Techniques scattered through o2s/playground

22
Solutions

• Where Techniques store state
• Keeps track of modifications and rolls back state
  as necessary.
• Where properties are stored
• Public Properties (exposed as Goal
  properties)solution.satisfaction .5
• Private Propertiessolution._var 42

23
Interfacing with the Real World

• Techniques can call arbitrary code.
• Agnostic towards implementation technology.
• Python is the common denominator.
• Node Cloning
• created by the GenerateSolution subgoal

24
(No Transcript)
25
(No Transcript)