[Project IFT702] / Investigation on socialize (schmoozing)

During the project, we face an important problem to enable Socialize action to be planned.

1. The planner optimizer critaria

In classical planning, an optimal plan is a plan that is minimal in number of step (number of actions). But, in metric planning, we want to do more. An optimimal plan is a plan that minimize or maximize a certain value. By exemple, at ICP-3, the optimal critaria of the depot world was to minimize total fuel used.

By default, if no metrics is specified, Metric-FF optimize a plan in his size (number of step).

2. Why the Waitings actions

In our PDDL domain file, we defined two actions for waiting : WAIT-PRES-SESSION and WAIT-POST-SESSION. Theses two actions are usefull to do time synchronization. If the robot arrive before the time of the presentation, the planner can add a wait action to consume time.

The problem is that waiting actions consume a variable time window. Theses actions WAIT UNTIL a certain fixed time (time of the beginning of a presentation).

3. What we hope from the planner

The first plan is the optimal plan where the number of step are the optimality critaria. But, for the AAAI Challange, we hope that the planner will consider Socialize action. In this case, an optimal plan is a plan where waiting time is minimize and where Socialize action are insered as time consuming actions.

4. The first approach

With PDDL 2.1 level 2, it is possible to maximize a value. So, our first idea was to add a score variable in the state representation.

ScientificConf_exA.pddl
   
(define (domain ScientificConference)
  (:requirements :typing :fluents)
  [...]
  (:functions
   [...]
   (score)
  )  ; end functions section
  [...]
   (:action SOCIALIZE15
      :parameters(?loc - location)
      :precondition(and
         (robot-at ?loc)
         (socializing-place ?loc)
         (registered)
         (>= (battery-level) (* 900 (energyconsumed-per-second)))
         (<= (currenttime) 56700)  ; avant 15:45.... conference ending at 16:00!
         )
      :effect(and
         (increase (score) 10)
         (decrease (battery-level) (* 900 (energyconsumed-per-second)))
         (increase (currenttime) 900)
         )
   )
[...]

This avenue was not possible due to a limitation of Metric-FF. With Metric-FF, it's not possible to maximize an increasing value. Only minimizing an increasing value is possible (or maximizing a decreasing value).

Test File : test_socializeA.fct (contain a line with " (:metric maximize (score)) " )

# the argment -O is important to enable the optimizer
[$METRIC-FF_PATH]/ff -o ScientificConf_exA.pddl -f test_socializeA.fct -O

Planner output :
warning: change on metric in wrong direction. metric replaced with plan length.


5. The second approach

Since we cannot maximize a decreasing value, we tried to minimize total-waited-time. In this case, we add a new variable total-waited-time in the state representation and we increase this value each time we wait.

ScientificConf_exB.pddl

(define (domain ScientificConference)
  (:requirements :typing :fluents)
  [...]
  (:functions
   [...]
   (total-waited-time)
  )  ; end functions section
  [...]
   (:action WAIT-PRES-SESSION
     :parameters(?ses - pres-session)
     :precondition(and
         (< (currenttime) (time-pres-begin ?ses))
         ;(>= (currenttime) (- (time-pres-begin ?ses) 300))
         (>= (battery-level) (* (- (time-pres-begin ?ses) (currenttime)) (energyconsumed-per-second)))
         )
     :effect(and
         (increase (currenttime) (- (time-pres-begin ?ses) (currenttime)))
         (increase (total-waited-time) (- (time-pres-begin ?ses) (currenttime)))
         (decrease (battery-level) (* (- (time-pres-begin ?ses) (currenttime)) (energyconsumed-per-second)))
         )
   )
[...]


This second approach was not possible due to a second limitation of Metric-FF. It is not possible to optimize a value that are increased with non-constant expression.

Test file : test_socializeB.fct  (contain a line with " (:metric minimize (total-waited-time)) " )

 ../Metric-FF/ff -o ScientificConf_exB.pddl -f test_socializeB.fct -O
warning: non-constant effect on metric. metric replaced with plan length.

6. The third approach

We think about a other approach. The real problem is that WAIT actions takes too much time. Another idea is to fix an upper bound on the WAIT duration (fixed to 5 minutes). So, planner will need to introduce others actions to consume time. Also, we created an action SOCIALIZEUNTIL that do socialize until the time of a presentation minus 5 minutes.

ScientificConf_exC.pddl
(define (domain ScientificConference)
  (:requirements :typing :fluents)
  [...]
  (:functions
   [...]
  )  ; end functions section
  [...]
   (:action WAIT-PRES-SESSION
     :parameters(?ses - pres-session)
     :precondition(and
         (< (currenttime) (time-pres-begin ?ses))
         (>= (currenttime) (- (time-pres-begin ?ses) 300))
         (>= (battery-level) (* (- (time-pres-begin ?ses) (currenttime)) (energyconsumed-per-second)))
         )
     :effect(and
         (increase (currenttime) (- (time-pres-begin ?ses) (currenttime)))
         (decrease (battery-level) (* (- (time-pres-begin ?ses) (currenttime)) (energyconsumed-per-second)))
         )
   )
   (:action SOCIALIZEUNTIL
      :parameters(?loc - location ?ses - pres-session)
      :precondition(and
         (robot-at ?loc)
         (socializing-place ?loc)
         (registered)
         (< (currenttime) (- (time-pres-begin ?ses) 300))
         (>= (battery-level) (* 900 (energyconsumed-per-second)))
         )
      :effect(and
         (decrease (battery-level) (* 900 (energyconsumed-per-second)))
         (assign (currenttime) (- (time-pres-begin ?ses) 300))
         )
   )
[...]


Tests :
We test this approach with test1_nav.fct, an easy problem.

# With Enforced Hill-Climbing
../Metric-FF/ff -o ScientificConf_exC.pddl -f test1_nav.f

Plan :
Planner takes > 500MB of memory... no plan...

# Without Enforced Hill-Climbing
../Metric-FF/ff -o ScientificConf_exC.pddl -f test1_nav.f -E -h 1

Plan :
        0: GOTO STARTPLACE P15
        1: GOTO P15 STARTPLACE
        2: GOTO STARTPLACE P15
        3: GOTO P15 STARTPLACE
        4: GOTO STARTPLACE WP_6
        5: GOTO WP_6 STARTPLACE
        6: GOTO STARTPLACE P29
        7: GOTO P29 REGISTRATION
        8: REGISTER REGISTRATION
        9: GOTO REGISTRATION WP_1
       10: SOCIALIZEUNTIL WP_1 PRESSESSION1
       11: GOTO WP_1 STANDROOM_2
       12: WAIT-PRES-SESSION PRESSESSION1
       13: MAKE-PRESENTATION STANDROOM_2 PRESSESSION1

Time : 47sec

In our tests with normal domain, test1_nav.fct was resolved in 5 seconds. With our last modification, the performance of the planner is not satisfated. So, we have to reject this approach even it's working.