Doing a planner

[Sanxano]

Hi everyone,

Our research group is working on a robotics project related to
automatic structure building and we would like to use EUROPA as a
planner for this task.

You can see the problem here:
http://sites.google.com/site/sanxano/inicio/Planning1.pdf


Thank you in advance and best regards.

[Michael J Iatauro]

Thank you for your continued interest in Europa and your patience with
the dev team =-).
It's not really clear from your model what the constraints are that
would determine what the correct sequence of wall construction would be.
Can you provide a more complete problem description? From the picture
you provided, it looks like (1) and (4) are "long" walls and (2) and (3)
are "short". Does construction have to start and end with a long wall?

~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 about your answer.
I'm very interested in using EUROPA in my work.

Sorry if the description is incomplete.
In general, main constraint is the structure stability, in the build
process.

This constraint is modeled as: You can't place a piece, if the pieces
which are supported are not placed before.

All pieces are equal.
A optimization in this algorithm may be the cost in take a piece u
other, (Distance in the piece store and the build location). But this
optimization is a the "item 2", now, I only would like to know if is
posible a generic description model that was adaptable to the size of
the structure.

In example 1,
piece_4 is support on on piece_2 and piece_3.
piece_2 is support on piece_1.
And piece_1 must be on the bulding location.

Regards.


On 22 ene, 22:07, Michael J Iatauro <Michael.J.Iata...@nasa.gov>
wrote:

[Minh Do]

My interpretation of the picture and the restrictions/constraints is: (1)
"wall" 1 is on the floor (basically acts as the floor); (2) walls 2 & 3
are on top of 1; (3) the "wall" 4 is like a roof on top of 2 & 3.

Therefore, the two correct sequences as mentioned in the documents are:
1,2,3,4 or 1,3,2,4.

Minh

>--
>You received this message because you are subscribed to the Google Groups
>"europa-users" group.
>To post to this group, send email to europa...@googlegroups.com.
>To unsubscribe from this group, send email to
>europa-users...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/europa-users?hl=en.
>

[Michael J Iatauro]

On 01/23/2012 12:42 AM, Sanxano wrote:
> Thanks about your answer.
> I'm very interested in using EUROPA in my work.
>
> Sorry if the description is incomplete.
> In general, main constraint is the structure stability, in the build
> process.
>
> This constraint is modeled as: You can't place a piece, if the pieces
> which are supported are not placed before.

Ah! This explains my misunderstanding. I was interpreting the diagram
as a top-down view, but both you and Minh Do were treating it as a side
view. In retrospect, that makes more sense.

>
> All pieces are equal.
> A optimization in this algorithm may be the cost in take a piece u
> other, (Distance in the piece store and the build location). But this
> optimization is a the "item 2", now, I only would like to know if is
> posible a generic description model that was adaptable to the size of
> the structure.
>
> In example 1,
> piece_4 is support on on piece_2 and piece_3.
> piece_2 is support on piece_1.
> And piece_1 must be on the bulding location.
>
> Regards.

As described, this sounds a lot like a BlocksWorld problem, with the
added feature that you have to have multiple "vertical" blocks
supporting horizontal blocks above them. It's unlike BlocksWorld,
though, in that you aren't really assembling the structure from pre-made
parts that are differently arranged--you're just producing a schedule
for construction of the walls.

The controlling idea seems to be the notion of one wall (I'm treating
floors and ceilings as walls because I haven't had enough coffee to
think of a better name for the sum of walls, ceilings, and floors)
supporting another. That could be represented either as objects (one of
the Rover examples uses objects to represent paths between locations in
a similar manner) or as tokens. Building a wall would then require
having already built every wall that supports it. That, however,
produces just a total order. In order to force a total order on
construction, you can create a timeline to represent the construction
sequence.

I can elaborate on all of this, but I don't want to rob you of all the
fun of modeling =-).

~MJI

[Sanxano]

Thanks again for your answers. We have been taking a look at the
Blocksworld example and we will try to follow your ideas in order to
tune it. Our idea is to have two or three types of “blocks” and to
define the possible relations among them.

But we have an additional question. In the Blocksworld example, the
main class description is:

class Goal extends Timeline
{
Block firstBlock;
Block secondBlock;
Block thirdBlock;
Operator operatorTL;
Arm armTL;

Goal()
{
firstBlock=new Block(this);
secondBlock=new Block(this);
thirdBlock=new Block(this);
operatorTL=new Operator();
armTL=new Arm();
}

predicate GoalAchieved { eq(duration, [1 1]); }
}

so, there are always 3 blocks (a static definition). In our
structures, we would like to have a variable number of “blocks”, i.e.
to build a square we need 4 “blocks”; to build a cube we need 12, etc.
The main issue is that it will be decided in runtime.

So, the question is if it is possible to have a generic description
model for different number of “blocks”. For example, 4 “blocks” of
type I, 20 “blocks” of type II, etc.

Thank you in advance and kind regards,




On 24 ene, 17:11, Michael J Iatauro <Michael.J.Iata...@nasa.gov>
wrote:

[Michael J Iatauro]

On 01/25/2012 04:15 AM, Sanxano wrote:
> Thanks again for your answers. We have been taking a look at the
> Blocksworld example and we will try to follow your ideas in order to

> tune it. Our idea is to have two or three types of �blocks� and to

> define the possible relations among them.
>
> But we have an additional question. In the Blocksworld example, the
> main class description is:
>
> class Goal extends Timeline
> {
> Block firstBlock;
> Block secondBlock;
> Block thirdBlock;
> Operator operatorTL;
> Arm armTL;
>
> Goal()
> {
> firstBlock=new Block(this);
> secondBlock=new Block(this);
> thirdBlock=new Block(this);
> operatorTL=new Operator();
> armTL=new Arm();
> }
>
> predicate GoalAchieved { eq(duration, [1 1]); }
> }
>
> so, there are always 3 blocks (a static definition). In our

> structures, we would like to have a variable number of �blocks�, i.e.
> to build a square we need 4 �blocks�; to build a cube we need 12, etc.

> The main issue is that it will be decided in runtime.
>
> So, the question is if it is possible to have a generic description

> model for different number of �blocks�. For example, 4 �blocks� of
> type I, 20 �blocks� of type II, etc.

Well, first of all, you don't have to create the "blocks" in a
constructor. Obviously, or you'd never be able to create an object =-).

There are a number of ways to set up an initial state at run-time. You
can generate and then load the NDDL initial state on demand, or you can
use the PSPlanDatabaseClient API to create the objects in code. In
either case, you have to wait until after you're done instantiating the
objects to invoke close().