Rao,
As I read along the report, here are
comments I have in mind. I didn’t read the report as thoroughly as I
wish, so if you decide to pass the comments to the students, then please tell
them to contact me if they want to discuss any issue in more details. Well, if
I’m in ASU, then it would be much better…..
Here are the comments on the first
two reports that I just read. When I read more of them, I will send you follow
up emails on this topic.
- Preetha:
On the “Aspects
of the domain that had to be abstracted”
The
first two comments are absolutely correct and both planners need to be extended
to handle it. I think the numerical goal is a more
significant extension.
Comment #3, I think you can express
the fuel limitation by has another function “(capacity
?car)”. Please look at the domain description for some domain like
ZenoTravel in the competition.
Comment #4, even though the cost can’t
be explicitly specified, we are working on implicitly derive the action cost
from the plan metric field in PDDL2.1.
- Monika:
For problems that are “out-of-memory”,
you may be able to extend the amount of memory Java used to run a planner using
the option “-Xmx” followed by the amount
of memory used.
Regarding Monika’s domain, I
think it’s interesting and a hard domain. From the English description,
it has similar characteristic with the Rovers domain in the sense that it can
only capture “energizer” at certain location (and thus have to plan
how to go there and get it) but only has one mouse and thus produce serial plan
(instead of parallel plan in the Rovers domain in which we have several
Rovers).
You are right in pointed out the
limitation of the level of expressiveness that can be handled by two planners
like conditional effects or negative precondition etc. I totally agree that if
those features are all supported, then the domain description would be much
shorter and clearer.
In your original domain, I guess the
biggest problem for both planners is that your domain specifies a dynamic
world. Both planners can only work in the static world in which there is no
intervention from any object other than what manipulated by the selected
action. In your original domain, we are planning actions for the mouse, but the
cat seems to move independently of the mouse (I didn’t look closely at
the domain description but I guess that’s the way you want it). The
planners are not designed to work in these dynamic world scenarios.
For the problem that Sapa claims there is “no-solution” or out or
memory, I would like to get the domain and problem description in those cases
to look at what happened. For problem #1 in your test suite, please try to run
with ‘-no-auto’ option to see what happen.
I agree that adding duration does
not increase the complexity, but adding energizer does
actually increase the complexity, especially in this case when you can’t
get energizer whenever you want but have to go around in the right path to get
it. The metric quantity are very different from the logical True/False
predicate and at the current state, there are not as many effective techniques
to handle them.
I can see why Sapa
having more difficulties in handling this domain, compared to AltAlt. This is a grid-like domain in which the goals are
not independent and the negative interactions are of greater important than
domains such as logistics. Currently, Sapa does not
take care of negative predicate information as well as AltAlt.
If you find out why LPG failed to
solve any of your 5 problems, please let me know, I was very curious too. I
guess there is representational thing in your domain that trick
LPG. For my part, I will look at why Sapa can’t
solve the first simplest problem but could solve the other 4.
You made a correct and important
observation that “the planners did not deal well with plan having mouse
regress, or drift away from the cheese.” In fact, most of the heuristics
used in current planners are greedy and thus would have problems dealing with
those scenarios. I can think of one technique in FF to climbed
out of this hole by doing breath-first-search finding for (not immediate) children
of the current node that has better heuristic (in case where all the immediate
children appear to have worse heuristic values).
- Xin:
- Benton:
- Corey
Miller:
- Dan
Bryce:
- Josh:
- Menkes:
- Mike:
-