von: Sebastian Holtermann [mail] und Carl Johann Treudler [mail]

Vorwort zur Web Version.
Diese Version der Dokumentation ist inoffiziel, d.h. sie ist rein informativ und nicht für die Jury oder andere Jugend Forscht Teilnehmer gedacht, da sie möglicherweise nicht aktuell ist oder Fehler enthält. Desweiteren gilt auch für diese Seite, wie auch für den Rest des Internets, "Under Construktion" .

Wie werden aller Voraussicht nach am Jugendforscht Landeswettbewerb in Bremen im Jahr 2001 teilnehmen.

Einleitung

Am Computer zu Arbeiten bedeutet für die meisten wohl vor einem flachen Bildschirm zu sitzen und auf der zweidimensionalen Oberfläche des Desktop Texte oder Grafiken zu erstellen, indem man den Mauszeiger verschiebt, hier und dahin klickt und die Tastatur malträtiert.

Der Desktop spiegelt jedoch im Grunde nur die Flache Platte unseres Schreibtisches wieder, auf dem wir ja ebenfalls schreiben und zeichnen können. All diese Tätigkeiten, die wir dort machen, lassen sich leicht auf den Computerdesktop übertragen und dort weiterführen, aber was ist, wenn wir vom Schreibtisch aufblicken?

Läßt sich der Stoffpinguin oder die Kaffeetasse, die ich in der Hand halte und rundherum anschaue auch in den Computer übertragen?

Wundervolle dreidimensional animierte Tiere und Dinosaurier in Kino und Fernsehen sagen uns, kein Problem! Inzwischen kann man sich derartige 3D Objekten und Welten auch an den Heim-PC holen, wenn man allerdings nicht mehr bloß zuschaut sondern beginnt mit solchen virtuellen Objekten und Räumen zu arbeiten und zu interagieren, steht man bald vor einem Problem. Wie soll man mit einem plastischen Objekt vernünftig arbeiten, wenn man mit der Maus immer nur flache Ausschnitte davon händeln kann?

2.1 Die Arbeitsumgebung

Ein virtueller Raum hat genau wie ein realer Raum eine Höhe, eine Breite und eine Tiefe. Im Computer werden diese drei Rauminformationen gängiger weise in einem dreidimensionalen Koordinatensystem beschrieben, wobei jeweils eine Achse für eine Rauminformation steht.

Im Vergleich zum herkömmlichen Bildschirmarbeitsplatz, der nur Höhe und Breite besitzt fällt die dritte Dimension, die Tiefe, auf. Diese ermöglicht eine andere Form sowohl der Navigation als auch der Interaktion mit der Arbeitsfläche. Objekte lassen sich nicht mehr nur von einer Seite betrachten, wie auf einem Desktop, sondern von verschiedenen, ebenso läßt sich ihr Zustand nicht mehr nur in zwei Dimensionen verändern, sonder in drei.

2.2 Das Problem

Mit dem üblichsten Eingabemedium, der Maus, ergeben sich hier die ersten Probleme, denn man kann ein Objekt z.B. nicht in die Tiefe hinein verschieben. Aus diesem Grund stelle heutige Modellierungsprogramme meist verschiedenen Ansichten parat, in denen man Objekte zwar insgesamt im ganzen Raum manipulieren kann, jedoch zur Zeit immer nur in einer Ebene.

für die Interaktion mit einem zweidimensionalen Desktop optimiert, für eine optimale Interaktion mit einem dreidimensionalen Raum fehlt ihr jedoch eine dritte Achse für die Tiefe.

2.3 Das Ziel

Ziel dieser Arbeit ist es ein Eingabegerät zu entwickeln, das es ermöglicht Objekte im Raum auf allen drei Raumachsen gleichzeitig zu manipulieren und möglichst mit einer Hand ähnlich einer Computermaus zu bedienen ist.

3. Methoden und Vorgehensweise

3.1 Die Entwicklungsgeschichte

Die Idee zu einem 3d-Eingabegerät kam eigentlich während der Konstruktion einer Ein-Hand-Tastatur. Da beide Projekte ein Interface zum PC benötigen ist, und sich die Entwicklungen teils überdecken, haben wir diese der Vollständigkeit halber hinzugefügt.

Des weiteren ist jeder Zyklus in drei parallele Entwicklung-verläufe aufgeteilt um die unterschiedlichen Entwicklungen in den Bereichen der reinen Elektronik des Interfaces, der eigentlichen Hardware (der Teil den man am Ende in der Hand hält) und der Software für den PC.

3.2 Unsere Entwicklungsmethode

Nach dem unser Ziel nun in etwa bekannt war ging es an die Entwicklung unseres Projektes. Die Methode, die wird dabei anwendeten, läßt sich am ehesten als ein Zyklus beschreiben mit dem man sich schrittweise immer näher an sein Ziel kommt. Ein Zyklus läßt sich am besten in vier Phasen aufteilen: Zuerst eine Recherche Phase in der nach schon bekannten Problemlösungen, möglichen Verbesserungen für das Bestehende oder Anregungen gesucht wird. Danach folgt eine Phase der Evaluation des Gefundenen, gefolgt von der Implementation. Ist die Implementation abgeschlossen muß das Ergebnis wieder bewertet werden um sicher zustellen das der nächste Schritt nicht in die falsche Richtung geht. Mit jedem Zyklus sollte man sich seinem Ziel ein bißchen genähert haben, hoffentlich.
In der Praxis lassen sich diese einzelnen Phasen nicht so genau unterteilen und teils ist es notwendig während der Evaluation, einen gesamten untergeordneten Entwicklungszyklus zu durchlaufen um größere Probleme in der späteren Implementation zu vermeiden. Dies war zum Beispiel der Fall als eine alternative Entwicklungsumgebung für den Atmel µC (Mikrocontroller) notwendig wurde da niemand Interesse hatte den Mikrocontroller in Assembler zu programmieren.

3.2.1 Die Entwicklungszyklen

1. Zyklus

Nach reichlicher Recherche zum Thema „Ein-Hand-Tastatur“, war der Zeitpunkt gekommen einen ersten Prototypen zu konstruieren. Interface Das Interface war zu diesem Zeitpunkt relativ einfach aufgebaut und war auch lediglich in der Lage den Zustand von 8 Taster an den PC zu übermitteln. Die Wahl der Schnittstelle auf der PC-Seite fiel auf die parallele Druckerschnittstelle, da es mit ein bißchen trickreicher Verschaltung von ein paar Dioden und Wiederständen möglich ist 8 Taster auszulesen. Für diese Anwendung reichte dieses Interface vollkommen aus.

Hardware
Die ersten Probeformen bestanden lediglich aus einem Klumpen Knetgummi indem die Taster steckten. Dies war zwar primitiv aber es ermöglichte eine schnelle und unkomplizierte Anpassung der Position der Taster sowie der gesamten Geometrie des Gerätes.

Software
Die Software lief unter Linux und bestand zu diesem Zeitpunkt aus einem Treiber für das Interface und einem Decodierer der die Tastenkombinationen in Buchstaben und Zahlen umsetzte und ausgab. Der Treiber des Interfaces war in C geschrieben und wurde als Python-modul in den Decodierer geladen. Die Ausgabe der Zeichen erfolgte über eine Schnittstelle zum X11 Windowing-System, so das es möglich war alle gewöhnlichen Anwendung über die Tastatur zu bedienen.

2. Zyklus

Hardware
Bau eines einfachen Models aus Fischertechnik zum Testen des Interfaces und zur Überprüfung der Eingabe-geometrie.
Bei der Konstruktion eines ersten Prototypen mußten wir uns für die Sensoren mit denen wir die Position des Armes bestimmen wollten entscheiden. Die Wahl aus einer großen Anzahl an Möglichkeiten fiel zuerst auf die Messung mit mehreren Potentiometern, da dies schnell zu realisieren und kostengünstig war. Neben den Potentiometer haben wir auch noch zwei andere Verfahren zur Winkelmessung erprobt, aber nicht eingesetzt. Die Potentiometer reichten für die Testzwecke aus. Alternativ haben wird die Messungen mittels eines Reflexsensors und einem Optischen Biegesensor getestet.

Reflex Koppler
Ein Reflex-Koppler ist ein IC (= Integrierter Schaltkreis) das mittels einer Lichtquelle und einem Fotoempfänger die reflektierte Lichtmenge mist. Ursprünglich waren diese Baugruppen dafür gedacht einfache schwarz-weiß Markierungen zu erkennen, allerdings lassen sie sich aufgrund ihrer analogen Natur auch dazu verwenden die relative Entfernung zu einem Reflektor zu messen oder die Position über einem Graustufenverlauf zu ermitteln. Einzig störend ist die Tatsache das Fremdlicht die Messung stark verfälscht und somit eine umfassende Abschirmung notwendig wird.

optische Biege-Sensoren
Ein optischer Biege-Sensor funktioniert ähnlich wie der Reflexkoppler mittels Messung einer reflektierten Lichtmenge. Der Unterschied zum Reflexkoppler liegt darin das Emitter und Detektor nicht nebeneinander positioniert sind sondern jeweils an einem Ende eines flexiblen Schlauches oder Lichtleiters. Wird die Verbindung gebogen änder sich die Reflektionseigenschaften und am anderen Ende kommt effektiv weniger Licht an. Dieser Abfall kann nun gemessen werden und in etwa einem Biegungswinkel zugeordnet werden. Der Nachteil dieser Sensor-Anordnung ist das diese Sensoren relativ aufwendig kalibriert werden müssen und auch relativ störanfällig gegen über Quetschungen des Schlauches oder variierenden Biege-Radien sind. Letztendlich eignet sich dieser Sensor am ehesten zum „abschätzen“ von Winkeln.

Diese beiden Verfahren haben beide das Potential länger zu halten als es ein Potentiometer je kann, da sie optisch arbeiten und somit der Alterung und dem Abrieb der Schleifkontakte nicht unterliegen

Interface
Der Bau eines Interfaces mit Mikrocontroller, 12-Bit A/D-Wandler und RS-232 Schnittstelle zum PC brachte Probleme. Der externe A/D-Wandler erwies sich als elektrisch defekt und führte zu keinem Erfolg. Zur Programmierung des Mikrocontrollers kam der GCC C-Compiler zum Einsatz, da dieser den verwendeten Atmel AVR Mikrocontroller direkt unterstützt und unter der GNU-Lizenz steht und damit kostenlos ist. Die Entwicklung der Firmware für das Interface stellte sich als ein relativ komplexes Problem dar, aufgrund der Tatsache das uns keinen Echtzeit-Debugger zur Verfügung stand und das Interface damit wortwörtlich zur "Blackbox" wurde.

Software
Aufgrund des defekten A/D Wandlers konnte auf der PC-Seite leider nichts gemacht werden.

3. Zyklus

Hardware
Das vorher in Fischertechnik-Bausteinen aufgebaute 3-Achsen-Model wurde nach und nach in Leichtmetall-Profilen nachgebaut um die Belastung für Nutzer und Material zu verringern sowie die mechanische Stabilität zu verbessern.

Da sich die Potentiometer als zuverlässige und praktikable Lösung erwiesen hatten behielten wir sie bei. Es bleibt allerdings abzuwarten wie sich die Potis im Langzeitgebrauch bewähren.

Interface
Mit der Erscheinen eines neuen Kataloges unseres Lieblings Elektronikversandes (Reichelt) wurde plötzlich ein neuer Mikrocontroller aus der AVR Serie verfügbar. Dieser besagte Chip war für uns quasi ideal. Der AT90s2333 bot ausreichend I/O Pins und brachte einen 10-bit A/D-Wandler gleich mit. Somit bauten wir das Interface um diesen Chip herum neu auf und sparten einen IC und erhebliche Kosten.

Software
Zu allererst mußte ein Treiber entwickelt werden, der die Daten vom Interface empfängt und aufbereitet. Darauf aufbauend folgte ein geometrische Interpretation des Eingabegerätes um die Meßwerte der Potentiometer in X-, Y- und Z-Koordinaten umzurechnen. Mittels einer Anbindung an X11 (ein Fenstersystem unter UNIX, ähnlich Windows) ist es nun möglich beliebige Anwendungen zu steuern.

4. Ergebnisse

4.1 Welche Veränderungen an einem Objekt nimmt man am häufigsten vor?

Aus Erfahrung im eigenen Leben, als auch mit diversen Programmen zur Modellierung und Erstellung von dreidimensionalen Objekten, hat sich herausgestellt, daß zwei Arten der Veränderung an Objekten bzw. der eigenen Position im Raum am häufigsten vorkommen, die Translation und die Rotation.

4.1.1 Die Verschiebung (Translation)

Unter Translation versteht man allgemein die Verschiebung im Raum, dabei wird ein Objekt von einer Position zu einer anderen bewegt.

4.1.2 Die Drehung (Rotation)

Unter Rotation versteht man allgemein die Drehung um eine bestimmte Achse, der Einfachheit halber meist um eine der drei Raumachsen. Ein Objekt wird dabei um einen bestimmten Winkel rotiert und erhält dadurch eine neue Orientierung.

4.2 Das Eingabegerät

4.2.1 Der Aufbau

Das Eingabegerät läßt sich grob in zwei Teile unterteilen, den Griff und den Arm. Der Griff ist am Ende des Armes befestigt, und läßt sich frei im Raum bewegen.

4.2.1.1 Der Griff

Der Griff ist das Element, das der Benutzer in die Hand nimmt und auf das er Kraft ausübt.

Dabei umfaßt er mit einer Hand das rot markierten Element, mit drei Achsen drehbar aufgehangen ist, deren Rotationswinkel mit Hilfe von Potentiometern gemessen werden kann. Dadurch ergeben sich drei Eingabeachsen, die sich für den Erstbenutzer auch gedanklich leicht in in eine Rotationsachse im virtuellen Raum umsetzen lassen.

Der Griff dient also folglich hauptsächlich zur Eingabe von Rotationsdaten.

4.2.1.2 Der Arm

Der Arm ist das Element, das mit einer festen Unterlage verbunden ist und zur Aufnahme von Translations bzw. Positionsdaten dient. Er ähnelt der Aufhängung einer gewöhnlichen Schreibtischlampe und besitzt drei Achsen, deren Rotationsgrad ebenfalls durch Potentiometer gemessen wird. Aus diesen Rotationsdaten läßt sich die Position des Kopfes, errechnen, bzw. einer Verschiebung von diesem.

Der Griff ist am Kopf befestigt, so daß Arm und Griff eine Einheit bilden.

4.3 Die Materialien

Der Arm und der Griff sind zum größten Teil aus Aluminiumprofilen aus dem Baumarkt gefertigt, die mit diversen Werkzeugen in Heimarbeit bearbeitet wurden.

Aluminium eignet sich für diese Zwecke gut, da es sehr leicht ist, so daß das Eingabegerät nicht zu schwer in der Hand liegt, und es sich trotzdem bei den ausprobierten Kraftverhältnissen kaum verformt.

Achsen wurden größtenteils aus Messingrohr gefertigt, weniger aus besonderen Materialeignung als viel mehr aus Verfügbarkeitsgründen, da Messingprofile ebenfalls in vielen Formen im Baumarkt erhältlich sind. Für die Messung mit Potentiometer wurde in das Messingrohr ein Splint eingebracht, auf den die Potentiometerachse, die vorher mit der Säge in der Mitte aufgetrennt wurde, geschoben wurde, so daß diese fest mit der Achse verbunden sind.

Der Griff zum Anfassen ist aus Holz, da sich dieses mit „Hausmitteln“ am besten in die gewünschte Form bringen ließ.

4.4 Das Interface

Das Interface besitzt zur Zeit sechs analoge Eingänge und sendet deren Daten auf Anfrage als Digitalwerte an die RS-232 Schnittstelle.

4.5 Schaubild des Ablaufes von der Eingabe bis zur Anwendung

5. Diskussion:

5.1 Erfahrungen während der Projektarbeit

Bei der Arbeit an dem Eingabegerät ergab sich recht schnell die Erkenntnis, das nicht nur die Konstruktion der reinen Hardware wichtig ist, sondern mindestens ebenso das Interface zum Computer und die Software, die die Daten empfängt und verarbeitet.
Daher wurde der Umfang dieser Arbeit anfangs auch unterschätzt und wäre ohne Vorwissen über Schnittstellen, Elektrotechnik und Materialbearbeitung wahrscheinlich im gegebenen Zeitrahmen nicht möglich gewesen.

Als besonderes Problem hat sich die Schnittstelle zu bestehenden Anwendungen dargestellt. Als Probeanwendung benutzten wir “Descent III“, eine Flugsimulation, die dem Spieler alle sechs Freiheitsgrade zur Verfügung stellt um seinen Gleiter durch ein unterirdisches Labyrinth zu fliegen. Beim Testen ergab sich das Problem daß über die Emulation einfacher Tastendrücke nur eine sehr ungenaue und ruckartige Steuerung möglich war. Um dieses Problem zu beseitigen wäre es notwendig einen proportionalen Wert an die Anwendung zu übergeben und nicht nur ein einfaches Ja/Nein-Signal. Die hierzu notwendigen Schnittstellen der Anwendung zur Hardware sind aber weder standardisiert noch verbreitet. Die Entwicklung in diese Richtung dürfte noch etwas Zeit in Anspruch nehmen, bei der Einführung der Maus hat es mehrere Jahre gebraucht, bis die Software die Möglichkeiten als quasi analoge Eingabe überhaupt ausnutzte. Es bleibt abzuwarten, was die Zukunft an entsprechenden Schnittstellen zur Software (API) bringen wird. Für uns ist es ganz offensichtlich nicht möglich eine derartige API zu entwickeln und zu verbreiten.

Zur Konstruktion des Interfaces ist anzumerken das es zwar zur Genüge analoge Interfaces für den PC gibt, allerdings sind diese nicht nur inflexibel und teuer, sondern hätten uns genau wie bei unserem Selbstbau vor das Problem gestellt Treiber für Linux entwerfen, entwickeln und testen zu müssen.

Die Mechanischen Komponenten bedürfen ebenfalls weiterer Optimierung, was allerdings nicht nur eine Frage der Material- und Werkzeugausstattung ist, sondern ein Problem der endlichen Zeit. Insbesondere hinsichtlich Ergonomie und Nutzbarkeit sind noch umfangreiche Studien nötig um das Design weiter an den Menschen anzupassen. Die aktuelle Version stellt in dieser Hinsicht nur ein Konzeptmodell dar.

6. Literaturverzeichnis:

Quellen:

„The Linux Serial Programming HOWTO“ (Peter H. Baumann, Peter.Baumann@dlr.de )

http://www.linuxdoc.org/HOWTO/Serial-Programming-HOWTO.html

„Atmel for Dummies“ (Volker Oth, VolkerOth@gmx.de )

http://people.freenet.de/0xfade0ff/index.htm

Datenblätter zum Atmel AVR AT90s2333 (Mikro controller)

http://www.atmel.com/atmel/products/prod200.htm