Präsentation

Zunächst einmal: Wir haben einen überarbeiteten Prototypen (um das blöde XBee-Shield einzusparen, und um einen Taster statt Drehknopf zu verwenden, wie es auch im fertigen Element geschehen soll:
Das reale Version wird ja etwas kleiner, die Gehäuse sollen dann beispielsweise wie folgt aussehen:
Für den Fussballfan:

Die Edelversion in Mahagoni:
Und die Nerd-Version :-)
Jedenfalls haben wir jetzt unsere Abschlusspräsentation fertig, die Miniplatine ist auch gefräst und wartet auf den Bootloader (wenn wir den Mikrokontroller nicht schon bei Auflöten gegrillt haben :-)

Software

Da sich unser Projekt so langsam dem Ende nähert, dachte ich, ich schreibe nochmal was zu der aktuellsten Version der von uns genutzten Software.

Da unser Prototyp mit Ubisense arbeitet, wir aber auch an Orten, an denen es keine Ubisense-Sensoren gibt, arbeiten und testen wollten, haben wir in Processing ein kleines Programm geschrieben, dass den Ubisense-Server simuliert. Darin lassen sich die Positionen von unserem Test-Arduino und drei Freunden beliebig im Raum verschieben. Die Positionen werden dann in Nachrichten verpackt, die denen des Ubisense-Servers am Lehrstuhl entsprechen und per UDP an denselben Port gesendet.

An diesem Port lauscht dann unser zweites Processing-Programm, dass die Nachrichten wie in früheren Posts auf diesem Blog beschrieben interpretiert und über die serielle Schnittstelle per XBee an den Arduino weiterleitet.

Da wir inzwischen die Positionen von drei Freunden senden, mussten wir bei der Übertragung dafür sorgen, dass der Arduino die verschiedenen Datenpakete unterscheiden kann. Dazu senden wir für jede Positionsangabe (z.B. Friend2, X-Position) zwei Bytes. Zuerst eines, das dem Arduino mitteilt, welche Position nun übermittelt wird und danach die Position selbst.

Die weitere Interpretation der Daten geschieht dann auf dem Arduino:
Während eines Durchlaufs des Loops wird zunächst eine Funktion "getPositions()" aufgerufen, die den Buffer der seriellen Schnittstelle prüft und eventuell dort zwischengespeicherte Nachrichten einliest. Nach dem Aufruf dieser Funktion haben wir also schon einmal die Positionsdaten.
Als nächstes wird der Kompass ausgelesen. Dazu ist eine Kommunikation per I²C-Bus notwendig, für die es dankenswerterweise die Library "wire" für den Arduino gibt. Damit ist die Abfrage dann kein größeres Problem - Es reicht, dem Kompass den Befehl zukommen zu lassen, dass man gerne die aktuellen Daten hätte und dann auf den Empfang zu warten.
Nachdem die Kompassdaten dann erfasst wurden, geht es daran, aus den Positionsdaten und der Ausrichtung des FriendLocators die Richtung zu bestimmen, in der sich der aktuell ausgewählte Freund befindet. Dazu berechnen wir zunächst mithilfe der avr lib-c den Arkustangens der sich aus der eigenen und der Position des aktuell ausgewählten Freundes ergibt. Den erhaltenen Wert im Bogenmaß rechnen wir dann in Grad um und subtrahieren den vom Kompass erhaltenen Winkel.
Jetzt lässt sich ohne Probleme der so erhaltene Winkel einer LED auf dem Shield des Prototypen zuordnen. Zunächst wird aber nur gespeichert, welche LED später angeschaltet werden soll. Bevor die LED dann tatsächlich angeschaltet wird, berechnen wir noch die Distanz zwischen der eigenen Position und derjenigen des ausgewählten Freundes. Die Distanz beeinflußt die Frequenz, in der die LED blinkt: Je näher man dem ausgewählten Freund kommt, desto schneller blinkt die LED.

Der Code für die besprochenen Programme liegt frei in meiner Dropbox:
Ubisense-Simulation (Processing)
UDP-Client (Processing)
Arduino-Code

Miniaturisieren...

Da unser Protyp noch ein wenig groß geraten ist, um ihn bequem am Handgelenk tragen zu können, gibt's jetzt den Entwurf zu einem entsprechend kleineren Modul, in dem auf eine Volumen von ca. 35,6*25,4*8 mm (Innenmass) alle Notwendigen Bestandteile integriert sind.
Den Aufbau zeigt folgende Skizze:
Dies sind im einzelnen ein Atmega-Microcontroller mit den Anzeige-Leds und einem Taster auf der oberen Platineseite. Da ein Drehschalter, Poti oder ähnliches recht groß und aufgrund dem verdrehenden Gehäuse auch stör- und verschmutzungsanfällig ist, sind wir doch zu einem Taster mit drei AnzeigeLeds für die Funktion übergegangen (also 3 Funktionen für den Normalbenutzer und 8 für den Informatiker :-). Indem über der Platine eine dünne, und damit flexible Oberfläche als obere Abdeckung verwendet wird, kann damit die ganze Fläche zum Drücken des Tasters verwendet werden. Glücklicherweise bietet der Atmega in der SMD-Variante zwei weitere Ausgabepins, sonst wäre die Anzeige etwas kompliziert geworden. Als Taktgeber dient hier ein 8MHz-Resonator, da kleiner und mit integrierten Kondensatoren im Vergleich zum Quartz (wobei der Atmega auch einen integrierten 8MHz Quartz hat, aber so kann man ihn auch durch einen anderen ersetzen, falls es mal einen entsprechenden 16MHz Resonator gibt.

Auf der Unterseite der Platine ist dann ein GPS-Modul (basierend auf dem Aufbau des Micro-Mini von Sparkfun.
und ein Kompass (HMC 6352, da für unsere Zwecke ein einfacher 2D-Kompass reicht) untergebracht.

Darunter liegt dann die Batterie, wobei auf der Unterseite der Platine und der Oberseite des darunter liegenden XBee-Moduls die entsprechenden Kontaktflächen aufgebracht sind. Die Batterie kann dann durch eine seitliche Öffnung (Einschub) ausgetauscht werden.
Die Platinenober- und Unterseite wird damit später wie folgt aussehen:
Eine Möglichkeit, das darumherumliegende Gehäuse zu erstellen ist damit abgesehen vom 3d-Drucker ein Schichtmodell mit dem Lasercutter aus 2mm dicken Platten (Holz, Plexiglas, etc) in 4 "Rahmenschichten", wobei an den mittleren beiden (oder einer davon) die Befestigungen für das Armband sind, und die über die verschiedenen Inneformen die einzelnen Elektronikelemente tragen. Als obere und untere Abdeckung dient dann eine entsprechend dünne Deckfläche (lasergraviertes Furnierholz, bedruckte Transparentfolie). Die Innenabmessungen sind im Folgenden skizziert:
Der Mikrokontroller soll dann später über insgesamt 3 serielle Schnittstellen mit den einzelnen Modulen kommunizieren:
An der "normalen" seriellen Schnittstelle hängt das XBee-Modul, an den AnalogPins 4 und 5 über das I2C Protokoll der Digitalkompass und (noch viel später mal :-) an den durch den SMD-Atmega gegebenen weiteren Pins 20m und 21 das GPS-Modul, das mittels der TinyGPS und der NewSoftSerial-Bibliothek mit dem Atmega kommuniziert.

Victory!

Die Xbees sind wieder aus ihrem Schlaf (an dem wir wohl nicht ganz unschuldig waren) erwacht. "Was war denn nun das Problem?" werdet ihr fragen. Nun, ich gebe euch einen Tipp: Die API-Function Sets sind nichts, was man auf das Modem schreiben möchte, ohne zu wissen, was API ist (wir haben das natürlich trotzdem gemacht). Mit den normalen AT-Kommandos gibt sich das XBee dann nämlich scheinbar nicht mehr ab. 

Dann gibts auch keine Kommunikation mehr und überhaupt ist alles, als wäre das XBee gar nicht mehr da. In dem Falle hilft das Setzen des links hervorgehobenen Hakens enorm weiter. 

Nicht, dass dann alles wieder ohne Probleme funktionieren würde (auslesen und schreiben der Firmware klappte trotzdem nur nach x > 5 Versuchen), aber es besteht dann zumindest wieder die Möglichkeit, alles zum laufen zu bringen. 

Eine weitere Erkenntnis: Der Reset-Button auf dem Arduino-Shield bewirkt scheinbar keinen Reset des XBee-Moduls, sondern nur des Arduinos. Wenn X-CTU also nach einem Reset des XBee-Moduls fragt, dann muss ein Stück Draht zwischen dem RST- und dem GND-Pin des XBees her. Das erleichtert einiges.

Inzwischen befinden sich beide XBees wieder sicher im AT-Modus und funken glücklich miteinander um die Wette.

UbiSense-Probleme und ihre Lösung

Für unseren Prototyp haben wir uns vorerst für die Ortung via UbiSense entschlossen. Da der UbiSense-Server am Lehrstuhl schon fertig aufbereitete Positionsdaten im XML-Format versendet, gibt es in diesem Fall nämlich angenehm wenige Störfaktoren auf unserer Seite. Das einzige Problem ist es nun, an die Daten heranzukommen.

Die Kommunikation läuft folgendermaßen ab:

1) Zunächst muss man ein UbiSense-Endgerät beim Server auf seine IP-Addresse registrieren, damit man die Daten überhaupt erst einmal zugesendet bekommt.

2) Danach fängt der Server an, UDP-Pakete mit den XML-Daten auf einem bestimmten Port zu senden. Diese müssen empfangen und interpretiert werden.

Der erste Punkt ist relativ schnell in Processing geschrieben, wenn man die mitgelieferte Network-Library nutzt:

import processing.net.*;

Client ctrlMsg;
String ubisenseId = "020-000-024-100";

void setup()
{
    size(200,200);
    ctrlMsg = new Client(this, "137.226.56.44", 3501);
    ctrlMsg.write("register " + ubisenseId + " " + ctrlMsg.ip());
}

Nun gilt es allerdings, Daten auf dem UDP-Port zu empfangen und zu parsen. Der Empfang war das erste Problem. Zunächst mal wunderten wir uns, dass wir die Daten zwar im Terminal anschauen konnten, es uns aber nicht möglich war, mit Processing an die Daten zu kommen. Wie wir später herausgefunden haben, spricht Processing von Hause aus kein UDP und konnte damit auch nichts mit den eintreffenden Paketen anfangen.
Zum Glück gibt es eine Library, die grundlegende UDP-Funktionalitäten zur Verfügung stellt. Also schon einmal ein Problem weniger. Als nächstes müssen die XML-Daten geparsed werden. Natürlich könnte man jetzt eine Library fürs Parsen von XML-Daten hernehmen oder gar selbst implementieren, aber weil die zu parsenden Daten ja doch relativ speziell sind, haben wir uns nun doch für reguläre Ausdrücke entschieden (es ist einfach unglaublich viel einfacher). Das ganze (Empfang von Daten und Parsen) sieht in Processing dann so aus:

import hypermedia.net.*;

UDP udp;
String[] posData = new String[4];

void setup()
{
    udp = new UDP(this, 3501);
    udp.listen(true);
}

void receive(byte[] data)
{
    String inputString = new String(data);  
    String[] id = match(inputString, "id=\"([^\"]*)\"");
    String[] posX = match(inputString, "posX=\"([^\"]*)\"");
    String[] posY = match(inputString, "posY=\"([^\"]*)\"");
    String[] posZ = match(inputString, "posZ=\"([^\"]*)\"");
    posData[0] = id[1];
    posData[1] = posX[1];
    posData[2] = posY[1];
    posData[3] = posZ[1];
}


In posData stehen nun also die aktuellen Positionsdaten.

Der nächste Schritt ist jetzt, den ganzen Kram auch am UbiSense-Server zu testen. Es funktioniert zwar mit einem Testprogramm, dass ähnliche Botschaften auf einen UDP-Port sendet, aber man weiß ja nie.

Ein weiteres Ziel: Die XBee-Module dazu bewegen, wieder mit uns zu sprechen. Wenn sie sich dazu dann mal entschließen sollten, können wir die restliche Kommunikation fertig machen. Im Grunde muss der Arduino ja jetzt nur noch per XBee alle paar Sekunden die aktuelle Position anfragen und von Processing zugeschickt bekommen. Dazu aber dann später mehr, jetzt naht das Halbfinale und ich habe keine Lust mehr, noch länger vorm Rechner zu sitzen ;)

Es wird Ernst...

Nach ein wenig probieren und googeln, nachdem das nichts wurde (Eine Woche im Labor ersetzt den Tag in der Bücherei, oder wie ging der Spruch noch mal...): Die 2.4 Ghz Frequenz ist gar nicht so leicht abschirmbar, und Richtfunkantennen zu groß, mit der Funkpeilung wird also nichts.
Die Peilung per Magicmap kann anscheinend auch nur Räume unterscheiden, ist damit auch nicht verwendbar.
Im Rennen bleibt damit vor allem das GPS-System, vor allem, da wir nur Richtungsanzeigen brauchen und damit der Positionsoffset bei Sucher und zu Suchendem grösstenteils gleich ist. Nachteilig dabei ist, das dann auch ein Digitalkompass verwendet werden muss (gleiches gilt für die UbiSense-Lösung, die wir zum Ausprobieren verwenden), so das die Anzeige per (magnetisch bewegtem) Pfeil wegfällt - zumindest dürfte das sonst den Magnetkompass ein wenig verwirren.
Damit bleibt fürs erste die Anzeige mittels LED-Kreis. Ein erster Prototyp zum Testen:
Später kann das Poti als recht klobiges Bauelement auf die Rückseite verlegt werden und die gesamte Elektronik gegenüber dem Armband verdreht werden, so das ein einfaches Austauschen der Hülle möglich ist. Ausserdem kann ein noch freier Analogeingang mit der Hülle verbunden werden, so das zwei Armbänder miteinander kommunizieren können, um z.B. einen anderen Freund einzuspeichern.

Bisher sieht der Versuchsaufbau also so aus: Über das UbiSense-Modul kann der entsprechende Server die Position des Armbandes bestimmen und sendet dieses über xBees an alle Teilnehmer. Diese können dann aus ihrer und der Position der zu findenen Person die Richtung bestimmen, in der sie ist, welche dann mit den Kompassdaten zum Anzeigesignal verarbeitet werden und damit die entsprechende LED aufleuchtet. Die zu findenen Ob- und Subjekte können dabei über ein Poti ausgewählt werden. Eine Stellung dient dabei später zum Einspeichern neuer Freunde und eine weitere nutzt den LED-Ring als Uhr.

Insgesamt wird der Aufbau allerdings aufgrund des zu verwendenen GPS-Moduls (bzw. UbiSense-Moduls), eines Digitalkompasses und schliesslich des xBee-Moduls recht teuer und auch verhältnismässig groß.

Eine einfache Alternative wäre dann einfach nur ein xBee-Modul in Kombination mit dem Arduino zu verwenden, und das Arband als Leuchtring zu gestalten. In diesem Fall sendet man einfach nur die Frage "wo seid ihr" und die Armbänder der angesprochenen leuchten auf (und vibrieren im Idealfall). Die Positionssuche geschieht dann optisch, indem die Angesprochenen dann mit ihren leuchtenden Armbändern winken oder örtlich durch laufen zu einem vereinbarten Treffpunkt :-).
Um das xBee-Modul und den Arduino dann wenigstens etwas zu fordern, kann man dann natürlich auch wieder Einfachbotschaften senden oder hübsche graphische Effekt (Farbwechsel etc) machen. Ausserdem könnte das ganze zusammensteckbar aus Anzeigemodulen aufgebaut werden (bastel dir dein Wunscharmband :-)
So sieht das zwar noch hübsch hässlich aus, aber man kann das ja noch optimieren: Das Band wird ja maximal so breit wie das xBee Modul als breitestes Bauelement. damit ist noch über und unter der LED-Matrix zur Anzeige des "anrufenden" Namens noch platz für hintergrundbeleuchtete Schnörkel, die sich dann über das ganze Armband als Rahmen hinziehen. Abgesehen vom xBee kann sich das Band dann auch verjüngen und kleiner Symbole für Fixbotschaften enthalten, die dann durch Taster (das Potis zu klobig sind) ausgewählt werden.

Technikgedanken

Eine weitere Richtungsanzeige wäre über eine sogenannte Dopplerpeilung möglich, wie sie im Amateurfunk für "Fuchsjagden" verwendet wird. In diesem Fall müssten die Kunden unseres Geräts lediglich eine Amateurfunkprüfung je nach verwendetem Frequenzbereich machen. Da diese Dopplerpeilung jedoch wahrscheinlich nur schlecht mit den kurzwelligen Funkfrequenzen funktionieren dürfte, wäre das Device etwas grösser, aber die 4 halbmeterlangen Antennen kann man ja gut als Hutersatz tragen. Ausserdem können wir dann die bereits kommerziell erhältlichen Geräte verwenden, die es zwischen 400 und 6000 US$ kosten... Mmh, vielleicht wäre dann eine GPS-Shield oder iPhone doch etwas preiswerter :-)
Es gibt auch eine Positionsbestimmung per WLan der Humboldt-Universität in Berlin namens MagicMap (Ganauigkeit im Meterbereich, also ausreichend für unseren Zweck), allerdings müssen zu diesem zweck mindestens drei Accesspoints vorhanden sein - und deren Position bekannt sein, man kann also nicht einfach die Wlan-Shields der Arduinos bei einer großen Anzahl Personen gegenseitig nutzten, allerdings müsste es funktionieren, wenn wenigstens 3 eine Kombination aus WLan und GPS an ihrem Gerät haben. Hier könnte man wieder einen Grund für zwei Preisklassen haben. Die billige funktioniert nur, wenn entweder genügend Personen mit der teureren GPS-Klasse in der Nähe sind oder der Veranstalter/in der Umgebung entsprechende Access-Points mit bekanntem Standort in der Nähe sind. Gibt man mehr Geld aus, kann einem das egal sein.
Da aber die die WLan-Shields auch wieder nicht ganz billig sind, bleibt die xbee-Lösung mit Richtfunkpeilung immer noch die bessere Variante, wenn sie denn dann irgendwie funktionieren sollte.

Grundüberlegungen für den FriendLocator - Teil 2

Da das, wenn auch einfach zu erstellende und anzusteuernde LED-Display nicht unbedingt das hübschste ist, haben wir uns noch ein paar Überlegungen zu Alternativen gemacht.
Eine Alternative ist die Verwendung eines LCD-Displays, beispielsweise die Verwendung (zu Testzwecken) von alten Handydisplays, da zu kaufende leider deutlich zu gr0ß sind. Hier wird aber die Ansteuerung/Kontaktierung aufgrund der fehlenden Dokumentation/Miniaturisierung nicht einfach werden.

Ein ganz lustige Alternative wäre, angesichts der Community im Netz und den Möglichkeiten, die das FabLab bietet, ein Analoganzeige im Steampunkstil zu machen. Dies kommt der Kompassfunktion entgegen, ist also aus intuitiver Sicht leicht zu verstehen.
Realisiert werden kann dies, indem die entsprechende Anzeigenadel/-pfeil entweder durch einen Steppermotor (zu groß und aufwendig ansteuerbar) oder einfach über Magnetfelder - also zwei kleine über Kreuz angeordnete Elektromagnete ausgerichtet wird. Die Entfernung kann dann durch Zittern der Nadel angezeigt werden: Starkes Zittern bedeutet weite Enfernung und damit schlechtes Ausrichten, je näher - und damit stärker - das Signal ist, desto besser (und ruhiger) wird die Nadel ausgerichtet.

Zur Wahl des anzuzeigenden Freundes (oder auch der zu sendenden Botschaft) können dann verdrehbare Aussenringe (veränderliche Widerstände) dienen, auf denen die entsprechenden Freunde/Botschaften markiert sind. D.h. man würde beispielsweise den Freund und die zu sendende Botschaft nach "Norden" (also eine bestimmte Position) drehen und mit einem OK-Button betätigen. Alternativ kann auch nur ein Ring verwendet werden, und beispielsweise durch drücken des einen (oberen) Tasters der Empfänger und mit dem zweiten (unteren) Taster die Botschaft ausgewählt werden. Zur Anzeige leuchtet dann der entsprechende Taster als Indikator auf, und der Pfeil zeigt auf die entsprechende Ringposition.
(Die verrücktere, völlig übertriebende Fassung wäre natürlich, das sich dann die Ringe automatisch in die entsprechende Anzeigeposition drehen, das wäre naürlich vom Effekt her großartig, aber leider sehr aufwendig einzubauen, schlecht zu miniaturisieren, damit teuer und zusätzlich wahrscheinlich enorm störanfällig - mit anderen Worten: Genau das will ich haben :-)

Diese Variante ist dann allerdings nicht gut modifizierbar - also im Bezug auf andere Botschaften, neue Freunde etc.
Hierfür könnte man zwar einen "Buchstabenring" verwenden, bei dem nacheinander die Namen/Botschaften buchstabiert werden (z.B. aufleuchten), aber das ist aufwendig zu implementieren und nicht besonders nutzerfreundlich.
Alternativ könnten auch (vor allem zum Hinzufügen und Finden neuer Freunde) eine Art Lochkarten verwendet werden: Auf Folie gedruckte oder mit dem Lasercutter geschnittene Visitenkarten, die individuell verziert werden können und an einem Rand eine Lochreihe (also unbedruckte abwechselnd mit bedruckten Stellen) haben, die vom Locator beim Einschieben in eine entsprechende Öffnung mit einer Lichtschranke als Barcode ausgelesen werden, und so einen Freund zu internen Liste hinzufügen, bzw. dessen Position im eingesteckten Zustand anzeigen.
In diesem Fall gibt es gleich zwei Sammeloptionen: Zum einen kann das Armband entsprechend der Veranstaltung (wenn verliehen) oder des Besitzers designt werden, zum anderen können aber auch die Einsteckkarten als Sammelobjekte gestaltet werden.
Für die Botschaften müsste man sich dann auf einen bestimmten Standardsatz an Botschaften einigen, hier kann man sich beispielsweise an den beliebtesten SMS-Nachrichten orientieren. Für individuellere und längere Botschaften würde dann doch besser das Handy dienen und auch besser geeignet sein. Wir müssen uns also später noch überlegen, inwieweit die Nachrichten überhaupt einfach zu implementieren und zu bedienen sind, also ob dies überhaupt ein sinnvolles Zusatzfeature ist.

Hier folgt ein erster Entwurf des Steampunk-Armbandes:

Technikgedanken

Hier jetzt etwas konkretere Überlegungen zu Positionsbestimmung:
Kostengünstiger als ein XBee-Modul sind ganz geöhnliche Funktransceiver und -Receiver (9 € zusammen). Diese haben jedoch den Nachteil, da immer nur ein Tranceiver senden darf, was sich für geringe Personenmengen über ein Protokoll regeln liesse (Vor dem Senden wird zuerst nachgeschaut, ob bereits jemand sendet). Für grosse Personenmengen, was ja das Ziel ist, dürfte dies jedoch angesichts der relativ geringen Datenraten keine gute Lösung darstellen, zum Testen der eigentlichen Positionsbestimmung sind diese jedoch aufgrund des geringeren Preises und der Trennung zwischen Sendeeinheit (Kugelstrahler) und Empfangseinheit (Gerichteter Empfänger) besser geeignet.
Möglichkeiten, um die Antenne zu einer gerichteten Antenne umzubauen sind:
- Metallröhrchen um Antennendraht herum (wie bei den berühmten Pringles-WLan-Richtfunkstrecken), was jedoch aufwendig und damit eigentlich auch teuer ist. Allerdings könnte man versuchen, eine Koaxialleitung dafür zu missbrauchen. Der Platzbedarf ist damit aber trotzdem zu groß
- Parabolspiegel (erst recht unbezahlbar und zu groß)
- Panelantenne, welche durch Interferenz verschiedener Einzelantennen in einer Ebene eine Richtcharakteristik entwickeln. Hier ist zwar der Platzbedarf gering (gefräste Platine), aber der Entwicklungs- und Beschaltungsaufwand viel zu hoch.
- Patchantenne: Ein Kupferrechteck der Länge Lambda/2 dient als Antenne, die dahinterliegende Metallschicht als Reflektorfläche (was dann auch die Einzelelemente einer Panelantenne sind). Gegenüber der Panelantenne ist die Richtcharakteristik zwar geringer, dafür aber der Herstellungsaufwand bedeutend einfacher. Dies wäre damit das für unsere Zwecke naheliegenste Design.
Als Empfangsantenne dient somit eine Platine, auf der in verschiedene Richtungen eine Lambdqa/2 lange Antenne mit dahinter liegender Abschirmung freigeäzt/gefräst ist.

Da bereits der einfache Hertz'sche Dipol eine gewisse Richtcharakteristik hat, ist es allerdings sinnvoll, zunächst einmal das Sende- und Empfangsverhalten der "normalen" Antenne zu untersuchen, bevor wir uns weiter mit den komplexeren Antennen auseinandersetzen.

Grundüberlegungen für den FriendLocator - Teil 1

Für den FriendLocator brauchen wir im Wesentlichen zunächst ein Anzeigeelement und irgendetwas, womit wir die Position bestimmen können.

Ein einfaches und kostengünstiges Anzeigelement ist eine LED-Matrix, die sich auch sehr gut über einen Arduino ansteuern lässt. Hier müssen wir im Grunde nur bestimmen, aus wievielen Punkten die Anzeigefläche bestehen soll, und ob sie annähernd kreis - also achteckförmig sein soll, oder aber eher länglich. Während ersteres der Form eines Radars eher entspricht, kann mit letzterem Text besser dargestellt werden. Verschiedene Beispiele sind im Folgenden aufgeführt

Text kann dabei vor allem als Laufschrift dargestellt werden, so das man auch mit einer kleinen Anzeigefläche auskommt. In den vier rechten Displays sind dabei unten rechts der Beginn einer TEST-Botschaft angezeigt. Links daneben ist ein Radarsignal zu sehen, also Richtungsangaben, wobei durch die Länge der Striche (hier ein oder zwei Punkte) die Entfernung angedeutet werden kann. Rechts oben ist dann eine Anzeige, in welcher Richtung ein WC zu finden ist, und daneben eine Analoguhr zu sehen. Eine weitere Alternative zur Anzeige von Text als Lauflicht sind natürlich Animationen durch abwechselnd eingeblendete Bilder.

Zur Lokalisierung kann im einfachsten Fall (vom Arbeitsaufwand her) ein GPS-Empfänger verwendet werden, was jedoch verhältnismäßig teuer ist.

Ideal wäre es, ihn durch eine Lokalisierung über das Funkmodul zu ersetzen. Dabei könnte die Entfernung möglicherweise über die Signalstärke bestimmt werden. Zur Richtungsbestimmung müsste dann eine Art Richtfunk verwendet werden, wozu mehrere Antennen, welche eine Richtcharakteristik haben, über einen Multiplexer abwechselnd an das Funkmodul angeschlossen werden. Das wird eine der ersten Techniken sein, die wir testen müssen.

Auch die Möglichkeit, während einer Veranstaltung neue Freunde hinzuzufügen, sollte über das Armband einfach möglich sein (was dann ausserdem auch leicht vom Veranstalter genutzt werden kann, um Informationen einzuspeisen (WC-Standorte :-)).

Somit könnte man natürlich auch sein Zelt, Fahrrad, Auto, usw. mit einem Locator ausstatten und diesen damit gleichzeitig als Lokalisator für wichtige Dinge nutzen, falls man sie verliert, oder nicht mehr weiss, wo sie sind (Mein Freund, das Zelt, mein Freund, das Bier :-) ).

Falls ein GPS-Sensor verwendet werden wird, könnte man auch Positionen einspeichern, was im Gegensatz zu den zusätzlichen Locatoren keine Zusatzkosten verursachen würde und in gewissen Fällen (Zelt auf dem Festivalgelände) dennoch ausreichen würde.

Zur Verwaltung seiner Freundelisten soll später eine eigene Website bzw. ein Java-Applet dienen. Weiterhin sollte entweder - falls es preiswert genug wird - das Gehäuse entsprechend der Veranstaltung designed werden, oder aber zumindest entsprechende aufsteckbare Hüllen genutzt werden.

Eine erste Überlegung zum Interface des FriendLocators:

Ein Display (wie oben beschrieben), zwei Buttons (jeweils links/rechts oder oben/unten vom Display) zum durchscrollen der verschiedenen möglichen Ziele.

Auf dem Display wird ein Pfeil angezeigt, der zum aktuellen Ziel zeigt. Wenn ein Richtungsbutton gedrückt wird, erscheint zuerst der Name des Ziels, dessen Position bisher angezeigt wurde. Wird während der Namensanzeige ein weiteres mal ein Richtungsbutton gedrückt, wechselt das Gerät zum nächsten Ziel. Wird dann für x Sekunden kein Button mehr gedrückt, wechselt die Anzeige wieder auf den Pfeilmodus. Optimal wäre es, wenn auch während der Namensanzeige immer noch ein Punkt am Rand bliebe, der anzeigt, wo sich das aktuell ausgewählte Ziel gerade befindet. So könnte man sich auch schnell einen Überblick verschaffen.

Eine Alternative wäre es, den Pfeil ganz weg zu lassen und nur den Punkt zu nutzen. Damit könnte man auch den sonst nötigen Timeout vermeiden, der Nutzer verwirren könnte. Navigation durch eine Menschenmenge kann schon so verwirrend genug sein, da sollte das Interface nicht auch noch zur Verwirrung beitragen.

Eine zusätzliche Überlegung wäre das Versenden von kurzen, vordefinierten Nachrichten ("Bring Bier mit" ;) ), die über ein Menü ausgewählt werden könnten. Einige Botschaften könnten direkt auf dem Gerät vorprogrammiert sein, andere könnte man über das bereits angesprochene Applet selbst definieren. Wie genau dieses Feature angewählt und verwendet werden soll, muss noch geklärt werden.

Willkommen zum FriendLocator-Blog

Auf diesem Blog werden wir in den nächsten Wochen die Ideen und Fortschritte zu dem Abschlussprojekt unseres Softwarepraktikums bei der Media Computing Group dokumentieren.
Die Aufgabenstellung war, ein auf eine Anwendung reduziertes, mobiles Gerät zu entwickeln. Unsere Idee war nun, ein Gerät zu entwickeln, mit dem man auf öffentlichen Großveranstaltungen seine Freunde aufspüren kann.
Wer schon einmal auf einem Festival oder einem größeren Public Viewing war, wird wissen, wie schwer es sein kann, trotz zuvor festgelegter Treffpunkte seine Freunde zu finden. Natürlich ließe sich dies auch mit einem Smartphone machen ("There's an app for that!"®), aber wer möchte schon in größeren Menschenmengen mit seinem Smartphone in der Hand durch die Gegend laufen? Zu groß ist die Gefahr, angerempelt zu werden und damit in sekundenschnelle etwa 500€ in Elektroschrott umzuwandeln.
Der Gedanke war nun, mehrere kleine Geräte zu entwickeln, die sich bequem per Armband am Handgelenk tragen lassen und miteinander kommunizieren können. Kommt der Träger eines solchen Gerätes nun in die Nähe eines seiner Freunde, der ebenfalls ein solches Gerät trägt, weißt das Gerät die Träger darauf hin, das sich ein Freund in der Nähe befindet und weist die Richtung zu ihm. In welchem Umkreis dies funktioniert, muss noch getestet werden, sobald wir uns für eine Technologie entschieden haben. Aktuell ist der Plan, zur Kommunikation XBee-Module zu verwenden. Verschiedene Quellen sprachen von bis zu mehreren Kilometern Reichweite. Selbst, wenn man eine weniger optimistische Schätzung annimmt, sollte man zumindest auf einem größeren Platz noch in der Lage sein, sich zu finden. Das werden wir aber noch zu einem späteren Zeitpunkt ausgiebig testen.
Dieses Konzept könnte (so es sich denn preiswert genug umsetzen lässt) auch für die Organisatoren von Großveranstaltungen interessant sein. So könnte man diese Geräte auch gegen einen Pfand ausgeben und wichtige Orte auf dem Veranstaltungsgelände direkt mit einprogrammieren - Damit könnte das Gerät auch genutzt werden um anstatt des Weges zum nächsten Freund den Weg zum nächsten Bierstand oder WC zu weisen.
Wohin der Benutzer gerade geführt wird, kann er über ein sehr einfach gehaltenes Display einstellen. Offensichtlich sollte es das Ziel sein, das hierzu benötigte Interface möglichst einfach zu halten.