Information Technology Reference
In-Depth Information
Figure 9.15.
A planning problem with blocks
A
A
B
B
C
D
C
D
initial state
goal state
5.
Consider the reachable predicate defined in figure 9.3. Suppose the second
clause had been this:
reachable(S1,[M|L],S3) :-
reachable(S2,L,S3), legal_move(S1,M,S2).
Are there problems where this might work better than the previous version? Are
there problems where it might do worse?
6.
The bplan predicate presented in figure 9.8 can run forever, looking for longer
and longer plans, if it happens that there is no way to achieve the goal. Modify
the predicate so that it takes an extra argument n and will eventually stop with
failure if there is no plan of length n or less.
7.
This exercise returns to a blocks world similar to the one shown in figure 8.16.
Imagine that there is a group of blocks (cubes, for simplicity) arranged in some
configuration on a table in front of a robot, and you would like the robot to
rearrange them without having to tell it how to do so. Assume that there is a
single type of action, moving a block to a location , where a location is either an area
on the table or on top of another block. This action can only be performed by the
robot if there is nothing on the blocks and nothing at the desired location.
For the example problem shown in figure 9.15, an acceptable plan is this: move
block A to area 5 (on the table), move block B onto block D, and move block A
onto block B.
Use situations and fluents as the representation of the states in this blocks world.
For example, after performing the actions in this plan, the final situation would
be [move(a,b),move(b,d),move(a,area5)] . You will only need to use one flu-
ent, located_on (
)
b , l , s
,
which should hold when block b is at location l in
situation s .
Search WWH ::




Custom Search