Abstract
This report documents the conception, design and implementation of an accessible building navigation system for the System Level Integration Practical.
Introduction
Project Ideas
- Building Management System
- Miniature Cooperative Robots
- LazerQuest style game
- Body Area Network
Chosen Project
After some deliberation, we selected the Building Navigation System project, because it fit well within the capabilities of the ProSpeckZ platform, and combined elements of hardware, software, and reasonably complex embedded programming. It would not be too difficult to implement a basic system, and extend it further as time and resources permitted.
The Building Navigation System is a good example of a real-world use for Speckled Computing, since it requires only a relatively small amount of network bandwidth and processing capability. By minimising the resources needed for each individual node, the overall system can contain more nodes for a given power budget, and since the accuracy of positional information is at least partially proportional to the number of simultaneously visible nodes, we can provide more accurate and useful navigation information.
After proposing this project, we discovered that an extremely similar project had been proposed and implemented for the SLIP course the previous year, and so we decided to modify our original proposal to make it unique. To this end, we decided to implement an alternative user interface, suitable for the visually impaired. Common user interface elements such as text or graphical displays and illuminated indicators are not suitable for blind users. Conversely, devices specifically tailored towards blind or visually impaired users, such as braille 'monitors' often require some relatively steep learning curve,. Ideally, our system should be usable by either sighted or blind users with minimal learning or training requirements.
System Design
The overall system design and formal specifications were discussed by the whole group, and are documented as part of the reports by Richard and Andy. However, in an attempt to keep this report somewhat standalone, I shall offer my Extremely Big Picture of the system as follows: (NB: There isn't really a picture)
- The wearable device carried by the user which gives verbal directions to a location, uploaded to it via the Reception GUI
- Wall mounted ProSpeckZ mesh network, which also communicates with the ServerNode and UserNode to determine when the UserNode should inform the user of new directions.
- A ProSpeckZ with PC interface that bridges the Server and the WallNode network.
- Manages the building map and determines shortest paths between requested locations.
- Configuration tool for setting up the building map and location of wallnodes within it.
Team Organisation
Our project team consisted of 5 people, with a variety of specialist skills. Both myself and Mark are studying Electronics and Computer Science, making us the obvious choice to implement any parts of the project that involved a hardware element. Richard was the strongest C programmer in the group, and hence undertook most of the serious embedded programming tasks, such as the network layer and application logic. The other 2 members of the group (Andy and Gwylim) focussed on the overall system design, and the PC user interface software, written in Java.
Management and Communication
Initially, we met as a whole group to discuss project ideas, and
once we settled on the Building Navigation System, to work out the
initial design structure.
After the first few weeks, once we
each had a good idea of our tasks within the overall system, group
collaboration became a lot more informal, and segregated into 'The
Embedded Guys' and 'The Java Guys'. Meetings took place on a somewhat
ad-hoc basis, often in the lab to solve a particular issue, or specify
a particular interface between subtasks being implemented by different
people.
Group communication also took place via a group Wiki, IRC channel, and over email. Our codebase (for both the ProSpeckZ and GUI sources) was maintained in an offsite SVN repository, to allow us to work on multiple machines at once without too many source version conflicts.
My Role
At the beginning of the project, tentative roles were assigned to each team member, but as the project progressed, we found that this was quite limiting, and ended up not being an accurate representation of the work undertaken by each person.
Having used the ProSpeckZ platform for various other projects, I was the most knowledgeable about its features and limitations, and was often called upon by other members of the group (and the other group also taking the SLIP course) to provide design insight or help locate code or hardware bugs.
Over the course of the project, I worked on virtually every ProSpeckZ subsystem to some extent, and provided design, testing and usability reviews of the GUI components, but my main contributions were at the hardware and driver / hardware API level. A large amount of the ProSpeckZ code was written using an Extreme Programming methodology by myself and Richard, with my knowledge of the ProSpeckZ platform, and his knowledge of general C programming and algorithm implementations.
More detailed descriptions of the tasks I worked on can be viewed via the links below.
Personal Contributions
- Compass Module
- Speech Synthesiser
- Hardware Integration and Packaging
- PC Communication Hardware
- Other Work
Conclusion
Team Evaluation
We were extremely lucky that all of our team members knew each other prior to the project and got on well together. This was not entirely a good thing however, as it lead to extremely informal management practices, which did hinder the progress of our project to some extent.
I was satisfied with my personal contributions, although I would have liked to design some actual hardware. Unfortunately, due to my other courses, I just didn't have the time to spend on hardware design and implementation from scratch.
System Evaluation
Overall, the system worked surprisingly well, given the number of problems we had over the duration of the course, and the overall workload of our team. The transport layer written by Richard is really what tied it all together, without which the chances of a working system would have been practically zero. The hardware all worked fine, which I ascribe to the fact that we didn't attempt anything particularly daring and custom-designed, but rather took existing commercial products and integrated them together. Whilst not as satisfying as building something out of basic parts, we decided that we should concentrate on delivering a working system.
Our timetables were a little optimistic, and we ended up delivering less than we originally planned for (the security tracking feature ended up being added right at the last minute, but we had considered a PDA User Device with map for sighted users, and various other features that never got completed).
Our system would be unlikely to work reliably in a real-world environment, but we did demonstrate the general concept and show that such a system is feasible. With a lot more work, I think this could actually prove a useful accessibility feature for new buildings, and hopefully one day such a system will see widespread use.