Projekt
Zur Titelseite:
|
Die Idee zu dieser Jugend-forscht-Arbeit resultiert aus meinem Wunsch, ein preiswertes und trotzdem leistungsfähiges Beschleunigungsmessgerät für den Physikunterricht zu bauen. Das Herzstück dieses Gerätes ist der neuartige Sensor ADXL202.
Abb. 1.1: Der ADXL202 auf seiner Adapterplatine
Mein Messgerät sollte den folgenden Anforderungen gerecht werden:
Da ich mich hobbymäßig mit Elektronik und Programmieren beschäftige (Delphi, Pic-Assembler, CAD-Programme) war ich zuversichtlich, ein Gerät entwickeln und bauen zu können, das die o. g. Vorzüge in sich vereint.
Durch meine bei Entwicklung und Bau dieses Gerätes gewonnenen Kenntnisse kam mir die Idee, ein System zu entwickeln, das Raumlagen anhand der Erdbeschleunigung errechnen kann. Ich nannte es GBS, was für "Gravity-Balance-System" steht. Es beruht auf der Tatsache, dass der a-Sensor, je nachdem in welchem Winkel er zur Erde steht, eine mehr oder weniger große Erdbeschleunigung misst. Aus diesem Wert kann man den Winkel, in dem das System zur Erde steht, zurückrechnen, da g stets konstant und bekannt ist. Eine praktische Anwendungsmöglichkeit für GBS ist das "Intelligend-Failsafe-System" (IFS), ein Sicherheitssystem für Flugmodelle, das bei Abriss der Funkverbindung einsetzt.
Auf das "Gravity-Balance-System" habe ich ein Patent angemeldet.
Abb. 2.1.1: Die Schematik des Beschleunigungsmessers
Zum besseren Verständnis der folgenden Ausführungen erläutere ich in diesem Kapitel anhand der Schemata von Abb. 2.1 den Aufbau meines Messgerätes.
Das Herzstück der Schaltung bildet der ADXL202, dessen Daten von einem Mikrocontroller vom Typ Pic16F84 ausgewertet werden. Bis auf den Sensor, dessen zeitliche Intervalllängen gemessen werden müssen, wird das gesamte System über einen I²C-Bus kontrolliert. Dieses System hat auf der einen Seite den Vorteil, dass bis zu 127 Komponenten mit nur zwei Leiterbahnen angesteuert und abgefragt werden können, zum anderen, dass der Speicher fast beliebig ausbaubar ist. Leider verfügt der Pic standardmäig nicht über das I²C-Protokoll. So musste ich - angefangen bei der Startbedingung über Adress- und Datenübertragung bis zum Stopsignal - alles in Maschinensprache für den Pic programmieren.
Neben einer 8-Tastentastatur und einem 32 Kbyte Speicher besitzt mein Gerät ein großflächiges Display, um die Bedienungsfreundlichkeit zu erhöhen.
Um die aufgezeichneten Daten weiter verarbeiten zu können, machte ich mir Gedanken darüber, wie man sie in einen PC überspielen könnte.
Der Druckerport scheidet aus, weil man an ihn laut Hersteller nur bei ausgeschaltetem Computer Geräte anschließen darf. Hinzukommt, dass diese Schnittstelle oft belegt ist und es sie (nach Aussagen einiger namhafter Computerzeitschriften) an zukünftigen PCs nicht mehr geben soll. Die serielle Schnittstelle ist schon besser, da an sie auch bei eingeschaltetem PC etwas angeschlossen werden darf und sie auch mechanisch erheblich kleiner ist. Doch ist diese serielle Übertragung oft auch nicht verfügbar, weil z. B. ein Modem daran angeschlossen ist.
Sie ist zwar mechanisch recht klein im Vergleich zum Druckerport, aber es geht noch kleiner! So gibt es nur noch eine Lösung, und die ist auch die beste: den Universal-Serial-Bus, kurz USB!
Er ist der mechanisch kleinste von allen Schnittstellen, besitzt eine mehr als ausreichende Übertragungsgeschwindigkeit und durch den SIE (Serial-Interface-Engine) eine Fehlerkorrektur, um die sich der Anwender nicht kümmern muss.
Außerdem ist es sehr unwahrscheinlich, dass bei 127 möglichen Geräten nicht mindestens ein Port frei wäre. Jedoch kann bzw. will der Anwender nicht immer einen Laptop mit sich herumtragen, und zwar aus gutem Grund: Erstens ist so ein Gerät teuer und hinderlich bei Messungen, und zweitens ist er für Fallversuche auch nicht geeignet. Das Gerät muss also selbst in der Lage sein, Messreihen einzuspeichern. Dabei muss der Datenerhalt nach dem Ausschalten aber garantiert sein, um diese nachher in den PC zu übertragen.
Wie könnte nun aber ein solches Gerät aussehen? Am besten wäre ein Gerät, das aus einzelnen Modulen besteht, die man je nach Bedarf zusammenstecken kann.
Man benötigt eine Hauptplatine, die in der Lage ist, alle anderen Teile anzusprechen, also als Master fungiert.
Dazu verwendete ich insgesamt 4 Portexpander vom Typ PCF8574P. Dabei soll auch eine stabilisierte Spannung zur Verfügung gestellt werden. Die Anzeige kann mit auf die Hauptplatine, da man sie in jedem Fall brauchen wird.
Abb. 2.2.1: Die Hauptplatine mit Display
Als nächstes muss ein Anschluss zum Sensor geschaffen werden, weil sich dieser in meinem Fall auf einer Extra-Platine befindet, die ihn gegen Überspannung durch statische Elektrizität, Verpolung, zu hohe Belastung der Ausgänge usw. schützt. Diese Platine kann allerdings nicht an den I²C-Bus angeschlossen werden. Der Grund ist, dass die zeitliche Länge des digitalen Ausgangssignals des ADXL202 gemessen werden muss, da man hierüber die aktuelle Beschleunigung erfährt. Auf der Sensorplatine befindet sich auch noch ein I²C-EEPROM, welches zum Abspeichern von Kalibrationswerten genutzt werden kann. Außerdem enthält es das TOC (Table of Contents) für den Hauptspeicher.
Abb. 2.2.2: Das Herzstück: Die Schutzschaltung mit eingesetztem Sensor und Sockel für EEPROM
Beim Interface kommt die Stromversorgung vom USB selbst, lediglich die Massen müssen miteinander verbunden werden.
Da ich mit meinem Programmiergerät nicht die Pics der neuesten Generation (die mit USB-Anschluss) programmieren kann, musste ich auf einen fertig programmierten Cypress-Controller vom Typ CY7C63001A zurückgreifen, den die Firma Modul-Bus anbietet, dem auch direkt ein geeigneter Treiber beiliegt.
Abb. 2.2.3: Das USB-Interface mit dem Cypress-Controller und den Portexpandern
Für die Speicher-Einheit nahm ich 4 EEPRoms vom Typ 24C64, die zusammen 32 Kbyte aufnehmen können. Da sie ohne weitere Beschaltung I²C-tauglich sind, hatte ich auf der Platine noch Platz frei, wo ich einen weiteren Portexpander anbrachte, um 8 Tasten anschließen zu können. Speicher und Tastatur bilden ein Modul.
Abb. 2.2.4: Die Speicherplatine mit den vier Speicherbausteinen, dem Portexpander und den Tasten
Die Schaltung mit ihren Modulen wird von dem o. g. Mikrocontroller vom Typ Pic16F84 gesteuert. Dieser Controller ist nahezu wie geschaffen für solch einen Anwendungsfall, da er über 13 bidirektionale Pins verfügt, von denen ich 12 nutzte. Das eingebaute RTCC-Register (ein Register zur Zeitmessung) war für mich besonders praktisch, weil es automatisch hochgezählt wird und das eigentliche Programm ungestört parallel laufen kann.
Ebenfalls nutzte ich die vielseitigen Interruptmöglichkeiten für die Messung der Signallänge.
Der (Flash-Rom-)Programmspeicher mit 1024*14 Bit ist für meinen Zweck auch mehr als groß genug, außerdem lässt er sich in Sekunden im Programmiergerät wieder löschen, was bei vielen größeren und kleineren Brüdern des Pic16F84 leider nicht der Fall ist.
Im übrigen ist dies ein preiswerter Controller.
Der ADXL202 besteht aus zwei auf dem Chip integrierten Kondensatoren (einer für die x- und einer für die y-Achse), an deren Platten eine Schwungmasse angebracht ist, die den Plattenabstand bei Beschleunigung verändert und sie somit messbar macht. Durch Beschleunigungen, wie beispielsweise die Erdanziehungskraft, werden diese Platten nun verschoben, wodurch sich die Kapazität des Kondensators ändert. Eine integrierte Elektronik formt daraus (entsprechend der äußeren Beschaltung) ein pulsweitenmoduliertes Signal. Findet keine Beschleunigung statt, so hat dieses Signal genau 50 % der mit R1 (ein externer Widerstand) eingestellten zeitlichen Länge. Pro "g" wird dieses Signal um 12,5 % länger oder kürzer, entsprechend der Beschleunigung in positive oder negative Richtung. Für jede der beiden Achsen wird ein eigenes, vom anderen unabhängiges Signal ausgegeben. Diese Signale "starten" fast gleichzeitig.
Der erste Teil der Schaltung, den ich fertigte, war eine Adapterplatine für den Sensor, da ich ihn nicht direkt in die Schaltung einlöten wollte. Die nach unten gerichteten Stiftleisten lassen sich in jeden DIL-Sockel hineinstecken (=>"Abb. 1.1: Der ADXL202 auf seiner Adapterplatine").
Als nächstes wurde die Platine der Schutzschaltung entworfen, belichtet, entwickelt, geätzt, gebohrt, bestückt und auf Funktion geprüft. Alle Schaltungen und Platinen sind übrigens mit dem Platinenprogramm "Eagle" entworfen und berechnet. Um die Platinen zu optimieren, d. h. um möglichst viele der notwendigen Verbindungen auf einer Seite zu schaffen, musste ich "Eagle" die Platine mit verschiedenen Einstellungen ständig neu berechnen lassen, um auch die optimale Position der Bauteile zu ermitteln.
Danach wurden die Layouts auf Transparentfolie ausgedruckt und in einem fotochemischen Prozess auf das Basismaterial übertragen. Es folgte eine Kontrolle, ob nicht irgendwo eine Leiterbahn "verlaufen" war und daher nicht erwünschten Kontakt mit einer anderen hatte. Ebenfalls konnte es vorkommen, dass beim Belichten ein Fehler aufgetreten war, den man nach dem Entwickeln nicht gesehen hat und so eine Trennung vorlag, die nicht sein darf. Haarrisse zählen ebenfalls hierzu, sie sind aber nur durch Nachmessen mit dem Durchgangsprüfer zu entdecken. Weil nicht alle im Schaltplan vorgesehenen Verbindungen möglich waren und sich das Erstellen einer doppelseitigbeschichteten Leiterplatte nicht lohnte, mussten die nicht vorhandenen Verbindungen mit kleinen Kabeln auf der Lötseite von Hand nachgezogen werden. Anschließend wurde die Leiterplatte gebohrt, bestückt, gelötet und mit Schutzlack überzogen, um eine Oxidation des Kupfers zu verhindern.
Da das System hauptsächlich über den I²C-Bus kontrolliert wird, musste ich nicht sparsam mit den Leitungen zur Ansteuerung der nicht I²C-fähigen Komponenten (Sensorplatine mit ADXL202) umgehen, trotzdem beschränkte ich die Schaltung auf ein Minimum an Bauteilen und Leitungen, um sie klein und preiswert zu halten, schränkte sie aber nicht in ihrer Leistungsfähigkeit ein.
Für den ADXL202 brauchte ich zwei Leitungen, für den Messeingang einen und den zweiten, um den Kanal auszuwählen, der auf den Messeingang geschaltet werden soll, was ich mit einem einfachen elektronischen Umschalter realisierte, der aus 4 NAND-Gattern besteht.
Des weiteren gibt es noch einen Write-Protection-Pin für den Kalibrationsspeicher, er wird aber nicht benutzt.
Das I2C- Protokoll musste ich selbst programmieren, da der Pic nicht standardmäßig darüber verfügt (es gibt einige Controller, bei denen dies bereits in der Hardware implementiert ist). Hierbei gab es die Schwierigkeit, dass ich schlecht kontrollieren konnte, was der Controller gerade tut. So konnte ich nur ein Oszilloskop zu Hilfe nehmen und ungefähr ablesen, was sich auf dem Bus abspielte; das musste ich von der Startbedingung über das Lesen und das Schreiben auf den Bus bis zur Stopbedingung tun. Da ein falsch angesprochenes Bauteil nicht antwortet, hatte ich sonst keine Möglichkeit zu überprüfen, wo sich ein Fehler eingeschlichen hatte. Auch das Zusammenspiel dieser Befehle musste geprüft werden. Dies nahm sehr viel Zeit und Geduld in Anspruch. Aber auf diesem Protokoll baute ich dann das gesamte System auf. Vom Interface über die Steuerleitungen des Displays sowie der Tastatur und der frei programmierbaren Ein- und Ausgänge bis hin zum batteriegeschützten Speichersystem beruht alles auf zwei einfachen Signalleitungen, die eine maximale Übertragungsgeschwindigkeit von fast 8 KB (Kilobyte) pro Sekunde ermöglichen. Hierfür musste ich sogar noch Warteschleifen programmieren, da der Pic mit seinen 20 MHz (Befehlsausführungsfrequenz: 5MHz => 1 Zyklus = 200nsec => 5.000.000 Befehle pro Sekunde) den Bus sonst übertaktet hätte, denn I²C-Bausteine vertragen maximal 100 KHz Taktfrequenz.
Der Bus arbeitet nun mit ca. 90 KHz, so dass eine lückenlose Datenübertragung als gesichert angesehen werden kann.
Hierbei gab es ein weiteres Problem: Der Sensor reagiert empfindlich auf elektromagnetische Wellen, was zu einem nicht zu ignorierenden Rauschen führt. Weil das I²C-EEPROM mit dem TOC direkt unter dem Sensor lag, legte ich den Bus im Controllerprogramm für die Zeit, in der gemessen wird, still. Jedoch reichte das allein nicht aus; eine extra Abschirmung war notwendig, da ebenfalls der Monitor meines PCs störte. Das USB-Interface selbst ist ein weiterer großer Störfaktor, auch wenn es sich nur um ein Low-Speed-Gerät handelt, welches Daten mit bis zu max. 1,5 Mbit überträgt. Nun musste ich die Programme entwickeln, die die einzelnen Module verwalten.
Zuerst implementierte ich das Interface, denn ich weiß aus Erfahrung, dass es immer gut ist, wenn ein Mikrocontroller direkt mit dem PC verbunden ist. Das hat folgenden Grund: Man kann ihm die Anweisung geben, eine Funktion mit einem (ebenfalls über das Interface gesendeten) Wert zu bearbeiten; das Ergebnis sendet er zurück (oder zeigt es irgendwie sonst an) so dass man sehen kann, ob die Funktion richtig arbeitet oder nicht.
Hierzu ein Beispiel: Ich wollte testen, was das Display bei bestimmten Befehlen macht. Also schrieb ich ein (Mikrocontroller-)Programm, das die Befehle des PCs an das Display weiterleitet. Das Programm baute ich dann aus, und später sendete ich direkt Tastaturwerte (von der PC-Tastatur) über das USB-Interface an den Pic, der daraufhin auf das Display schrieb, was ich auf meiner Computertastatur eingab.
Dies war eine praktische Sache, denn nun konnte ich die verschiedenen Algorithmen, die ebenfalls im Controller programmiert sind, prüfen. Dazu sendete ich dem Pic Werte, ließ ihn den Algorithmus damit durchrechnen und das Ergebnis anzeigen. So testete ich u. a. eine Funktion, die Hexadezimalwerte in ASCII-Zeichen umwandelt, denn kein Mensch ist in der Lage, vierstellige Hex-Zahlen im Kopf in Dezimalzahlen umzuwandeln (oder wüssten Sie, dass C5D3 = 50643 ist?). Wir denken nun einmal dezimal, und die Elektronik hat sich dem anzupassen.
Aber das war nicht die einzige Funktion, die auf diese Art und Weise unter die Lupe genommen wurde. Auch die Funktionen, die sich um das sachgemäße Beschreiben des Displays kümmern, wurden so entwickelt und getestet. Sicher ist es möglich, Programme bereits in der Entwicklungsumgebung (MPLAB von Microchip) im PC zu simulieren, doch das Zusammenspiel mit der äußeren Hardware kann man hierbei leider nicht berücksichtigen, daher muss es praktisch erprobt werden.
Dies sind nur wenige Beispiele für die Funktionen, die alle im Assembler-Quellcode des Pic enthalten sind.
Insgesamt ist das Erstellen von Assembler-Code für Mikros eine zeitaufwendige Sache, hat aber im Vergleich zu der Programmierung in C den Vorteil, dass ein Assembler-Programm teils erheblich schneller läuft, da ein menschlicher Programmierer genau weiß, was er braucht und was er weglassen kann. Jedoch braucht man für diese Art der Programmentwicklung auch sehr viel länger als in einer Hochsprache.
Es gibt insgesamt "nur" 33 verschiedene Befehle für den 16F84, doch ist selbst ein Vertippen gefährlich, da sich viele Befehle nicht sonderlich voneinander unterscheiden.
Dazu muss man sich auch die Reihenfolge der Befehle gut überlegen, weil eine solche Kleinigkeit schon eine stundenlange Fehlersuche nach sich ziehen kann.
Oft besteht auch ein kleiner logischer Fehler in der Idee (diese Art Fehler sind besonders schwer aufzuspüren, sind aber mit am häufigsten). Die Logik hingegen nimmt schnell Dimensionen an, die ein intensives Nachdenken erfordern.
Für Mathematik z. B. hat man nur Additions-, Subtraktions- und Schiebebefehle zur Verfügung, und weil 8-Bit-Register keine Zahlen von größer als 255 aufnehmen können, muss man immer wieder prüfen, ob ein Register nicht "übergelaufen" ist.
Ein simples Beispiel für die Logik im Pic: Ich habe ein Register, in dem ich den Zustand des 3. Bits umkehren muss. Ich könnte hierzu jetzt folgendes tun:
| btfss | Register, 3 | Ist das 3. Bit =1 ? |
| goto | $+3 | nein: Überspringe die nächsten beiden Befehle |
| bcf | Register, 3 | ja: Bit löschen |
| goto | ende | zum Ende springen |
| bsf | Register, 3 | Setze das Bit in dem Register |
| goto | ende | |
| ende | return | Ende der Funktion, Rücksprung |
Dies wäre eine Möglichkeit, das Problem zu lösen; aber wenn man auf diese Weise programmiert, sind auch die 1024 Speicherstellen für Befehle bei einer Aufgabe wie dieser schnell verbraucht. Da es keinen Invertierungsbefehl gibt, sollte man das so machen:
| Movlw | b'00001000' | Laden des Hauptregisters "w" mit diesem Bitmuster, wo das 3. Bit auf 1 liegt (von rechts nach links zählend, mit dem 0. Bit beginnend) |
| xorwf | Register, f | Exclusive-Or-Verknüpfung mit Ergebnis in "Register" |
| ende | return | Rücksprung |
Der Inhalt von "Register" hat sich nicht verändert bis auf das 3. Bit, das nun invertiert ist.
Sie können dies auf jedem technisch-wissenschaftlichen Taschenrechner nachprüfen.
Schalten Sie ihn hierzu in den binären Modus, geben Sie irgendeine Folge von Einsen und Nullen ein (mindestens 4-stellig), wählen sie "EXOR" oder "XOR", geben sie "1000" ein und drücken Sie "=". Es wird sich an der ursprünglichen Kette von Einsen und Nullen nichts verändert haben bis auf das 3. Bit, welches jetzt den gegenteiligen Zustand hat.
Wenn Sie statt "1000" nur Einsen eingeben, werden alle Stellen invertiert sein.
Auf diese Art kann man sehr viel Quellcode und somit Programmspeicher sparen. Würde man die Funktion, welche die hexadezimalen Zahlen in dezimale umwandelt, so programmieren, bräuchte man fast 96 (!) mal soviel Programmspeicher! (Damit hätte man fast die Hälfte des gesamt verfügbaren Speichers verschwendet!) Allerdings arbeitet man dort auch mit indirekter Adressierung, deren Erklärung hier den Rahmen sprengen würde.
Fakt ist:
Der Code muss also gut durchdacht sein, schon allein aus Geschwindigkeitsgründen.
Die Kommunikation zwischen dem Pic und dem PC erfolgt über den "USB-Port"-Controller der Firma Modulbus. Um ihn ansprechen zu können, muss ich unter Delphi auf den entsprechenden Treiber zugreifen. Dies geschieht so:
function USB_IO : integer;
begin
FileName := '//./CompuLABusb_0';
Hand:= CreateFile(PChar(FileName), GENERIC_WRITE Or GENERIC_READ,
FILE_SHARE_WRITE Or FILE_SHARE_READ, nil, OPEN_EXISTING, 0, 0);
Temp:=DeviceIoControl(Hand, $04, @iIn, InSize, @iOut, OutSize,Size,nil);
closehandle(Hand);
end;
Hand ist ein Handle (ein Steuerelement), das über "CreateFile" erzeugt/angefordert wird.
Geräte werden unter Windows 98 wie Dateien gehandhabt, allerdings über einen Treiber, weil unter Win 98 kein Programm direkt auf die Hardware zugreifen darf (da Programme mit anderen "Rechten" arbeiten als Treiber; Treiber haben höhere "Rechte").
Zuerst muss der Name des Gerätes angegeben werden. Wenn es angeschlossen ist, findet Windows den entsprechenden Treiber und öffnet ihn. Die folgenden 3 Parameter beschreiben Zugriffsart und Sicherheitsattribute (hier: "nil" = nicht existent), der Rest sind Einstellungen, die nur für Windows von Interesse sind.
Mit DeviceIOControl wird schließlich ein Befehl/Parameter an den Treiber gesendet, der die in "iIn" abgelegten Daten an den USB-Controller weiterleitet und Daten vom Controller anfordert, welche er in "iOut" ablegt (dazu werden aber nicht die "Buffer" direkt übergeben, sondern nur die Speicherstellen angegeben, wo sich die "Buffer" befinden, deshalb das "@").
Dazu muss noch angegeben werden, wie groß diese "Buffer" sind, das geschieht mit "iInsize" sowie "iOutsize". Der Wert "$04" ist für den (Cypress-)Controller der Befehl, Daten an seine Ports zu schreiben oder die anliegenden zu senden, je nachdem was in "iIn" steht. Es gibt noch weitere Befehle, die z. B. den Sink-Strom der Ausgänge einstellen; sie sind für die Kommunikation aber nicht von Bedeutung.
Die Daten für das bzw. vom Messgerät werden von 2 Portexpandern in den (Pic-)Controller übertragen bzw. von ihm in sie geschrieben. Es handelt sich hierbei um einen Datenbus mit quasi-bidirektionaler Struktur. Quasi-bidirektional deshalb, weil die Ausgänge (sowohl die vom Controller als auch die der Portexpander) nicht auf High-Z* umschalten können. Der "1"-Zustand wird durch integrierte Pull-up-Widerstände erreicht, die problemlos auf "Low" gezogen werden können. Dies vereinfacht die Realisierung der Übertragung erheblich, da bei quasi-bidirektionalen Bussystemen keine Tristate-Register verwaltet werden müssen, wie das beispielsweise beim Pic der Fall ist. Buskonflikte sind hierdurch nicht möglich.
Die Daten werden über ein von mir entworfenes Protokoll zwischen Messgerät und PC übertragen. Ich möchte es hier aber nicht weiter erläutern, weil ich es bis zur Präsentation noch weiter entwickeln werde, um die Übertragung schneller zu machen.
Im PC werden die Daten zunächst in einem Array abgelegt und in die für Excel verständlichen Zahlen umgerechnet (jeder gemessene Wert besteht aus 2 Byte, daraus formt mein Programm eine Integerzahl). Dann wird Excel automatisch über OLE gestartet und mit den geladenen, umgeformten Werten "gefüttert".
*hochohmiger Zustand, der bei bidirektionalen Bussystemen zum Ignorieren des Ausgangs führt; versuchen nämlich zwei parallel geschaltete Systeme gleichzeitig, ein verschiedenes Datenmuster auf den Datenbus zu geben, so kommt es zu einem "Buskonflikt"; geht einer von ihnen auf High-Z, kann der andere seine Daten problemlos auf den Bus schreiben.
Nachdem die Kommunikation funktionierte, konnte ich erste Testmessungen durchführen und den Verlauf der Beschleunigung in einem Diagramm betrachten. In meinem Fall richtete ich die x-Achse des Sensors direkt auf den Boden und fing an, ihn zu drehen, so dass nach einiger Zeit die andere Seite der x-Achse auf den Boden zeigte (jede Achse hat ja einen positiven und einen negativen Bereich, deshalb geht die Kurve auch ins Negative). Man sieht der Messung (Abb. 3.1) an, dass das Gerät noch nicht hundertprozentig eingestellt war, der Offset musste noch korrigiert werden, die Amplitude stimmt noch nicht ganz, und eine bessere Abschirmung war auch noch nötig. Das Zittern rührt von meiner Hand her, da der Sensor nirgendwo befestigt war. Aus demselben Grund ist auch die Wellenlänge etwas unregelmäßig. Der große Zacken bei der ca. 130. Messung ist auch kein Fehler, sondern ein Missgeschick meinerseits!
Abb. 3.1: Die erste Messung, das Gerät ist nur sehr grob kalibriert, der Offset noch nicht korrigiert
Der nächste Schritt war das Messen mit zwei Sensoren gleichzeitig (Abb. 3.2). Das Ergebnis sieht man in dem Diagramm unter diesem Text. Auch bei dieser Messung musste ich den Sensor von Hand bewegen, wobei mich dauernd das Kabel vom Sensor zur Hauptplatine störte, deshalb das Gezitter. Ich startete die Messung, als sich die x-Achse (blau) parallel (soweit ich das von Hand hinbekam) zum Erdboden befand und die y-Achse genau auf ihn gerichtet war. Nun begann ich, den Sensor zu drehen. Ich erwartete, dass die beiden Sinuskurven um 90° phasenverschoben waren, und genau das trat ein!
Bei meinen Messungen gewann ich folgende wichtige Erkenntnis:
Mein Arbeitstisch war nicht gerade! So banal sich das auch anhören mag, es ist von größter Wichtigkeit, weil bereits ein Winkel von nicht einmal 0,6° zum Erdboden den Sensor eine Beschleunigung von 10 mg messen lässt. Deshalb stimmte wahrscheinlich auch der Offset nicht, und so hielt ich den Sensor bei den hier aufgeführten Messungen von Hand in der Luft.
Abb. 3.2: Dual-Messung
Nachdem das Messgerät soweit entwickelt war, dass es fehlerfrei messen, speichern und übertragen konnte, sollte es seinen ersten Praxistest bestehen.
Zusammen mit meinem Mitschüler Eric Plum machte ich mich an die Entwicklung eines Microsoft-Excel-Makros. Unser Makro erlaubt es, aus den aufgezeichneten a-Werten Energie, Geschwindigkeit, Strecke, Kraft und Impuls für die Bewegung zu berechnen (Abb. 4.1) und grafisch darzustellen. Lediglich die Masse muss für einige Werte von Hand eingegeben werden.
Abb. 4.1: Bildschirmeinfang: Mauswahlmenü des Makros
Warum aber gerade in Excel? Nun, Excel ist ein sehr weit verbreitetes Programm, mit dem viele Leute arbeiten bzw. arbeiten können; noch dazu ist es zu vielen anderen Office-Programmen, wie z. B. Word oder Access kompatibel, so dass Messungen vielfältig verwaltet und bearbeitet werden können. Ferner kann jeder, der ein Standard-Office-Paket besitzt, diese Dateien öffnen.
Um die Zuverlässigkeit meines Messgerätes und des Programms zu überprüfen, bauten wir eine Teststrecke aus einer Lego-Bahn und befestigten das Messgerät auf einem Anhänger.
Dann wurde eine Aufzeichnung gestartet; die Bahn beschleunigte auf einer kurzen Strecke und fuhr dann in einer Endlosschleife ihre Runden.
Abb. 4.1: Das Messgerät auf der Teststrecke in der Endlosschleife
Die Aufzeichnung wurde anschließend in den PC übertragen, und mit dem Makro ausgewertet. Das Ziel dieser Auswertung war es, die Form und Abmessungen der Strecke alleine aus den a-Werten zu rekonstruieren, denn so konnten wir die Funktion und das Zusammenspiel von Messgerät und Programm am besten kontrollieren. Das Ergebnis zeigt Abb. 4.2 .
Abb. 4.2: Die vom Makro errechnete Strecke
Dazu mussten aber erst einmal die Fehler, die durch die Erdbeschleunigung auftraten, beseitigt werden; schließlich bekommt man es in der Praxis nie so ganz hin, dass der Sensor absolut parallel zur Erde liegt. Dazu wurde eine Kalibrierfunktion erstellt, der wir angaben, dass der Sensor in den ersten 4 sec der Messung stand, die gemessene Beschleunigung also nur von der Erde stammen konnte. Diese Funktion errechnete Faktoren, die die übrigen Werte so korrigierten, als hätte der Sensor wirklich parallel zur Erde gelegen. Der zweite Korrekturalgorithmus benötigt Zeitangaben, wann das Gerät auf einer Geraden beschleunigt wurde; schließlich werden die Messwerte von ihm so korrigiert, als hätte das Gerät mit einer Achse genau in Fahrtrichtung und mit der anderen genau seitlich gezeigt. Auch die Geschwindigkeit, mit der der Zug in die Schleife hineinfährt, wird durch ihn ermittelt. Der dritte Algorithmus berechnet anhand der gemessenen Radialbeschleunigung die Krümmung der Kurve in der Endlosschleife, und rekonstruiert daraus Form und Abmessungen der gefahrenen Strecke.
Wie man sieht, stimmen Foto und Rekonstruktion sehr genau überein; der Praxistest kann somit als bestanden angesehen werden. Nur zwei Dinge sind wirklich wichtig, damit die Rekonstruktion funktioniert: Der Zug muss sich mit konstanter Geschwindigkeit in die Schleife hineinbewegen und auch in ihr fahren sowie der Zeitpunkt, wann er zum ersten mal hineinfährt, muss bekannt sein, denn dieser ist aus einem über die ganze Messung laufenden a-t-Diagramm nur sehr schwer abzulesen. Diesem Ableseproblem kann ich aber möglicherweise durch ein kleines Zusatzmodul, das ich bis zur Präsentation fertig haben will, beikommen. Es handelt sich hierbei um ein Modul, das Markierungen an der Strecke erkennt und im Speicher den Zeitpunkt des Passierens vermerkt.
Wie in Kapitel 1 erwähnt, besitze ich auf GBS ein Patent.
Was ist das Gravity-Balance-System und wozu dient es?
Diese Frage möchte ich anhand eines Beispiels an Flugmodellen erklären:
Wie der Name schon sagt, handelt es sich um ein System, das ein Flugmodell oder ein anderes Gerät in Balance hält. Ähnlich einem Piezo-Kreisel. Leider haben diese Kreisel aber den Nachteil, dass sie nur Änderungen der Raumlage eines Flugmodells bemerken. Sie erkennen nicht, ob die von ihnen gegebenen Ruderbefehle wirklich ausgereicht haben, um das Modell wieder in seine vorherige Lage zurück zu bringen. Das rührt daher, dass nur Druck- oder Zugänderungen am Piezo-Kristall eine Reaktion hervorrufen.
Diesem Mangel komme ich mit dem von mir entwickelten System bei!
Das GBS kann nicht nur Änderungen der Raumlage feststellen, es kann sogar die Lage zum Erdboden selbst jederzeit, in jeder nur denkbaren Fluglage, bestimmen. Dadurch ist ein Vorher-Nachher-Vergleich möglich; die Steuerbefehle werden so lange beibehalten, bis die Nulllage (wie immer die auch aussehen mag) wieder erreicht ist.
In der einfachen Ausführung besteht GBS aus zwei Beschleunigungssensoren, die in einem 90° Winkel zueinander angeordnet sind und im Normalfall parallel zum (Erd-)Boden liegen.
Je nach Raumlage sind sie mehr oder weniger geneigt und messen entsprechend ihrer Neigung einen unterschiedlich großen Teil der Erdbeschleunigung. Da "g" bekannt und auch überall konstant ist, kann man die Neigung aus den Messwerten zurück berechnen, entsprechend der Formel Winkel = 1/sin( Messwert/ g).
Selbstverständlich funktioniert das nicht nur bei Flugmodellen, sondern bei allen Objekten, die in Balance gehalten werden müssen und gesteuert werden können.
Auf diese Entwicklung ließ ich mir vom Patentamt in München einen Schutz erteilen; eine Kopie der Urkunde befindet sich als Anhang an dieser Arbeit.
Für Flugmodelle speziell entwickelte ich auf Basis von GBS das "Intelligent-Failsafe-System" (IFS); es stellt sozusagen eine praktische Anwendung für GBS dar.
Bei gewöhnlichen "Failsafe"-Systemen programmiert man in den (PCM-)Empfänger im (Flug-)Modell die Positionen, die die Ruder des Modells einnehmen sollen, falls Störungen in der Funkübertragung auftreten. Dies soll das Modell bei Abriss des Kontaktes zwischen Sender und Empfänger stabilisieren. Leider funktioniert es aber meistens nicht so, wie es gedacht ist. Hierzu ein Beispiel aus der Praxis:
Vor einiger Zeit schlug in meinem Verein eine ca. 3.000,-- € teure "Pits", ein Kunstflug-Doppeldecker, fast senkrecht in ein Feld ein. Die Ursache war, dass ein weiterer Sender, der die gleiche Frequenz hatte, während des Fluges der "Pits" eingeschaltet wurde. Der PCM-Empfänger der "Pits" aktivierte daraufhin "Failsafe". Leider befand sich das Modell zu dieser Zeit in einer vertikalen Fluglage, und es erfolgte der Einschlag.
Das "Versagen" des "Failsafe"-Systems ist in seiner Konstruktion begründet, denn durch das bloße Anstellen der Ruder kann man nicht die Lage eines Flugmodells bestimmen; diese Kommandos müssen der momentanen Lage angepasst sein.
Beim IFS hingegen wird nicht die Ruderposition, sondern die Lage des Modells im Raum programmiert. Ist das System aktiviert, steuert es das Modell in die vorher einprogrammierte Lage. Sollte diese z. B. durch eine Windböe verlassen werden, wird automatisch gegengesteuert, bis sie wieder erreicht ist. Jede beliebige Lage ist programmierbar, z. B. leichter Sinkflug mit leichter Schräglage nach links, um das Modell Kurven drehen zu lassen. Mit solch einem System ist die Wahrscheinlichkeit einer Beschädigung des Modells beim Aufsetzen erheblich geringer.
IFS würde sich bereits beim ersten "Problemflug" rentieren.
Des weiteren ist IFS in geringfügiger Abwandlung als Landehilfe bei Modellen und bemannten Flugzeugen einsetzbar, da es schneller als der Pilot auf Luftströmungen reagieren kann.
Darüber hinaus ist der Einbau denkbar unkompliziert: Das IFS wird einfach zwischen den Empfänger und die Servos geschaltet und dient gleichzeitig als Signalverstärker. Das Anbringen von externen Sensoren ist nicht erforderlich.