Add support for location detection

[davesnowdon]

It would be useful for NAO to be able to recognise locations. One mechanism for doing this could be the use of wifi access points and signal strength. If a GPS sensor is attached then that could be used too.

naoutil should provide an interface to name & recognise locations that abstracts the technology used.

[AxelVoitier]

The underlying implementation would have to map named locations with a list of possible signatures. A signature would be defined by its type (wifi, gps, avahi, etc.) and its value (relevant only to the sub-component implementing the type).

When a signature does not correspond to any known named location, it would have to be stored in a list, the unknown list. If it is possible to tell that different signatures of different types correspond to the same place (such as, they are acquired at the same time), then they would have to be aggregated together in a list before being added to the unknown list. Later on, the NAO owner can map a signature or a list of signature with a named location. This could be done through a widget, a behaviour or naoutil API for instance.

The list of named locations associated with their signatures, plus the unknown list, have to be stored in a robot-dependent place. This could be a local file, specific ALMemory keys, or ALPreferences. The point is that any behaviour could have access to it through naoutil API.

We define two typical use case of this named location API:

• An application needs to store place-dependent data. For instance, an application doing SLAM.
• An application needs to react differently depending on the place the robot is. For instance, having different reactions between Home and Work places.

Some special locations could be used, by convention, by the client applications. E.g., an application could assume that there exist a typical scenario where Home and Work places is commonly used. The naoutil API does not have to provide anything special for that. It is up to the application developers to make such usage of special locations. The naoutil API documentation could simply list them as their adoptions-by-convention emerge.

Proposed naoutil API:

• SignatureProvider: a class/interface used to be sub-classed by provider of signatures.
• getNamedLocation(type=None): acquire signatures. If a match with a named location can be done, return the name. If not, store the signatures in the unknown list. Type parameter restricts the signature acquisition to specific providers. Can be None, a provider or a list of providers.
• getDetailedLocation(type=None): like getNamedLocation(). But also return full signature details (can be used to get GPS location for instance).
• getUnknownLocations(type=None): return all unknown location signatures of a certain type or list of type. If type is None, return for all types.
• matchNamedLocation(name, signature(s)): match signature(s) to a name. Remove the signature(s) from the unknown list is applicable.
• getSignaturesForName(name, type=None): get the list of signature for a certain named location.
• removeSignatureForName(name, signature(s)): remove the signature(S) of a location for a certain named location.

To complement.

[AxelVoitier]

Complementing the SignatureProvider abstract API:

• SignatureProvider.acquireSignature(): return a signature of the current location.
• SignatureProvider.matchSignatureInList(signature, signatureList): return the index of a matched signature. Allow the signature provider to define how a signature match to another (e.g.: let a gps signature provider to define a radius around a gps coordinate where another signature can be said to match it).