The simplification in this model is made even more extreme by the fact that, as with SHRDLU, there is no real robot there at all, and there are no real boxes to move about in 3-dimensional physical space. Rather, the robot and its world are simulated, and details of the simulation are held in a database containing a list of facts which are currently true in the world. There are two kinds of entries in the database. First, there are the entries which represent general, unchangeable, background facts about the objects in the world, such as the colours and sizes of the boxes on the table. Thus, when we ask the robot, for example, to move `the large red box', it is able to work out which box we must be referring to. Unchangeable facts of this sort are represented as lists like
[boxB size large] [boxB colour blue]
[boxb size small] [boxb colour blue]
[boxG size large] [boxG colour green]
Then there are the changeable facts, which only hold at particular times in the history of the `world'. These say where a particular box is located, what, if anything, the robot is holding, and so on. For example, the state of the world pictured in figure 3.7 might be represented by the following database entries:
[boxG on table] [boxr on boxG] [cleartop boxr]
[boxb on table] [boxR on boxb] [boxg on boxR]
[cleartop boxg] [holding boxB]
The cleartop entries make explicit which boxes can be directly picked up or covered with another box. The entry [holding boxB] indicates what the robot is currently holding. The robot might not have been holding anything, in which case the database would instead have contained the entry [handempty].
The MSBLOCKS automaton will respond to commands and questions in English like
Put the big green box onto the small green one.
Place a blue box on a red one.
Is there a large box on the table?
When we tell the simulated robot to do something like ``Put the big green box onto the small green one'' the program has to
Given the initial state shown in figure 3.7, the plan to achieve
the goal
[boxG on boxg]
requires several operations:
As the robot carries out the plan by performing these operations, the changeable part of the database is modified (or `updated'). One or more items is deleted from the database, and others are added to it (see figure 3.8). For instance, operation (1) above requires the program to
Delete: [holding boxB]Add: [boxB on table] [cleartop boxB] [handempty]
By the time operations (1)-(5) have been performed the database will have been changed quite considerably. The changeable part of it will now consist of
[handempty] [cleartop boxG] [boxG on boxg]
[cleartop boxr] [boxr on boxB] [boxB on table]
[boxb on table] [boxR on boxb] [boxg on boxR]
Figure 3.8 shows the final state of the boxes.
[IMAGE ]
Figure 3.8: The final state of the MSBLOCKS example.
If the robot were a real one -- for instance, storing crates in a warehouse -- then real boxes would be manipulated in a real physical environment. It would still be necessary to update the database after each operation to record the changes which have taken place in the environment. However, from the point of view of modelling the internal, `mental' organization of this kind of system, carrying out actions on real objects is unnecessary. In the MSBLOCKS simulation (as in SHRDLU and the many similar `blocks-world' programs it has inspired), the operations consist simply of the manipulation of symbolic structures. It would be quite possible to add to such a system a robotic arm that could manipulate actual boxes sitting on a physical table, but the main issues which are addressed by MSBLOCKS (and by SHRDLU) concern internal organization, rather than outwardly observable performances.