09/11/07 - Architecture and first hardware.

The previous few weeks (yes, all of the next few blog entries will be back dated - since I haven't been adding them to my blog as I went along, something which I will have to do from now on) we have been ordering the required hardware components, researching 3D sound localization and designing the frameworks general architecture.

So far, we have received the ultrasonic sensor and the XBee modules. Graham has some great pictures in his blog. Like this one of us testing the ultrasonic sensor. We have also ordered more parts (digital compass, accelerometer) and Graham will begin constructing the headset as soon as they arrive. The XBee module will be used solely as a wireless serial connection between the headset and host computer.

The frameworks planned architecture:
The framework will be built in a highly modular architecture, with each component being completely self contained. The components will communicate with each other through a central message router, over TCP/IP. Any complex subsystem will be implemented in a separate component. This allows us to easily add new components or remove old ones, change how the messages are routed between them, monitor the messages or control the components through external GUI programs.

The applications can use the framework in two ways:

1. They can be implemented as a completely separate program (or set of programs) which communicate(s) with the framework over TCP/IP. It would, effectively, act the same as any other component in the framework and has the full power of the framework at it's disposal.
2. They can be implemented as an event based python script, being executed as part of the message router. How flexible or powerful this method is will depend on the API developed, but an interface to send and receive commands to/from the router (and therefore to and from the rest of the framework) will exist, making it almost as powerful as the alternative option. This method would be able to make full use of the routers integrated state machine (more on this in a later post) and is highly event based, making this method much easier to develop applications with. Python is also a very convenient high level language.

Option 2 would be the preferred method of developing applications, but it may also be useful (especially for the development of tools and new, additional components) to allow for option 1.