This directory contains code for the AIBO Local Map module. This file
is a diary of ideas and development for this code.


2002-12-12

A meeting two days ago with Dave has solidified the design of the AIBO
Local Map. It consists of two components:

1. An egocentric depth map that forms a hemisphere around the front of
   the AIBO. Each value in the depth map corresponds to the depth of the
   nearest object along a ray emanating from the AIBO's chest.

2. An egocentric height map for the local environment. This is a regular
   horizontal grid map.

Each map cell will consist of range/height information and other
attributes such as color and uncertainty. Uncertainty is one of the most
important as it will help the AIBO choose where to direct its attention
next to gain information about the environment. The appropriate header
files that describe the map data structures will contain more information
about all the cell attributes.

Since these maps are all egocentric, they must be updated when the AIBO
moves. Naturally, the Aibo's noisy motion will lend uncertainty to the
information in the maps. For the height map, this uncertainty can be
reflected in a decrese in the certainty values for cells in the map. For
the spherical depth map, the change is more complex. Motion may reveal
parts of objects that have been previously obscured. For this reason,
it will be necessary for moving objects to "smear" uncertainty behind 
them as they travel. The AIBO will be attracted to these uncertain
regions and will be motivated to check out newly revealed object faces
and terrain.

For both maps, almost any motion will result in cells on some of the
edges adopting an extremely low confidence value, as new, unfamiliar
terrain enters the local maps.

Because the AIBO systems software has an unreliable malloc, the map
data structures will be statically allocated. This means that the
C++ objects that handle the local map will not encapsulate the map
data but instead will be custodians of global map data. It's unlikely
that the AIBO will need more than one local map system running at any
time, so this is not an especially crippling limitation. Routines
that update the map will therefore be class methods--there should be
no need to instantiate a local map object.


2003-01-07

The choice has been made to implement both local maps with a
'double buffering' scheme--meaning that two buffers are used to store
both the DM and the HM each. When a major update is made to the maps,
existing information from the old DM and HM buffers is used to fill up
the new DM and HM buffers. This approach may seem overkill for the HM
especially, where it may seem that the data can just be shifted. In fact,
this method is more flexible, and in the future it may allow us to
compensate for the poor motion model of the AIBO by sampling and
combining possible transformations of data in the local maps.


2003-01-21

Meet AGM, the Aibo Global Map. A global height map in addition to the
local one, which means its allocentric. Uses some of the data structures
and configuration header information from the Local Map system, but is
also a system unto itself. A third file of C routines will mediate data
transfer between the local and global maps.

2003-02

Unit tests passed--it's integration time!
