pucrs-automated-planning / javagp Goto Github PK

Reported by schapel on 2010-10-07 23:55 UTC
JavaGP sends all output to stderr. It should send output to stdout instead so the output can be redirected more easily.

Reported by meneguzzi on 2013-09-12 20:23 UTC
In some domains (like the one attached), if the initial state contains only objects of a certain type, the planner infers types wrongly during planning.

Original message from student below:
Defini que as ações enter e exit devem ter como parâmetro os tipos mais específicos que representam um corredor e uma sala, para ressaltar que o robô entra em uma sala a partir de um corredor e deve sair da sala para um corredor.

(:action enter
:parameters
(?from - hallwayloc
?room - room)
:precondition (and (at ?from) (connected ?from ?room))
:effect (and (at ?room) (not (at ?from)))
)

(:action exit
:parameters
(?room - room

?to - hallwayloc)
:precondition (and (at ?room) (connected ?to ?room))
:effect (and (at ?to) (not (at ?room)))
)

Tenho também a ação move cujos parâmetros devem ser do tipo hallwayloc, reforçando que a ação move deve ser utilizada somente para o deslocamento entre corredores.

(:action move
:parameters
(?from - hallwayloc
?to - hallwayloc)
:precondition (and (at ?from) (connected ?from ?to))
:effect (and (at ?to) (not (at ?from)))
)

E o predicado connected define que dois location - tipo base para hallwayloc e room - estão conectados um ao outro.

No problema pblonghall criei um local composto por 12 corredores conectados em ordem, inicializando com o robô no corredor hl1 e com objetivo de chegar ao corredor hl12. Entendi que de acordo com meus tipos declarados o robô deve chegar até o corredor hl12 utilizando somente a ação move, mas ao executar o planejador recebo o seguinte plano:

move(hl1,hl2)
enter(hl2,hl3)
enter(hl3,hl4)
enter(hl4,hl5)
move(hl5,hl6)
enter(hl6,hl7)
move(hl7,hl8)
move(hl8,hl9)
move(hl9,hl10)
enter(hl10,hl11)
enter(hl11,hl12)

Tenho outra versão do domínio e do mesmo problema sem utilizar tipos, onde restrinjo pelos predicados hallway e room nas pré-condições das ações, e nesta versão o plano utiliza somente a ação move.

Hoje baixei a última versão do JavaGP no sourceforge e os planos continuam os mesmos.

Reported by leandroshp on 2010-09-29 18:59 UTC
If you run the planner in this domain the generated plan is like this:

a(object)
b(object)
a(object)

That executes the action a twice, even if the planner already have a post condition in the state.
I know that the goal (a_ok(object), b_ok(object)) is redundant because to have b_ok first i need to have a_ok but for me is important to express the goal like this. In this case if I change the goal to just b_ok(object) it generates the right plan

a(object)
b(object)

Reported by sachini on 2015-05-15 04:43 UTC
I ran the abstract.pddl and problem file in /examples directory using javagp & it produced the following output.

SEVERE: Parser error at line 2, column 32 file (abstract.pddl) : Require key ":disjunctive-preconditions" forbidden due to parser requirement options.
SEVERE: Parser error at line 2, column 59 file (abstract.pddl) : Require key ":conditional-effects" forbidden due to parser requirement options.
SEVERE: Parser error at line 3, column 32 file (pb1.pddl) : Require key ":disjunctive-preconditions" forbidden due to parser requirement options.
SEVERE: Parser error at line 3, column 59 file (pb1.pddl) : Require key ":conditional-effects" forbidden due to parser requirement options.
SEVERE: Parser error at line 7, column 30 file (abstract.pddl) : Disjunctive formula cannot be defined without require key ":disjunctive-preconditions".
SEVERE: Parser warning at line 1, column 17 file (abstract.pddl) : Domain "disjunctive-pb" should be defined in a file "disjunctive-pb.pddl".
SEVERE: Parser warning at line 1, column 18 file (pb1.pddl) : problem "disjunctive-pb" must be defined in a file "disjunctive-pb.pddl".
INFO: Running planner, maximum memory: 2,649MB
INFO: Expanding graph
INFO: Extracting solution
INFO: Plan found with 1 steps
INFO: Planning took 115ms ( 0s )
INFO: Total memory used: 179MB
INFO: Plan found:
dijunctive_action(a,b)

INFO: Plan length: 1

Question 1

I believe these SEVERE errors are being produced by PDDL4J library. Since this manages to find a valid plan is it safe to assume the "errors" are being overridden somehow?

Question 2

I tried to run a custom PDDL with :equality definitions (i.e. actions have "=" statements (e.g. (= ?arg1 ?arg2) as preconditions). In this case this error manifests into a domain/problem file parsing issue that affects the plan-searching process. Are there any known workarounds for this problem?

Thank you for your attention.

Reported by arturfreitas on 2013-09-06 19:42 UTC
The bug on disjunction at precondition happens when changing from:
(:action enter
:parameters (?h ?r)
:precondition (and (hallway ?h) (room ?r) (at ?h) (connected ?h ?r))
:effect (and (not (at ?h)) (at ?r)))

to include:
(:action enter
:parameters (?h ?r)
:precondition (and (hallway ?h) (room ?r) (at ?h) (or (connected ?r ?h) (connected ?h ?r)))
:effect (and (not (at ?h)) (at ?r)))

using the following problem definition:

(define (problem pb1)
(:domain robby)
(:objects h1 h2 h3 r1 b1)
(:init
(hallway h1) (hallway h2) (hallway h3)
(beacon b1)
(room r1)
(connected h1 h2) (connected h2 h3) (connected h2 r1)
(connected h2 h1) (connected h3 h2) (connected r1 h2)
(in b1 r1)
(at h1)
)
(:goal (and (reported b1) (at h3))))

The planner suggests the action "enter(h1, r1)", but it would require the proposition "connected(h1, r1)" and this condition does not exist. The room r1 is connected only to h2.

Reported by leandroshp on 2010-10-22 16:21 UTC
For this two domains attached, that are "theoretically" the same domain, the planner is generating different plans.
The difference between this two domains is that domain1 uses the predicate "at" and domain2 uses the predicate "where" to represent the same property.

For domain1, the planner builds the following plan
bookFlight(from,eventcity,eventday,eventdayAfter)
bookTrain(from,eventcity,eventday,eventdayAfter)
bookHotel(eventcity,eventday,eventdayAfter)

For domain2, the planner builds the following plan
bookFlight(from,eventcity,eventday,eventdayAfter)
bookHotel(eventcity,eventday,eventdayAfter)

I see here two problems:
1- The planner shoudn't generate different plans for the same domain. I have a clue for this bug (I hope you get it :) ): if you look at the operator bookFlight, it has two effects flightBooked (...), at|where(...). The planner generates different plans because "at" and "where" have alphabetic different positions in relation to flightBooked, "at" comes before and "where" after. For example, if you change "at" for "cat" the planner builds the same plan, but if you change for "hat" it will build a different plan, equals to "where". (Dont ask me how I found it!)

2- Again, the plan for domain1 is not optimized because yu dont need bookTrain to reach the goal. Maybe this is related to the bug described on bug "3078208".

I hope i made my point clearly.

Reported by meneguzzi on 2013-08-31 12:24 UTC
Constants in PDDL are not being processed properly, see example of blocks world with a table constant in the domain.

Reported by sachini on 2015-05-06 21:54 UTC
I ran blocks world PDDL domain through JavaGP to see how the planning graph looked like. Although the generated graph has all required fluents, it is not in the typical preposition -> action -> preposition.... layers

As seen in attached files, there are no incoming edges from level 0 preposition level to action 1 level. Furthermore, in later preposition levels, there are prepositions such as (a), (b), which are undeclared in the problem/domain files.

I have attached the .dot file generated by the program & the resulting graph (drawn from graphviz) .png file for Blocks World PDDL domain.

Thank you very much
Sachini

Reported by ramonpereira on 2014-09-04 17:03 UTC
In this domain, the JavaGP results unnecessary actions for plan.
For example (in ZIP file - aperture.pddl, pb1.pddl, pb2.pddl, pb3.pddl):

• Correct:
  0: shoot(pbody,left,middle,red)
  1: enter(pbody,left,middle)
  2: exit(pbody,middle,right)
  3: shoot(pbody,right,middle,yellow)
  4: teleport(pbody,right,left,yellow,red)
  5: pick(pbody,left,companion)
  6: teleport(pbody,left,right,red,yellow)
  7: drop(pbody,right,companion)
• JavaGP:
  shoot(pbody,left,middle,yellow)
  shoot(pbody,left,middle,red)
  enter(pbody,left,middle)
  exit(pbody,middle,right)
  shoot(pbody,right,left,red)
  teleport(pbody,right,left,red,yellow)
  pick(pbody,left,companion)
  teleport(pbody,left,right,yellow,red)
  drop(pbody,right,companion)

TIPS to check (debug):

• Closed World Assumption; and
• Negative preconditions.

Reported by meneguzzi on 2010-10-05 20:28 UTC
Added feature request from David Luo
Hi Felipe,
Just a quick question, is there any parameter we can set in JAVAGP such that the graphplan algorithm can find all the possible plans for a goal?

Thanks!
-David

Reported by meneguzzi on 2013-08-29 01:38 UTC
Subtypes are not being processed correctly in action specifications. Whenever an action specifies a parameter as being of a type with subtypes, objects of the subtypes are not being accepted as valid for the action. See, in example robby.pddl, action "report", in pb0.pddl, the action should be immediately application, and yet, it does not recognize object room1 of type room to be the same type as location.

Reported by leandroshp on 2010-10-12 08:14 UTC
For this domain and problem attached, the planner is not finding the complete plan. The plan found is

sendVehicleInfo(vehicle)
getWeatherInfo(closestLocation)
mobilityInfo(closestLocation,vehicle)

instead of

sendVehicleInfo(vehicle)
getClosestLocation(location) < -------------------------------- this step needs do be performed in orded to add the "location(closestLocation)" to the beliefs
getWeatherInfo(closestLocation)
mobilityInfo(closestLocation,vehicle)

If this operator is removed, the plan is not found, but when it is added, it does not appear in the plan.

Command line interface fails to show help string when no parameters are provided.

Reported by aldo14 on 2013-04-29 22:08 UTC
If a goal state exists in the initial state, and achieving other goal states requires>1, the resulting plan includes additional actions to (essentially) re-achieve the pre-existing goal state rather than using appropriate no-ops.

For example, if goal is {at(Truck, a), ~blocked(A,B)}

Then the resultant plan is something like this; (* = unecessary action)
move("bulldozer1", "A")
move("truck1", "A", "C")*
unblock("bulldozer1", "A", "B")
move("truck1", "C", "A")*

Reported by schapel on 2010-10-17 22:34 UTC
JavaGP release notes should document:

• the dependence JavaGP on Jason and JavaCC, and that these JAR files need to be placed in the lib directory
• the assumption of JavaGP that ground terms bound to two different variables are distinct (e.g. in walk(X,Y) X and Y cannot be bound to the same ground term)
• the lack of the closed-world assumption, which means that negated preconditions that hold in the initial state must be explicitly stated
• using the switch -Mmx2g to give JavaGP more heap space will help JavaGP complete longer plans

I'm not quite sure what is causing this, but I'm seeing this error message:

SEVERE: --> The Problem has Negative Preconditions

SEVERE: Error parsing structure swap-vjason.asSyntax.parser.ParseException: [null:1] ArithExpr: first operand 'swap' is not numeric or variable.
        at jason.asSyntax.parser.as2j.arithm_expr(as2j.java:1278)
        at jason.asSyntax.parser.as2j.rel_expr(as2j.java:1155)
        at jason.asSyntax.parser.as2j.log_expr_factor(as2j.java:1121)
        at jason.asSyntax.parser.as2j.log_expr_trm(as2j.java:1086)
        at jason.asSyntax.parser.as2j.log_expr(as2j.java:1069)
        at jason.asSyntax.parser.as2j.term(as2j.java:950)
        at jason.asSyntax.Structure.parse(Structure.java:85)
        at graphplan.domain.jason.OperatorImpl.<init>(OperatorImpl.java:59)
        at graphplan.parser.PDDLPlannerAdapter.getDomainDescriptionFromPddlObject(PDDLPlannerAdapter.java:152)
        at graphplan.Graphplan.main(Graphplan.java:196)

Exception in thread "main" java.lang.NullPointerException
        at jason.asSyntax.Atom.<init>(Atom.java:49)
        at jason.asSyntax.Structure.<init>(Structure.java:64)
        at graphplan.domain.jason.OperatorImpl.<init>(OperatorImpl.java:59)
        at graphplan.parser.PDDLPlannerAdapter.getDomainDescriptionFromPddlObject(PDDLPlannerAdapter.java:152)
        at graphplan.Graphplan.main(Graphplan.java:196)

The swap-v action mentioned in the error message is as follows:

(:action swap-v
    :parameters (?pos1 ?house1 ?pos2 ?house2)
    :precondition (and
                   (tile ?pos1 ?house1)
                   (tile ?pos2 ?house2)
                   (vadj ?pos1 ?pos2)
                  )
    :effect (and
              (tile ?pos1 ?house2)
              (not (tile ?pos1 ?house1))
              (tile ?pos2 ?house1)
              (not (tile ?pos2 ?house2))
            )
  )

Let me know if you'd like to have the full pddls. I'm not posting them as they refer to an ongoing class assignment.

Just for the record, these PDDLs won't work on the web-planner either, but they do work on planning.domains, and generate a proper plan.

Reported by elpaquitooo on 2015-05-09 11:32 UTC
I'm starting to use this application, use the examples as shown in the help, but the application produces exceptions.

I Run: java -jar javagp.jar -nopddl -d examples/strips/ma-prodcell/domain.txt -p examples/strips/ma-prodcell/problem.txt

I get the following result:

INFORMACIÓN: Running planner, maximum memory: 247,5MB
INFORMACIÓN: Expanding graph
INFORMACIÓN: Goals not possible with 1 steps
INFORMACIÓN: Expanding graph
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at graphplan.graph.memo.mutexes.MutexCondition.verifyConditionsByIndexes(MutexCondition.java:30)
at graphplan.graph.memo.mutexes.StaticMutexesTable.isMutex(StaticMutexesTable.java:130)
at graphplan.graph.algorithm.impl.MutexGeneratorImpl.addActionMutexes(MutexGeneratorImpl.java:63)
at graphplan.graph.planning.PlanningGraph.expandGraph(PlanningGraph.java:229)
at graphplan.Graphplan.plan(Graphplan.java:386)
at graphplan.Graphplan.main(Graphplan.java:237)

Running

javagp -extractAllPossibleSolutions 9 -d rpgddl -p pb1.pddl

In the RPG domain makes the planner continue well beyond length 9 plans and never returns the actual solution of length 9.

pb1.txt
rpg.txt

@guilhermekrz, can you check this?

Reported by meneguzzi on 2013-03-28 17:40 UTC
From Fabien Lagriffoul

I'm not sure but I think there is a bug in the method:

MutexGeneratorImpl.isMutex()

I think that the last forloop:

for(Proposition effect : operator1.getEffects()) {...

should be with "operator2" instead of "operator1".

I'm working with the source package javagp-src-0.9.2.
line 119 in MutexGeneratorImpl.java

In Graphplan, line 63:
private static final String LOGGER_FILE = "logging.properties";
This file is located at "src/logging.properties".

Closed world assumption does not seem to be working on the attached RPG domain (it generates a useless destroy_sword action because it cannot find (not (carry)).
pb1.txt
rpg.txt

@ guilhermekrz if you have time to check this in detail, I'd appreciate it. No hurry though.

Reported by beppe712 on 2015-10-11 15:30 UTC
It seems when running any example problem with any key requirement other than :strips JavaGP will throw the error:

MacBook-Pro-di-Giuseppe:javagp-bin-1-2 Beppe$ java -jar javagp.jar -d examples/pddl/blocksworld/blocksworld.pddl -p examples/pddl/blocksworld/pb1.pddl
GRAVE: Parser error at line 2, column 24 file (blocksworld.pddl) : Require key ":equality" forbidden due to parser requirement options.
pddl4j.ParserException: Parse error in PDDL Domain
at graphplan.parser.PDDLPlannerAdapter.(PDDLPlannerAdapter.java:106)
at graphplan.Graphplan.main(Graphplan.java:195)

JavaGP will successfully find a plan in the case of Blocksworld without :equality. The same error applies to any other key, listing "Require key ":name-of-key" forbidden due to parser requirement options." for each key.

Best Regards

Reported by beppe712 on 2015-09-02 14:15 UTC
JavaGP fails to find a plan for some problems written in STRIPS. However, by including in the initial state the negation of all goals not fulfilled at the initial state level, it is possible obtain a valid plan despite such problem model being equivalent to the first.

This seems to be applicable for several problems and domains that I have written.

I have attached one simple domain/problem which presents such failure during planning.

Best regards

I've written a simple planning problem to test JavaGP and the planner fails to find the solution. Since JavaGP works for the blockworld example in examples/pddl, I suspect that the planner fails due to the presence of actions without parameters.

Follow the domain and problem definitions:
domain0.pddl

(define (domain domain0)
  (:predicates (oo)
               (pp)
               (qq))
  (:action firstAction  :parameters () :precondition (oo) :effect (and (not (oo)) (pp)))
  (:action secondAction :parameters () :precondition (pp) :effect (and (not (pp)) (qq)))
)

problem0.pddl

(define (problem problem0)
  (:domain domain0)
  (:init (oo))
  (:goal (qq))
)

The output received is the following:

$ java -jar javagp.jar -d examples/dummy/domain0.pddl -p examples/dummy/problem0.pddl
INFO: Running planner, maximum memory: 3,851.25MB
INFO: Expanding graph
INFO: Goals not possible with 1 steps
INFO: Expanding graph
INFO: Goals not possible with 2 steps
graphplan.graph.planning.PlanningGraphException: At graph level 4: Goals are not possible and graph has levelled off, plan is not possible.
	at graphplan.Graphplan.plan(Unknown Source)
	at graphplan.Graphplan.getPlanSolution(Unknown Source)
	at graphplan.Graphplan.main(Unknown Source)