About BlocksWorld example
Sanxano
I have been working in the blockworld example making some changes on
it (highlighted in red in the attached pdf file). You can see the
different plans obtained in each case. The instruction
“precedes(bottom4InitiallyOnTable.end, horizonEnd);” seems quite
relevant for the solver plan. When do we need to use it?
http://sites.google.com/site/sanxano/inicio/Blocksword.pdf
Thank you in advance and kind regards,
Michael J Iatauro
> Hi everyone,
>
> I have been working in the blockworld example making some changes on
> it (highlighted in red in the attached pdf file). You can see the
> different plans obtained in each case. The instruction
> relevant for the solver plan. When do we need to use it?
>
> http://sites.google.com/site/sanxano/inicio/Blocksword.pdf
>
> Thank you in advance and kind regards,
To make sure that I understand your situation correctly, you added a
fourth block to the model and to the goal state, and the planner found a
plan. I'll call this edit (1). In (1),
precedes(bottom4InitiallyOnTable.end, horizonEnd) is commented out. You
then created edit (2) by removing the fourth block from the goal state,
and the planner found the exact same plan as in (1), with the fourth
block stacked. Then, in edit (3), you commented in the precedence
constraint and the planner failed to find a plan. Is that right?
By "failed to find a plan", do you mean that it "timed out"--that is,
didn't find a complete plan in 500 steps--or did the planner conclude
that no plan existed? You might try running it for 1000 steps if it
timed out.
In either case, planning (and constraint satisfaction in general) can be
quite sensitive to decision and choice order, both of which can be quite
sensitive to the constraints in the plan, so it would be interesting to
compare the sequence of decisions that the planner makes between (2) and
(3) to see where they diverge.
Looking at the rule for Bottom::OnTable, it has two temporal constraints:
ends(Operator.PickUp pickUp);
met_by(Operator.PutDown putDown);
The met_by affects the start time, so I don't think it's relevant, but
the ends constraint is an equality between the two end times. So, in (2):
* bottom4InitiallyOnTable.start = 0 (from the explicit constraint)
* bottom4InitiallyOnTable.end = [1 +inf] (from the implicit duration
constraint)
* The sub-goal pickUp.end = [1 +inf] (from the ends constraint)
* The sub-goal pickUp.start = [-inf 0] (from the implicit duration
constraint)
In (3):
* bottom4InitiallyOnTable.end = [1 150]
* pickUp.end = [1 150]
* pickUp.start = [-inf 0]
It's possible that the more constrained case in (3) causes more tokens
to be within the horizon, creating more decisions for the planner.
~MJI
------------------
Michael J. Iatauro
Software Engineer
Dell | Services, Federal Government
NASA Ames Research Center
Office: 650-604-0662
Mail stop: 269-2
P.O. Box 1
Moffett Field, CA 94035-0001
www.dell.com/perotsystems
Sanxano
Thanks for your answer.
1. In respect of:
> By "failed to find a plan", do you mean that it "timed out"--that is,
> didn't find a complete plan in 500 steps--or did the planner conclude
> that no plan existed? You might try running it for 1000 steps if it
> timed out.
>
What's the different betwen steps and "int horizonEnd = 150;" (in de
code)
2. When you say:
> Looking at the rule for Bottom::OnTable, it has two temporal constraints:
>
> ends(Operator.PickUp pickUp);
> met_by(Operator.PutDown putDown);
>
> The met_by affects the start time, so I don't think it's relevant, but
> the ends constraint is an equality between the two end times. So, in (2):
>
> * bottom4InitiallyOnTable.start = 0 (from the explicit constraint)
> * bottom4InitiallyOnTable.end = [1 +inf] (from the implicit duration
> constraint)
> * The sub-goal pickUp.end = [1 +inf] (from the ends constraint)
> * The sub-goal pickUp.start = [-inf 0] (from the implicit duration
> constraint)
>
May be that the constranis are not very restrictives?
It's posible think that in (2) "there is a goal plan" on block 4?
3. And finaly
Say what happens in (3) happens in (0), where (0) is the initial
example (without changes).
In (0)
fact(Bottom.OnTable bottom3InitiallyOnTable);
eq(bottom3InitiallyOnTable.theBlock, goalTower.thirdBlock);
eq(bottom3InitiallyOnTable.start, 0);
//precedes(bottom3InitiallyOnTable.end, horizonEnd);
<<Find a plan>>
And in (0')
fact(Bottom.OnTable bottom3InitiallyOnTable);
eq(bottom3InitiallyOnTable.theBlock, goalTower.thirdBlock);
eq(bottom3InitiallyOnTable.start, 0);
precedes(bottom3InitiallyOnTable.end, horizonEnd);
<<Don't find a plan (in 2500 steps).>>
In summary, I'm going to reorder some constraints, to see if I can
find some solution.
Regards.
On 20 dic, 17:34, Michael J Iatauro <Michael.J.Iata...@nasa.gov>
wrote:
>
> > Hi everyone,
>
> > I have been working in the blockworld example making some changes on
> > it (highlighted in red in the attached pdf file). You can see the
> > different plans obtained in each case. The instruction
Michael J Iatauro
> Hi Michael,
>
> Thanks for your answer.
>
> 1. In respect of:
>>
>> By "failed to find a plan", do you mean that it "timed out"--that is,
>> didn't find a complete plan in 500 steps--or did the planner conclude
>> that no plan existed? You might try running it for 1000 steps if it
>> timed out.
>>
>
> In (3) I tried 2500 steps! and it diden't find a complete plan.
So it timed out. Interesting.
> What's the different betwen steps and "int horizonEnd = 150;" (in de
> code)
The planning horizon is the span of plan-time over which the planner
will search. Any flaws that lay outside of that horizon will be
ignored. Setting a number of steps just limits how many decisions the
planner will try before it stops. There are three ways in which
planning stops:
1. A plan is found; there are no remaining flaws within the horizon,
the plan is constraint consistent, and the solver achieved this in less
than the maximum number of steps.
2. The planner "times out"; flaws remain within the horizon after the
planner has made the maximum number of decisions.
3. The search is exhausted; the entire search tree has been expanded in
less than the maximum steps, and it all leads to constraint inconsistencies.
>
>
> 2. When you say:
>
>> Looking at the rule for Bottom::OnTable, it has two temporal constraints:
>>
>> ends(Operator.PickUp pickUp);
>> met_by(Operator.PutDown putDown);
>>
>> The met_by affects the start time, so I don't think it's relevant, but
>> the ends constraint is an equality between the two end times. So, in (2):
>>
>> * bottom4InitiallyOnTable.start = 0 (from the explicit constraint)
>> * bottom4InitiallyOnTable.end = [1 +inf] (from the implicit duration
>> constraint)
>> * The sub-goal pickUp.end = [1 +inf] (from the ends constraint)
>> * The sub-goal pickUp.start = [-inf 0] (from the implicit duration
>> constraint)
>>
>
> I'm not very sure what do you want to tell me.
> May be that the constranis are not very restrictives?
> It's posible think that in (2) "there is a goal plan" on block 4?
I'm not very sure either. It's just the major difference between the
two, and so the first thing that caught my attention. I wish I could
dedicate more mind-share to this, 'cos it seems interesting, but we're
in a bit of a crunch at work.