e.on zero – Klapp! Die Zweite!*

 

 

*Die Zweite? Zur ersten geht’s hier!

 

Neues Schuljahr, alte Elektronik-AG. Fast die gleiche Besetzung. Und die Frage:

 

Where do we go next?

 

Aber diese Frage beantwortet sich rasch, denn es gibt einen neuen Wettbewerb. e.on-zero: Man baue ein Rennboot mit Wasserstoffantrieb. Können wir das?

 

25.10.2010

 

Mal gucken. Wir nehmen einen Motor und eine Schiffsschraube. Wir schnitzen ein Boot aus Styropor. Wir verbinden das Ganze mittels eines TRIX-Baukastens. Wir lassen es zu Wasser. Es kippt um. Wir befestigen Gegengewichte. Es fährt. Schön. Ein Boot bauen können wir also. Was hat das eigentlich mit Elektronik zu tun?

 

 

 

Vorschlag: Boot bauen kann jeder. Da es vermutlich nicht 10 Meter freiwillig geradeaus fährt, muss man es steuern. Funkfernsteuerung? Nö! Machen wir doch mal was ganz Außergewöhnliches: Steuern wir das Boot mit einem Laser-Leitstrahl. Die Idee: Fotosensoren kontrollieren, ob sich das Boot auf Kurs (auf dem Leitstrahl) befindet und geben – per Mikrocontroller (Juhu, das können wir!) – dann Signale an das Ruder.

 

1.11.2010

 

Wir kompaktifieren (oder so ähnlich) den Antrieb. Das Ganze soll immerhin ein Rennboot werden und kein Ponton mit Antrieb.

 

 

In der Ausschreibung heißt es, das Ganze soll mit einer einzigen Brennstoffzelle laufen. Das ist eine echte Herausforderung. Die macht maximal 1 Volt Spannung. Wir brauchen einen Motor, der mit 1 Volt (oder besser weniger) läuft. Die Stromstärke ist weniger das Problem, da ist so eine Brennstoffzelle recht großzügig.

 

Nun gibt es zwar Sparmotoren, die man an Solarzellen anschließen kann, und die daher mit 0,5 Volt auskommen, aber die sind auch sehr stromsparend. Und hier die entscheidende Formel:

 

Leistung = Spannung mal Strom

 

Was sagt uns das? Dass wir mit einem Stromsparmotor die Leistung, die die Brennstoffzelle liefern könnte, gar nicht ausnutzen würden. In Zahlen:

 

Kennlinie der Brennstoffzelle (gemäß Anleitungsbuch):

 

Lastwiderstand

0,1 Ohm

0,33 Ohm

1 Ohm

3,3 Ohm

10 Ohm

33 Ohm

Strom

1,43 Ampere

1,05 Ampere

0,56 Ampere

0,22 Ampere

0,08 Ampere

0,03 Ampere

Spannung

0,32 Volt

0,47 Volt

0,62 Volt

0,76 Volt

0,84 Volt

0,9 Volt

Leistung

0,458 Watt

0,494 Watt

0,347 Watt

0,167 Watt

0,067 Watt

0,027 Watt

 

Wir müssten die Brennstoffzelle demnach mit etwa 0,3 Ohm belasten, damit sie maximale Leistung abgibt. Mögliche Motoren sind:

 

Motor

Spannung (minimal)

Strom (Leerlauf)

Leistung

Widerstand

Igarishi 2025-22

1,5 Volt

0,2 Ampere

0,3 Watt

7,5 Ohm

Mabuchi RE 280

1,5 Volt

0,25 Ampere

0,375 Watt

6 Ohm

Conrad 198080

0,3 Volt

0,027 Ampere

0,0081 Watt

11,1 Ohm

Conrad 198358

0,4 Volt

0,11 Ampere

0,044 Watt

3,6 Ohm

2 mal 198358 parallel

0,4 Volt

0,22 Ampere

0,088 Watt

1,8 Ohm

 

Keiner der Motoren kommt an diesen Optimalwert von 0,3 Ohm heran, aber 2 mal Conrad 198358 parallel (=1,8 Ohm) käme zumindest von allen am besten in die Nähe.

 

 

Bei dieser Last würde die Spannung der Brennstoffzelle noch etwa 0,7 Volt betragen. Dann fließen durch 1,8 Ohm (nach Ohm: I=U/R) etwa 0,4 Ampere. Dies ist auch die Stromstärke, die die Brennstoffzelle bei der Last liefern kann. Die Leistung wäre dann (P=U*I) gleich 0,28 Watt. Das ist immerhin mehr als die Hälfte der Leistung, die die Brennstoffzelle im Idealfall liefern könnte. Wobei die Motoren dann mit 0,4 Ampere laufen müssten, d.h. jeder mit 0,2 Ampere. Das wird knapp.

 

Vorschläge für Alternativen?

 

Daniel: „Wie viel Prozent des Bootes müssen am Ziel ankommen?“

 

Niklas: „Hä?“

 

Daniel: „Wir sprengen mit dem Wasserstoff die Brennstoffzelle. Irgend ein Trümmerteil des Bootes kommt bestimmt ins Ziel.“

 

Jäkel: „Kein Kommentar.“

 

Somit beschließen wir, einen Katamaran zu bauen. Der kann mit zwei parallel geschalteten Motoren fahren, mit denen wir die Leistung der Brennstoffzelle den Umständen entsprechend bestmöglich nutzen können. Außerdem lässt sich ein Katamaran leicht mittels der Drehzahl der Motoren steuern.

 

8.11.2010

 

Wir haben die Motoren bestellt, die laut obiger Überlegung in Frage kommen könnten. Da sie noch nicht da sind, überlegen wir uns inzwischen eine Idee, die Spannung der einen und einzigen Brennstoffzelle hoch zu transformieren. Es gibt Spannungsvervielfacher-Schaltungen. Eines wissen wir jedenfalls schon aus dem letzten Wettbewerb: Auf dem Spannungslevel kriegen wir keine Elektronik zum Laufen. Die einzige Chance sind Relais. Das müsste etwa so gehen (und geht mit der Elektronik-Workbench auch so):

 

 

Ein Kondensator wird parallel zur 1V-Quelle aufgeladen, dann wird durch zwei Umschalter der Kondensator mit der Quelle in Reihe geschaltet und an den Verbraucher (Motor) gelegt. Zugleich wird ein zweiter Kondensator aufgeladen. Danach schaltet man wieder zurück. Und so weiter. Am Motor sollten dann 2 Volt liegen (Quelle plus geladener Kondensator), jedenfalls Beginn jedes Zyklus, da sich die Kondensatoren jeweils wieder entladen. Wenn man nun den Umschalt-Takt schnell genug macht, müssten am Motor praktisch ständig 2 Volt liegen. In der Simulation klappt das, wie man sieht.

 

Allerdings braucht man sehr große Kondensatoren. Wir probieren es mit 4700µF-Elkos aus, und gewinnen den Eindruck, dass es tatsächlich funktioniert. Aus 0,8 Volt werden 1,1 Volt. Noch nicht der Durchbruch. Aber es gibt da diese „Gold-Cap“-Kondensatoren mit irre großen Kapazitätswerten. Besorgen wir also ein paar davon.

 

15.11.2010

 

Gelegentlich sollten wir unser Projekt zum Wettbewerb anmelden. Leider waren die Gold-Caps, um es kurz zu sagen, der absolute Flop. Wie auch immer die funktionieren mögen, Kondensatoren sind es jedenfalls nicht. Zumindest benehmen sie sich nicht so. Man kann sie nicht laden und man kann sie nicht entladen. Oder man kann sie zwar laden, aber danach haben sie keine Ladung. Oder wie auch immer. Sie fliegen in die Restekiste, mag sich mal jemand anders damit herumärgern. Wir kehren zu den 4700µF-Elkos zurück und erhöhen die Taktrate, aber es hilft nichts. Mit Relais kann man die Taktrate nicht beliebig erhöhen, und unsere Motoren haben nur 1,8 Ohm Innenwiderstand. Entladezeit T = RC = 1,8Ohm*0,0047Farad = 0,0086 Sekunden. Das war vertane Zeit.

 

Warnung an alle: Gold-Caps sind Murks!

 

22.11.2010

 

Projektanmeldung gefaxt. Es sollte eine Zeichnung beigefügt werden. Da wir aber noch nicht wirklich wissen, wie unser Boot am Ende aussehen wird, haben wir uns bei der Zeichnung auf eine ziemlich freihändige Freihandskizze beschränkt. Erkennt jemand was?

 

 

Weitere Bauteile bestellt. Als Fotosensoren für den Leitstrahl wollen wir Solarzellen nehmen. Sie sollten recht schmal sein, wegen der Messgenauigkeit bei der Kursabweichung, aber möglichst hoch, da sie auch bei Seegang nicht den Leitstrahl aus den Augen verlieren dürfen. In den einschlägigen Katalogen (ja, Conrad, wer sonst?), gibt es kaum noch Solarzellen zum Basteln, das Zeitalter haben wir verpasst. Der vornehme Bastler kauft jetzt fertige Solarmodule. Modul klingt irre gut und bringt uns nicht die Spur von weiter. So ähnlich wie Portfolio. Man sollte es zum Unwort des Jahres erklären. Letzte Chance: So genannter „Solarzellenbruch“.

 

29.11.2010

 

Solarzellenbruch besteht aus hauchdünnen Siliziumscheiben, die mal Solarzellen werden wollten, den Fertigungsprozess aber nicht überlebt haben. Wir stellen uns vor, dass man die Bruchstücke in die gewünschte Form sägen, feilen, schneiden, beißen oder sonst was kann. Wir haben es probiert (bis auf das Beißen). Es geht nicht. Aus wenigen großen Bruchstücken werden viele kleine Bruchstücke.

 

Aber diesmal: Ha! Es geht doch! Man nehme: Eine Solarzellenscherbe. Man löte vorne (Sonnenseite) das Kabel für Minus an und hinten das für Plus.

 

 

Man nehme ein L-Profil aus Plastik. Man nehme Zweikomponentenkleber. Man klebe das Profil von hinten auf die Solarzellenscherbe. 

 

 

Man lasse den Kleber trocknen. Man nehme eine Zange und beiße mit ihr die überstehenden Reste der Scherbe ab. Man erhält: Einen Solarsensor in den gewünschten Abmessungen. Getestet mit Laserpointer und Voltmeter: Funktioniert!

 

 

6.12.2010

 

Nikolaus. Wir werden uns jetzt nicht darauf einlassen, ein Steuerprogramm in den µC zu brennen und zu sehen, ob es das Boot richtig steuert. Das muss vorher getestet werden, und zwar nicht erst, wenn das Boot fertig ist. Das Programmierteam entwickelt (seit Wochen) einen Simulator. Nein, nicht in Visual Basic. Visual Basic hassen wir immer noch! Wir machen das in JAVA!!!

 

 

Dieses Applet lässt ein Boot über den Bildschirm fahren. Die Antriebskräfte und die Reibung im Wasser werden über eine Physik-Engine nachgebildet. Man kann die Motoren von Hand (mit Mausklick) schalten oder auf Autopilot schalten. Der Autopilot ist eine JAVA-Methode, die testet, welcher (simulierte) Sensor gerade vom (simulierten) Laserstrahl getroffen wird, und die daraufhin die (simulierten) Motoren auf einen für sinnvoll erachteten (simulierten) Schub schaltet. Die eigentliche Leistung besteht darin, den Autopiloten so zu programmieren, dass er auf diese Weise das (simulierte) Boot auf Kurs hält. Ein paar Buttons im Applet dienen extra dazu, das Boot aus dem (simulierten) Kurs zu bringen und zu sehen, was dann passiert.

 

 

Okay, zugegeben, bisher fährt es wilde (simulierte) Schlangenlinien. Aber im Prinzip hält es den Kurs. Wenn die (reale) Rennstrecke breit genug ist, könnte es irgendwann ins (reale) Ziel kommen. Daran muss noch gearbeitet werden. Wie an so vielem anderen auch.

 

13.12.2010

 

Wir haben uns inzwischen entschieden, den Katamaran aus zwei Plastikflaschen zu bauen. In jede kommt eine Antriebseinheit. Auf das Deck kommt der Rest: Sensoren, Brennstoffzelle, Tanks, Elektronik, Batterie für die Elektronik.

 

Mittlerweile haben wir eine reichliche (und insgesamt irgendwie ganz schön teuer gewordene) Auswahl an Motoren, Antriebswellen, Kardangelenken und Schiffsschrauben vorliegen. Unter uns: Die Kardangelenke sind die Pest. Die sollen ja eigentlich die Rotation vom Motor auf die Welle übertragen, aber sie hakeln bei der geringsten Verkantung. Wenn man den Motor aus einem Akku-Powerpack betreibt, stört das vermutlich nicht weiter, aber wenn man mit 0,7 Volt auskommen sollen und der Motor mit knapper Not überhaupt dreht, ist jedes Klemmen eine Katastrophe. Vor allem: Lenz’sche Regel! Je schwerer der Motor dreht, desto mehr Strom zieht er. Ein abgewürgter Motor zieht soviel Strom, dass der andere dann auch noch stehen bleibt.

 

 

 

Da müssen wir uns etwas Anderes einfallen lassen. Ach ja: Was machen wir eigentlich, wenn am Wettkampftag die Sonne scheint? Wenn die Solarzellen Sonnenlicht sehen, erkennen sie vermutlich den Laser-Leitstrahl nicht mehr. Was heißt vermutlich? Bestimmt nicht!

 

Jäkel: „Sonnenlicht macht Gleichstrom. Wenn wir den Laser modulieren, kriegen wir Wechselstrom. Das kann man dann elektronisch mit einem Hochpass unterscheiden.“

 

Johanna: „Was ist ein Hochpass?“

 

Jäkel: „Das stelle ich mir etwa so vor...“

 

 

Alle: „Aha.“

 

Aufgabe (als hätten wir sonst noch keine): Wir brauchen eine Lochscheibe, die vor dem Laser rotiert, um den Lichtstrahl zu zerhacken.

 

20.12.2010

 

Zwei gute Nachrichten: 1. Die Weihnachtsferien stehen bevor. 2. Unser Boot ist zur Teilnahme zugelassen. Eine schlechte: Die heutige Sitzung der AG fällt aus, weil der Betreuer einen Termin in Kiel hat. Dafür werden über die Ferien Probleme gelöst. Klar soweit?

 

10.1.2011

 

Durch Opfern einer Pfandflasche, die längs aufgesägt wurde, konnte eine Antriebseinheit entwickelt werden, die in das Innere passt. Allerdings gelang es nicht, sie wie bei einem Buddelschiff durch den Flaschenhals einer heilen Flasche zu praktizieren. Statt dessen muss die Flasche seitlich, also oben (bezogen auf die Lage im Boot), aufgesägt werden. Unten ginge auch, aber dann läuft Wasser rein. Bei der damit verbundenen Gewaltanwendung ging leider einer der Motoren kaputt.  

 

 

Unbeeindruckt davon beginnen wir mit den Aufbauten des Schiffes. Die Fotosensoren müssen dabei einen langen Hals machen, damit sie über die Brennstoffzelle, die auch noch an Deck stehen muss, hinweg gucken können. Unter Deck können wir sie leider nicht hängen, dann liegt sie bei der Größe schon im Wasser.

 

 

11.1.2011

 

Betreuertreffen in Rendsburg. Freizeitheim der e.on. Der Ort ist vom Vorjahr bekannt. Kaffee, Kuchen, Limo. In einem Brainstorming und mit bunten Klebezetteln an einer Hafttafel erarbeiten die teilnehmenden Lehrkräfte und Schüler unter professioneller pädagogischer Anleitung (IQSH), dass ein Rennboot möglichst wenig Strömungswiderstand und möglichst wenig Gewicht haben sollte. Nebenbei hört man: Mindestens eine andere Gruppe plant auch einen Katamaran, als Wasserstofftank werden Luftballons diskutiert, zur Gewichtsersparnis könnte auf jegliche Steuerung auch ganz verzichtet werden, und die Bestzeit für 10 Meter lag beim letzten Mal bei 24 Sekunden. Ein Projekt, bei dem ein Luftkissenboot gebaut werden soll, wird auf Nachfrage und nach kurzer Diskussion zum Wettbewerb zugelassen, solange das Luftkissen nicht zum Vortrieb beiträgt. Anmerkung des Veranstalters: „Wir gehen davon aus, dass das sowieso nicht funktioniert!“

 

18.1.2011

 

Unser Boot nimmt Form an. Zwei Flaschen beherbergen die Maschinen (das Problem der Kardangelenke ist noch ungelöst), ein (irre dünnes) Alu-Lochblech dient als Deck. Die Sensor-Säulen stehen auch schon. Ja, so ungefähr hatten wir es uns vorgestellt.

 

 

Eingedenk der Impressionen aus Rendsburg (mit bunten Klebezetteln) packen wir das Ding mal auf eine Waage. Es fühlt sich gar nicht so schwer an, aber es wiegt (in diesem Zustand, noch ohne Brennstoffzelle und Elektronik!) satte 500 Gramm. Da es sich bei den Flaschen um 1-Liter-Flaschen handelt, kann man (Schöne Grüße von Herrn Archimedes) ausrechnen, dass sie – voll untergetaucht! – jeweils 1 kg tragen könnten. Macht zusammen 2 Kilogramm. Mit anderen Worten: Sowie unser Boot schwerer als 2 Kilo ist, wird es zum U-Boot. Und auch bei nur einem halben Kilo dürfte es schon im Wasser liegen wie ein nasser Sack. Mist! Das wird kein Rennboot, das wird bestenfalls eine Rennschnecke. Da muss Gewicht weg!  Abspecken nennt man das auch.

 

25.1.2011

 

Ideen zur Gewichtsreduktion: Motorwelle kürzen (eine 4mm-Antriebswelle wiegt 35 Gramm. Wir mussten die leichtere 3mm-Version leider verwerfen, weil wir für die keine gegenläufigen Schiffsschrauben kriegen), Trägerprofile lochen (Rallye-Look), kürzere Schrauben (eine 10 mm lange M3-Schraube wiegt 0,7 Gramm, das hat vor uns bestimmt auch noch keiner gewusst!), Aluminium durch Plastik ersetzen wo es geht. Und vor allem: DIESMAL KEINE UNTERLEGSCHEIBEN! Das heißt im Übrigen: weiteres Material besorgen.

 

Das Abspecken ist übrigens nicht trivial. Kunststoff ist nicht so verwindungssteif wie Aluminium. Bei kürzeren Wellen (die nur zweimal 20 Gramm Gewicht sparen) rückt zugleich der Motor deutlich nach achtern und tiefer. Das obere Ende des Stevenrohrs soll aber nicht unter die Wasserlinie kommen, sonst läuft uns das Boot durch das Stevenrohr voll. Wie also ändert sich die Wasserlinie abhängig vom Gewicht des Bootes?

 

Dazu können wir ja mal ein wenig theoretisieren. Die Flaschen sind in erster Näherung zylinderförmig. Der Querschnitt ist ein Kreis. Das Gesamtvolumen entspricht der Kreisfläche, das Eintauchvolumen entspricht dem Kreisabschnitt. Die Formel für einen Kreisabschnitt sollte in der Formelsammlung stehen... Schundliteratur!!! Sie steht nicht drin!!! Handarbeit ist angesagt. Zum Glück findet Jan-Hendrik eine passende Formel im Mathebuch, die man nur noch ein wenig auf die Physik anpassen muss.

 

 

Die eintauchende Fläche F (Kreisabschnitt) verhält sich zur Gesamtkreisfläche A=pr2 wie die Masse des Bootes (tatsächliche Wasserverdrängung) zur maximalen Masse (Gesamtverdrängung der Flaschen, also 2 Liter Wasser, entsprechend 2kg). Das ergibt: F/A = m/2kg. Bei den verwendeten Flaschen ist übrigens r = 3,9cm. Ergebnis:

 

Masse bei Eintauchtiefe t: m = 2kg*F/A = 2kg * (r2*arccos(1 – t/r) – Wurzel(2rt – t2)*(r – t))/(pi * r2).

 

Der Rest ist einfach: EXCEL-Tabelle anlegen: t von 0 bis 3,9cm; m ausrechnen, grafisch darstellen:

 

 

Wenn das Boot 0,5 kg wiegt, wird es demnach 2,3 cm Tiefgang haben. Was haben wir davon? Wenn wir noch die bunten Zettel vom Rendsburger Brainstorming hätten, könnten wir es jetzt an die Pinnwand heften: Ein leichteres Boot hat weniger Tiefgang. Bitte nicht lachen, der Mensch von IQSH meinte das völlig ernst! Eines steht fest: Das Kürzen der Motorwelle auf die Hälfte bringt das Stevenrohr rund 1,5cm tiefer und 40 Gramm Gewichtsreduktion. 40 Gramm sind in der obigen Grafik ein Teilstrich. Damit kommen wir vielleicht einen Millimeter weiter aus dem Wasser. Fazit: Wir kürzen die Motorwelle also nicht. Die Masse sparen müssen wir woanders. Hausaufgabe: Bohren. Wir machen aus allen Trägern durch Bohrungen einen Schweizer Käse. Schade, dass man das nicht auch mit den Motoren machen kann, die sind das Schwerste an der Konstruktion. Bestenfalls noch getoppt vom Akkupack für die Steuerelektronik. Da nehmen wir wohl besser Knopfzellen.

 

Apropos Steuerelektronik. Mit der sind wir heute schon richtig weit gekommen:

 

 

Wir gehen (worst case) davon aus, dass der Wettbewerb im Saal stattfindet. Dann werden unsere Fotosensoren neben dem Laser-Leitstrahl auch noch die mit 100 Hz flackernden Leuchtstoffröhren sehen. Die Modulation des Leitstrahls muss davon deutlich zu unterscheiden sein, wir haben die besten Ergebnisse bei 800 Hz gefunden. Dann können wir mit einem Hochpass die 100 Hz weitgehend unterdrücken. Das Restsignal wird verstärkt. Dann wird es gleichgerichtet und ein Kondensator damit geladen. Damit kriegen wir ein Ausgangssignal, das einen deutlichen Unterschied zwischen „ich sehe den Leitstrahl“ und „ich sehe den Leitstrahl nicht“ macht, so dass wir dies einem Eingang des Microcontrollers als digitalen Wert zuführen können. Auf dem Simulator sieht das jedenfalls schon sagenhaft gut aus. Wenn wir den Kram nachher löten, dürfen wir nicht so große Lötzinnkleckse machen, das ist alles Gewicht...!

 

9.2.2011

 

Neuer Stundenplan, Treffen jetzt mittwochs. Die Runde war sehr klein: Dr. Jäkel und Jan Hendrik. Trotzdem sehr effektiv. Die Hausaufgabe ist gemacht, die Antriebe sind durchlöchert und wiegen alles in allem gut 50 Gramm weniger. Und vor allem: Wir brauchen diese unseligen und hakeligen Kardangelenke überhaupt nicht! Da muss man erst einmal drauf kommen: Ein Stück Silikonschlauch tut’s auch und kann sich ganz bestimmt nicht verkanten! Einziger Haken: Man braucht trotzdem einen Adapter von 2mm (Motorwelle) auf 4mm (Schlauch und Antriebswelle). Das hat freundlicherweise die Drehbank in Dr. Jäkels Bastelkeller erledigt.

 

 

Weitere heutige Leistung: Die oben noch simulierte Schaltung ist jetzt real existierend aufgebaut. Und wisst ihr was? Sie funktioniert! Bei den Bauteilewerten mussten wir noch ein bisschen variieren, und da wir noch keinen Laserstrahlzerhacker haben, musste ersatzweise eine Leuchtdiode auf die Sensor-Solarzelle flackern (800 Hz aus Generator), aber sonst war es schon wie im wirklichen Leben. Erst einmal haben wir nur das Signal auf den Sensor leuchten lassen:

 

 

Bild oben: Signal am Verstärkerausgang, Bild unten: hinter dem Gleichrichter. Nun kam die Frage nach dem worst case (mit Neonbeleuchtung). Zuerst haben wir nur die Deckenbeleuchtung eingeschaltet. Das sehen wir im nächsten Bild:

 

 

Oben ist wieder der Verstärkerausgang, unten das Signal nach der Gleichrichtung. Damit ist klar, dass unser Hochpass funktioniert: Das 100 Hz-Flackern schlägt praktisch nicht mehr durch. Jetzt haben wir zusätzlich das Signal (Leuchtdiode) eingeschaltet:

 

 

Ergebnis: Ein bisschen Welligkeit des Signals ist noch zu erkennen, aber mit 1,6 Volt nach der Gleichrichtung klar vom Neonlicht (0,4 Volt) zu unterscheiden. Sieht eigentlich fast aus wie in der Workbench-Simulation.

 

Ein immer noch mögliches Schreckensszenario, das nicht vergessen werden darf: Wettbewerb bei herrlichem Wetter im Freien: Die Sonne scheint! Natürlich auch auf die Sensorzelle. Da eine Solarzelle bei auch nur einigermaßen erträglicher Beleuchtung immer 0,5 Volt liefert (das hat mit dem p-n-Übergang zu tun, für Details siehe unseren Beitrag vom Vorjahr!), kann man an der Spannung nicht unterscheiden, ob nur Sonne draufscheint oder der Laser noch zusätzlich. Man könnte auch sagen: Die Sonne blendet unseren Sensor. ABER: Jedes Lichtquant trennt ein Ladungsträgerpaar (Details: siehe oben). Also ist die Stromstärke sehr wohl von der Beleuchtung abhängig und müsste bei zusätzlicher Laserbeleuchtung ansteigen. Der Verstärker verstärkt aber Spannung und nicht Strom. Dafür haben wir (schon oben in der Simulation) die 47 Ohm gleich am Eingang vorgesehen. Wegen U = R * I erzeugt der Strom eine Spannung an dem Widerstand, der zur Stromstärke proportional ist. Damit sollte der Blendungseffekt umgangen werden. Und es scheint zu funktionieren:

 

 

Wir haben dazu die 47 Ohm erst einmal weggelassen. Bild oben: Signal am Eingang vorhanden, aber keine Sonne. Bild Mitte: Zusätzlich scheint die Sonne auf die Sensorzelle. Die Blendung lässt die Signalstärke zurückgehen. Das war zu erwarten. Und nun haben wir die 47 Ohm eingesetzt. Tätärätä: Tatsächlich wird die Spannung am Ausgang wieder größer. Möge das Ganze nachher im Boot immer noch so gut funktionieren (Oder mit der Bibel gesprochen: Psalm 121, Vers 8).

 

16.2.2011

 

Zur Abwechslung sind mal wieder fast alle da. Und der Prototyp des Laserstrahlhäckslers ist fertig. Er sieht sehr handgemacht aus und läuft sehr unrund. Da er nur den Laserstrahl zerhacken soll und nicht auch den Laserpointer, müssen wir ein bisschen mit dem Stativmaterial improvisieren. Jäkel: „Eine Leybold-Muffe passt natürlich nur zu einer Leybold-Stativstange, ist doch logisch, oder?“

 

 

Wir testen das Ganze mit dem Prototyp unserer Sensorsolarzelle. Okay, das Oszillogramm zeigt ein Rechtecksignal, und aus den Längen der Impulse kann man genau rekonstruieren, wie ungleich groß die Scheibenausschnitte sind. Wegen der Unrundizität (auch Unwucht genannt) stellt sich allerdings eine maximal erreichbare Frequenz von ca. 250 Hertz heraus, danach fängt der Aufbau an, vom Tisch abzuheben.

 

„Wir könnten eine Firma beauftragen, mit einer CNC-Werkzeugmaschine eine perfekte Schlitzscheibe herzustellen.“

 

„Wir könnten das auch bleiben lassen.“

 

Und dann kommt die Erkenntnis zum Tage. Wir haben da doch diesen TRIX-Baukasten (nein, keine Schleichwerbung; die Firma gibt’s nicht mehr) in der Sammlung. Und in dem gibt es eine wundervolle Auswahl an wundervollen Zahnrädern:

 

 

 

Niklas baut das Ding zusammen, und - wer sagt’s denn: Funktioniert! Und zur Not sogar weit über 800 Hz. Nur das Leybold-Stativmuffendesign ist irgendwie peinlich. Sollten wir bis zum Wettbewerb noch Zeit finden, müssen wir da noch mal einen künstlerisch wertvollen Entwurf hinkriegen. Nun gut. Wir verbinden also die bewährte Sensorzelle mit ihrer Hochpass-Verstärker-Gleichrichterschaltung, klemmen das Oszilloskop an den Ausgang und haben noch nie ein so schönes Steuersignal gesehen.

 

Halt, noch nicht applaudieren! Im Einsatz muss das Ding auch noch auf 10 Meter Entfernung funktionieren. Wir entwirren den Drahtverhau aus Kabeln, ziehen mit dem Zerhacker und seinem Netzteil einmal quer durch die Physiksammlung in den Raum auf der anderen Seite und zielen mit dem Laser von dort auf die Sensorzelle. Laut Google Maps sind das 10 Meter. Okay, wir hätten auch ein Maßband nehmen können.

 

 

Das Zielen ist übrigens gar nicht so leicht (Hallo, Leute, bitte nicht mit den Köpfen in den Laserstrahl, verdammt noch mal!), weil man den Lichtpunkt bei der Tageshelligkeit praktisch nicht sieht. Wir verfolgen den Strahl mit einem weißen Blatt Papier und schaffen es, ihn gerade so auf den unteren Rand der Sensorzelle zu justieren. Er divergiert schon ein bisschen stark, geht aber noch nicht über den Rand. Aber das genügt ja. Solange das ganze Licht auf die Zelle fällt, sollte auch das ganze Signal noch da sein. Alle versammeln sich um das Oszilloskop. 3 Volt. „Das Boot kommt jetzt aus dem Kurs.“ Wir verschieben den Sensor. 0,5 Volt. „Das Boot steuert zurück auf den Kurs.“ Wir schieben den Sensor zurück. 3 Volt. Fett und kursiv: Jubel bricht los!

 

 

Nicht, dass wir damit das schnellste Boot bauen, aber es wird bestimmt die genialste Steuerung, die die Welt je gesehen hat. 

 

23.2.2011

 

Nachdem der Prototyp der Schaltung mit dem Prototyp des Sensors funktioniert, ist es nun an der Zeit, die echten und endgültigen Sensoren zu basteln (Natürlich erst, nachdem die wackeren Streiter sich mit kiloweise Pizza gestärkt haben). Außerdem beschließen wir, die Brennstoffzelle nicht einfach an Deck zu stellen, sondern sie tiefer zu legen (kennt noch jemand Max Manta und Juppi Körner?). Dann steht sie den Sensoren nicht so im Weg. Zu diesem Zweck wird mit der Laubsäge ein Ausschnitt in das Deck gesägt (Alex und Daniel messen auf Millimeterbruchteile den Umriss des Lochs aus). Wieso heißt das Ding eigentlich Laubsäge? Sägt man damit Laub? Das fällt doch im Herbst von selbst runter. Und ’ne Eiche fällen kann man damit auch nicht, obwohl sie ein Laubbaum ist (Höchstens eine ganz kleine). Wie auch immer, Jan-Hendrik dezimiert den Bestand an Sägeblättern, und schließlich ist ein Loch in der Aluplatte, durch das die Brennstoffzelle saugend-schraubend eben gerade nicht durchpasst. Weil die elektrischen Anschlüsse rausstehen. Also noch ein Ausschnitt, diesmal handgemacht von Niklas. Und noch ein Sägeblatt.

 

 

 

Das Loch in der Platte spart 1,4 Gramm Aluminium ein. Die fünf Plastiksäulen für die Sensoren können daraufhin je 2,5 Zentimeter gekürzt werden: spart zusammen 7,2 Gramm (Dreisatz: 1cm Plastikschiene wiegt also 0,576g, aber wer will das schon wissen?). Außerdem werden Janine und Johanna beim Sägen fotografiert, weil sie sich beschwert haben, sie seien auf der Internetseite nirgends zu sehen.

 

 

Solarzellenbruch kontaktieren (ein Bruch geht dabei zu Bruch, also noch mal, und trotzdem bleibt ein Kabel übrig; wer kann da nicht zählen?). Die eine Lötstelle verbraucht dann soviel Zinn, dass die ganze schöne Gewichtsersparnis vermutlich wieder aufgebraucht ist. Zweikomponentenkleber anrühren, kleben ... Nicht drücken, nur kleben! Sonst fraktalisieren wir den Bruch weiter!

 

 

 

Schließlich abbinden lassen, das dauert. Herr Jäkel verteidigt die halbfertigen Sensoren, die da so vor sich hin trocknen, am späten Nachmittag erfolgreich gegen die Putzfrau und genießt dafür das Privileg, das Abknabbern der überstehenden Flächen abends allein zu erledigen. Das war die gute Tat zum 23. Februar.

 

 

2.3.2011

 

Die fünf Sensoren sind fertig und harren erschütterungsfrei gelagert in einer Hartschaumbox (man könnte auch sagen Styropor, wenn man wüsste, wie man das schreibt) ihrer zukünftigen Verwendung. Die heutige Sitzung ist von einem Mangel an Teilnehmern und Teilnehmerinnen gekennzeichnet. Niklas setzt sich an den PC und nimmt sich das Steuerprogramm vor, um ein paar Ideen einzubauen, die er sich unterdessen überlegt hat. Die Simulation unterscheidet jetzt fünf Fahrstufen wie ein klassischer Maschinentelegraf: Null bis Vier, oder nautisch ausgedrückt: Stopp, ganz langsam, langsam, halb und voll. Allerdings nur voraus. Rückwärts ist bei einem Wettbewerb nicht vorgesehen und wer bremst, hat sowieso verloren. Damit gelingt es tatsächlich fast perfekt, das simulierte Boot auf Kurs zu halten. Außer in einer ganz speziellen Extremsituation, in der es nach der falschen Seite abbiegt. Das darf dann eben nicht passieren. Es sei denn, es fällt uns noch etwas ein. Immerhin schafft das Boot in neun von zehn Fällen die simulierten 10 Meter Rennstrecke mit Erfolg. Und da wir drei Versuche haben, ist die Wahrscheinlichkeit eines Totalversagens nur noch ein Promille. Bei dem geringen Risiko verkauft uns ja vielleicht eine Marineassekuranz eine günstige Havarieversicherung...

 

Außerdem sind nun alle Teile für die Steuerelektronik beisammen. Das sieht im Moment noch so aus:

 

 

Da muss jetzt nur noch das Runde (=Anschlussdrähte) in das Eckige (=Streifenraster-Platine), nur dass es im Gegensatz zum Fußball sehr viele runde Teile gibt, die alle auf dem eckigen Teil Platz finden müssen. Jan-Hendrik verspricht, zur nächsten Woche einen Bestückungsplan zu zeichnen.

 

9.3.2011

 

Der Bestückungsplan ist fertig, lässt aber Fragen offen. Jan-Hendrik meint, die Platine sei zu klein für die Schaltung (immerhin 5 Kanäle, pro Sensor einer). Wie viel Platz braucht man für eine Leiterbahnunterbrechung? Was wiegt eine Kabelbrücke (samt Lötstelle)? Da müssen wir noch mal drüber. Außerdem wäre es ja nun an der Zeit, das Steuerprogramm von JAVA auf Assembler umzustricken. Haben wir nicht noch das vom vorigen Jahr, das von unserem Solarbrunnen, als Muster? Leider nicht mehr auf diesem Rechner; zwischen damals und jetzt liegt ein Festplattencrash mit Totalverlust der Daten. Immerhin haben wir damals eine ganz ordentliche Doku ins Netz gestellt, der Quelltext ist also noch verfügbar (Ein Hoch auf die Datensicherung!). Also frisch ans Werk!

 

 

 

Es wird im Handbuch geblättert. Wie ging das noch mal? Öffnen eines neuen Projektes, Auswahl des passenden Controllers. Aha. Und selbstverständlich alles auf englisch. Bilingualer Unterricht, sozusagen. Der Assembler kennt natürlich nicht so komfortable Strukturen wie

 

if ((sensor==2) && (altsensor==2))

{ motor(1,VOLL); motor(2,VOLL); }

 

Hier ist alles gnadenlos bit-orientiert, und das gute alte GOTO feiert fröhliche Urständ (laut Wikipedia Althochdeutsch für "Auferstehung"). Wir diskutieren und entwerfen an der Tafel eine Logik, die wenigstens schon mal die Nummer des beleuchteten Sensors identifiziert...

 

 

...und verwerfen sie kurz darauf wieder, weil sie hoffnungslos umständlich wird. Vermutlich würde der Arbeitsspeicher des Controllers dafür gar nicht ausreichen. Wir müssen jetzt eben auch gnadenlos bit-orientiert denken. Ein Sensorereignis ist keine Nummer, sondern ein gesetztes Bit auf Port B. Ja, so könnte es gehen ... aber nicht mehr heute.

 

16.3.2011

 

Jan-Hendrik gibt heute eine kurze Sondervorstellung, indem er eine Kochplatte und ein Paket Nudeln auspackt und nach einem Kochtopf fragt. Er sei heute noch nicht zum Mittagessen gekommen. Wir nehmen das mal als Comedy-Einlage. Außerdem muss er gleich wieder weg, weil er von der Theater-AG als Beleuchter gebraucht wird. Aha, daher also der Hang zum Dramatischen.

 

Die restlichen Jungs basteln am Controller-Programm weiter, brauchen aber wohl noch eine Weile, um sich in BTFSC (Bit Test File Skip if Clear) und DECFSZ (Decrease File Skip if Zero) reinzudenken.

 

Nachdem die Sensoren nun fertig sind, könnten wir sie eigentlich wieder auf dem Boot befestigen. Janine und Johanna nehmen die Aufgabe in Angriff und geben zunehmend laute Laute des Unwillens von sich. Was gibt’s? “§$%&/())(/&%$§!“ (=Druckfassung eines nicht druckbaren Fluchs). Die L-Profile haben ja alle schon mal in Reih und Glied an Deck gestanden, mit kleinen Winkeln (und Metallschrauben) befestigt, nur damals noch ohne die Solarzellen. Da die Bohrungen für die Schrauben aber von Hand gemacht sind, sind sie natürlich nicht genormt, und jedes Teil passt nur an einer einzigen Stelle. Jetzt haben wir also ein Puzzle aus 15 Teilen (5 Sensoren mit je 2 Befestigungswinkeln), von denen sich aber jeder Winkel noch in zwei Lagen an zwei Positionen anschrauben lässt. Das ergibt nach den Gesetzen der Kombinatorik: 5! * 10! * 2 = 870 912 000 verschiedene Möglichkeiten, wie die Sensoren und Winkel an Deck verteilt werden können. Und nur eine davon ist richtig. Nach einer Stunde haben die Mädels vier Sensoren einigermaßen angeschraubt (mit Plastikschrauben!), aber der letzte passt beim besten Willen nicht mehr, und die übrigen vier stehen windschief herum wie der sibirische Wald nach dem Tunguska-Meteoriten.

 

 

Man hätte vor dem Auseinanderbauen natürlich farbige Markierungen anbringen können, welche Winkel an welchen Sensor gehören (und wie herum), aber das ist uns leider erst jetzt eingefallen (oder, wie ein afrikanisches Sprichwort besagt: „Hätte war gestern!“). Sie geben entnervt auf. Die einfachste Lösung besteht zweifellos darin, zehn neue Befestigungswinkel zu sägen und zu bohren.

 

Dafür sind wir an einer anderen Baustelle deutlich weitergekommen. Eine Schnapsidee des AG-Leiters besteht nämlich darin, dem Mikrocontroller noch am Ort des Wettbewerbs letzte Instruktionen über die Zuordnung zwischen Fahrstufen und Motordrehzahlen übermitteln zu können (z.B. je nach Windverhältnissen), wozu eine PC-Schnittstelle eingebaut werden muss. Die ist jetzt im Controller-Code drin, und es gibt auch schon ein PC-Programm zur Datenübermittlung.        

 

 

Da wir Visual Basic auch weiterhin meiden, hat Herr Jäkel es in der historischen Sprache Turbo-Pascal geschrieben. Das sieht etwas handgestrickt aus und kennt keinen USB-Port, nur die serielle Schnittstelle. Was natürlich Windows XP zu Panikreaktionen veranlasst. Windows: „Die Anwendung versucht auf die serielle Schnittstelle COM2 zuzugreifen!“ Wir: „Ja, und?“ Windows: „Abbrechen oder ignorieren?“. Schon gut. Wir werden einen Laptop mit Windows 98 auftreiben – oder Windows 3.11, das ist noch sicherer. Es lebe der Fortschritt!

 

23.3.2011

 

Ein erfolgreicher Tag. Niklas beendet den ersten Teil der Routine für den Mikrocontroller (Sensorabfrage und Erkennen der Kursabweichung). Da Lötexpertin Lara nicht mehr in unserer AG ist, weil sie, seit der Mittelstufe der Elektronik-AG treu, nun fürs Abitur lernt (man müsste ihr eigentlich ein Denkmal errichten, etwa in Miss-Liberty-Pose, eine Lochrasterplatine unter dem Arm und einen Lötkolben in den Himmel gereckt), haben Janine und Johanna sich bereit erklärt, das Löten zu übernehmen. "Aber lieber erst mal etwas Einfaches". Schön, den Damen kann geholfen werden. Für das Computerinterface zur Datenübertragung existiert ein Prototyp in Gestalt eines Drahtverhaus:

 

 

Das Ding muss jetzt auf eine Platine. Nach einer kurzen Einführung in die Technik des Lötens von Herrn Jäkel und begleitet von Daniels überaus zahlreichen guten Tipps machen sie sich ans Werk, den Bestückungsplan in eine Schaltung umzusetzen.

 

 

 

Mit nur einem falsch eingelöteten Kondensator (Auslöten, die leider schon abgeschnittenen Anschlussdrähte wieder anstückeln, neu einlöten) und einer Zeitüberschreitung von nur 15 Minuten über das offizielle Ende der AG hinaus gelangen sie ins Ziel. Die Platine wird mit dem PC verbunden, die Datenübertragung wird gestartet. Die Daten gelangen zwar noch zu keinem Controller, weil der noch nicht fertig programmiert ist, aber die zur Kontrolle eingebauten Leuchtdioden flackern im richtigen Takt: Funktioniert!

 

 

30.3.2011

 

Wie vor zwei Wochen bereits angedroht, werden nun zehn neue Befestigungswinkel für die Sensoren gesägt. Diesmal machen wir es hoffentlich schlauer und gehen systematisch vor. Das ist öde, weil man nur langsam vorankommt, aber wie wir gesehen haben, dauert die schnellere Lösung noch länger. Der AG-Leiter erlaubt sich, diese Gelegenheit zu ergreifen und auf eine Lebensweisheit aus langjähriger Erfahrung hinzuweisen, die den jungen Leuten immer so schwer zu vermitteln ist:

 

Mach's langsam, dann geht's am schnellsten!

 

Das bedeutet hier: Zwei Winkel mit je einem Loch versehen. Die Winkel in der vorgesehenen Position an Deck festschrauben. Eine Sensorsäule (sie hat schon Löcher, und die bleiben auch da wo sie sind, denn mit der schon aufgeklebten Solarzelle kann man hier nicht mehr bohren!) in der vorgesehenen Position an die Winkel halten. Die Löcher durchzeichnen. Die Winkel wieder abschrauben. Die angezeichneten Löcher bohren. Die Winkel an den Sensor schrauben. Das Ganze auf das Deck schrauben. Und diese Prozedur für jeden der fünf Sensoren. Fühlt sich an wie zwei Schritte vor und drei zurück, führt aber nach endlicher Zeit zum gewünschten Ergebnis. Lösungen der Art "Da könnte man doch einfach..." sind manchmal genial, das sei zugegeben. Aber meistens führen sie nur zügig zur Katastrophe und dann kann man noch mal bei Null anfangen. Und mit Pech hat man dabei ein teures Bauteil zerstört (Wir erinnern uns noch deutlich an den zerschossenen Mikrocontroller vom vorigen Jahr, den wir falsch gepolt an die Betriebsspannung angeschlossen hatten). Wer kein Genie ist, sollte also beizeiten die andere Methode erlernen (In der Bibel zu finden unter Sprüche Salomos 19, Vers 2).

 

 

Tja, und dann kommt nun, wohl oder übel, die Steuerplatine an die Reihe. Da sie auf Streifenraster gebaut wird, sind zunächst etliche Leiterbahnunterbrechungen zu bohren. Janine und Johanna nehmen einen Filzstift und zeichnen die Löcher an. Löcher anzeichnen wird echt zu einer Lieblingsbeschäftigung.

 

 

Nach Übertragen aller Löcher vom Bestückungsplan auf die Platine empfiehlt Herr Jäkel, sie zur Kontrolle nachzuzählen. Er kommt auf 64 Löcher in der Vorlage. Die Mädchen kommen auf 62 auf der Platine. Wir tauschen. Die Mädchen kommen auf 63 in der Vorlage. Herr Jäkel kommt auf 62 auf der Platine. Niklas zählt die Löcher auf der Platine. Jetzt sind es 64. Die Markierungen auf der untersten Leiterbahn sahen irgendwie nicht aus wie Markierungen, aber wenn man sie mitzählt, stimmt es. Ob es wirklich stimmt, merken wir dann hoffentlich nächste Woche beim Löten.

 

6.4.2011

 

Nichts Neues unter der Sonne. Wir sägen und bohren Winkel. Die Plastikschrauben sind zu lang. Jan-Hendrik entsinnt sich seiner Erfahrung im Gewindesägen vom Vorjahr, probiert es mit Feinsäge und Puksäge, stellt dann aber fest, dass man Plastikschrauben viel einfacher mit einem Seitenschneider kürzt. Die Mädels löten die IC-Sockel ein (schweren Herzens haben wir den Nachteil des zusätzlichen Gewichtes zugunsten der Auswechselbarkeit durchgebrannter ICs in Kauf genommen), dann müssen sie auch schon wieder los. Auf die Weise dauert es bis nach Weihnachten. Niklas übernimmt und lötet von drei bis fünf Uhr an der Steuerplatine. Jetzt wissen wir endlich, wozu im Physikbuch die Farbcode-Tabelle für Widerstände abgedruckt ist.

 

 

Der Bestückungsplan erweist sich bisher als korrekt, es fehlen keine Löcher (Der geneigte Leser ist herzlich eingeladen, anhand der Bilder oben selber mal nachzuzählen. Achtung: Die Platinenunterseite ist spiegelbildlich zum Bestückungsplan!). Wobei das Fehlen von Löchern ja in ontologischer Hinsicht durchaus problematisch ist. Bei einem Loch fehlt immer etwas, sonst wäre es kein Loch. Was fehlt aber, wenn ein Loch fehlt? Wie gut, dass wir eine Elektronik-AG sind und keine Philosophie-AG.

 

13.4.2011

 

Zwei Tage bis zu den Osterferien, und danach noch gerade mal vier Wochen bis zum Abgabetermin der Doku. Jetzt wird's allmählich ungemütlich. Aber wenn gegen Ende kein Stress aufkommt, ist sowieso irgend etwas falsch. Außerdem sind wir ja eigentlich fast fertig. Die Arbeit an der Platine schreitet voran. Alle Widerstände drin, alle Stecksockel drin, fast alle Kondensatoren drin (beim Wegräumen fand sich noch ein nicht eingelöteter, und nach Studium des Bestückungsplans auch die Stelle, an die er gehört hätte. Na ja, den kriegen wir auch noch). Fehlen eigentlich nur noch die Relais und die Transistoren und der Quarz. Die Mädels machen das sehr ordentlich. Offenbar haben sie die Grundregel des Platinen-Bestückens gelernt: Lieber fünfmal nachprüfen als einmal wieder auslöten.

 

 

 

Die Sensoren sind erneut angeschraubt und stehen jetzt an Deck wie eine Eins. Der miese Job (siehe 30.3.) hat sich also gelohnt. Grr, In der einen Solarzelle ist ein Haarriss! Entweder sie funktioniert trotzdem, oder wir müssen einen Sensor noch mal neu machen. Das sehen wir dann.

 

 

Gelegentlich müssen wir an einen Probelauf denken. Jan-Hendrik darf mit offizieller Erlaubnis das Schulgelände verlassen und tobt mal eben rüber zum Schwimmbad. Der Bademeister zeigt Verständnis und gibt uns einen Termin, an dem wir das Boot im Freibad zu Wasser lassen dürfen. Am 7. Mai. Das ist genau eine Woche nach den Ferien. Jetzt wird es richtig hart. Das bedeutet, dass wir in der einen Woche heftig ranklotzen müssen, damit das Boot am Samstag einsatzfähig ist. Natürlich wird es nicht funktionieren. Kein Ding von dieser Kompliziertheit funktioniert beim ersten Versuch. Aber man braucht den ersten Versuch, damit man bis zum zweiten die Fehler suchen und beheben kann. Jedenfalls steht damit der Termin fest, ab dem die ganze Mechanik beginnen wird zu rosten, weil sie nass geworden ist. Ist eigentlich eine blöde Erfindung, dass Boote im Wasser nass werden. Mit einem Flugzeugwettbewerb hätten wir das Problem nicht – oder? (Plötzlich habe ich die Szene aus "Quax – der Bruchpilot" vor Augen, in der Heinz Rühmann seine Maschine unprogrammgemäß gewassert hat).

 

Das Steuerprogramm gilt weiterhin als fast fertig. Theoretisch (d.h. auf dem Emulator) verzweigt es je nach Sensorbeleuchtung in die richtige Unterroutine, die die Motordrehzahlen setzt. Hoppla, meint Niklas, damit drehen die Motoren aber noch nicht! Der Controller muss ja auch noch die Relais takten. Wann soll er denn das noch machen, wenn er dauernd die Sensoren abfragt? Gut erkannt. Herr Jäkel entwirft an der Tafel ein Programmschema, in dem die Abfrage der Sensoren und das Takten der Relais ineinander verschränkt ablaufen. Sensoren checken, Drehzahlparameter setzen, Zähler erhöhen. Mit aktuellem Parameter vergleichen. Überschritten? Dann Relais aus. Schleife: Wieder die Sensoren checken. Zähler erhöhen. Wenn 255 erreicht, Relais wieder an. Und so weiter.

 

Leider ist der Handy-Akku leer, und das wertvolle Tafelbild kann nicht dokumentiert werden. Das Handy an die Ladung - aber vergebens: Als es geladen ist, hat jemand in seiner Ordnungsliebe schon die Tafel abgewischt. Rekonstruktionsversuch - es sah sinngemäß so aus (wenn auch nicht ganz so schön):

3.5.2011

 

Außerplanmäßige Sitzung der AG am Dienstag nach den Osterferien. Alle gut erholt? Schön. Dann kann ja jetzt rangeklotzt werden, am Samstag soll das Boot in der Schwimmhalle zu Wasser. Ohne die Steuerplatine läuft nichts, und die ist noch nicht fertig. Leider ist Janine nicht da. Johanna lötet mit männlicher Assistenz, und es geht sofort schief. „Ist der Lötkolben schon warm?“ – „Aua!“ – „Also ja.“ (Erste-Hilfe-Kurs: Brandwunden sind sofort durchdringend zu kühlen!)

 

 

Der vergessene Kondensator wird eingebaut. Ach ja, da sind ja noch 5 weitere Kondensatoren. Und die Relais ... „Ist der schwarze Strich auf dem Relais auch der schwarze Strich auf dem Bestückungsplan?“ – „Ja.“ – „Super. Dann haben wir beide Relais falsch herum eingelötet.“ Die Entlötpumpe kommt zum Einsatz. Fump! Fump! ... insgesamt 16 mal.

 

 

Jan-Hendrik konstruiert einen genialen Halter für die Treibstofftanks (20-Milliliter-Plastikspritzen, steril verpackt) aus 0,75mm-Spulendraht. Das Ergebnis wird von Herrn Jäkel kritisiert als „hochgradig unprofessionell“. „Hält aber.“

 

Das Steuerprogramm? Niklas kann erst später kommen. Wie sich am Tag darauf herausstellt, kam Niklas tatsächlich später. Allerdings, als niemand mehr da war.

 

4.5.2011

 

Planmäßige Sitzung der AG am Mittwoch. Herr Jäkel stellt eine Konstruktion aus Plastikschrauben und Gummibändern vor: „Ich hab da mal einen alternativen Plan für die Befestigung der Tanks.“ Jan-Hendrik erkennt freundlicherweise die prinzipielle Eignung des Vorschlags an und setzt sie in die Tat um.

 

 

 Die letzten Bauteile kommen auf die Steuerplatine. „Die eine Diode muss auch noch umgedreht werden. Und dass mir keiner der Jungs mehr die Platine anfasst!“ Die autoritäre Anweisung des AG-Leiters degradiert die restlichen männlichen Hilfswilligen zu Drahtabschneidern und -abisolierern.

 

 

 

Dank der Arbeitsteilung geht es flott voran und die Platine wird fertig. FERTIG! Jetzt sollten wir sie testen. Aber der Controller ist noch nicht programmiert. Und wenn wir einen Fehler finden (und wir werden einen finden!), dann reichen die restlichen fünf Minuten nicht mehr, um ihn zu beheben. Also würden wir mit einem Frust nach Hause gehen, und das wollen wir doch nicht.

 

Jan-Hendrik entwirft an der Tafel eine Platz und Gewicht sparende Platine, auf der wir die Batterien unterbringen. Der Vorschlag, eine geheime Leitung von dort zu den Motoren zu legen, wird als unmoralisch (und anhand der dann zu erwartenden riesigen Bugwelle des Bootes auch zu leicht zu durchschauen) verworfen.

 

 

Bei der praktischen Ausführung kommt eine Laubsäge zum Einsatz, und der inzwischen angeschaffte Vorrat an Ersatzsägeblättern wird schon mal bereit gelegt, dann aber erstaunlicherweise gar nicht benötigt. Dafür splittert die Platine. Aber nur so ein bisschen, ganz an der Kante, wo es nicht stört. Außerdem stellt sich heraus, dass in den Ferien jemand (wir wissen auch, wer; und wir wissen auch, wo dein Fahrrad steht!) an unserem Laserstrahlzerhacker herumgespielt und ihn hoffnungslos dejustiert hat. Herr Jäkel verspricht, auf der heimischen Drehbank einen weiteren 2mm-auf-4mm-Adapter herzustellen und das Problem damit final zu lösen. Was dann übrigens auch gelingt.

 

 

6.5.2011

 

Außerplanmäßige Sitzung am Freitag. Johanna: "Ich weiß schon, wie der Tisch nachher aussehen wird." Ja, wir auch. Um es gleich zu sagen: Die morgige Wasserung des Bootes findet nicht statt. Dabei fing es so gut an. Die Platine ist fertig. Wir testen die fünf Verstärkerkanäle mit Solarzelle, Laserflackerlicht (aus dem neuen Zerhacker) und Oszilloskop. Kanal 1 bis 4 funktionieren auf Anhieb. Bei Kanal 5: kein Bild, kein Ton. Mittels einer Prüfspitze ... wisst ihr, was eine Prüfspitze ist? Man klemmt einen übrig gebliebenen Drahtschnipsel von einem eingelöteten Widerstand in eine Greifklemme, steckt ein Kabel mit einem Ende in die Klemme und mit dem anderen ins Oszilloskop. Damit wir uns klar sind, wovon wir reden – das sieht dann so aus:

 

 

Damit tastet man sich von Kontakt zu Kontakt den Signalweg entlang (wenn man von der Bestückungsseite her nicht rankommt, gerne auch von der Lötseite; zu diesem Zweck wird der Bauplan einmal spiegelverkehrt ausgedruckt, damit man auch von unten die Orientierung behält). Bei jedem zweiten Versuch fällt der Bananenstecker des Kabels aus der Buchse der Greifklemme. Ganz ruhig bleiben! Beim letzten Widerstand des Signalwegs ist das Signal weg. Deswegen heißt er Signalweg. Kalte Lötstelle. Wir korrigieren durch Nachlöten. Wir testen Kanal 5 erneut. Bingo! Lebt!

 

Nun kann ja nichts mehr passieren. Es beginnt die Endmontage des Bootes. Batterieplatine. Steuerplatine. Die unten heraushängenden 100 Meter Kabel durch die Löcher des Bootsdecks fädeln, kürzen, abisolieren, an die Pfostenleiste löten. Bezüglich der Drehrichtung der Motoren sind wir uns noch nicht ganz klar. Sollen die beiden gegenläufigen Schiffspropeller einwärts oder auswärts drehen? Die Seefahrtsexperten beschließen einwärts und trösten sich damit, dass das gegebenenfalls durch Umpolen der Brennstoffzelle leicht geändert werden kann. 

 

 

 

Jetzt sind alle Bauteile drin bis auf den Mikrocontroller. Wenn man jetzt mit der berühmten Prüfspitze (siehe oben) die Pins, mit denen der Controller  die Relais einschalten wird, auf Plus legt, müssten die Relais die Motoren einschalten. Die Tanks werden am Elektrolysator mit Wasserstoff und Sauerstoff geflutet (und der Experimentiertisch mit destillierten Wasser. Wobei Jan-Hendrik das trostreiche Statement abgibt, destilliertes Wasser hinterlasse zumindest keine Rückstände beim Verdunsten).  Die Tanks werden mit der genialen Gummibandkonstruktion unter das Boot geschnallt. Kontakt. Kontakt? Keine Reaktion. Die Relais klicken nicht einmal. Platine raus, umdrehen, kalte Lötstellen suchen. Tatsächlich. In jedem Relaissteuerkreis eine. "Neulich hab' ich euch noch gelobt, Mädels!" – "Das mit den Relais waren wir nicht!" Egal, wir löten nach. Neuer Versuch. Relais klicken, aber Motoren laufen nicht. Dawirddochderhundinderpfanneverrückt! Der AG-Leiter wird plötzlich nachdenklich. "Äh, Leute, ich glaube, da ist ein Fehler im Bestückungsplan. Die Motoren müssen mit einem Pol direkt an die Brennstoffzelle." Von schlechtem Gewissen erfüllt, lötet Herr Jäkel die Korrektur selbst.

 

Erneuter Test führt zum Erfolg. Die Motoren drehen. Gegenläufig. Einwärts. Zwanzig Sekunden lang. Dann ist der Sprit alle. Das war ja schon mal gar nicht schlecht, aber damit kommen wir leider keine zehn Meter weit. Moment mal. Direkt am Elektrolysator angeschlossen liefen unsere Motoren mit 10 Milliliter Wasserstoff viel länger. Und in den Spritzen sind 20 Milliliter. "Nehmen wir die größeren Spritzen!" – "Die wiegen aber mehr!" – "Ja doch. Aber was nützt ein leichtes Boot, das es nicht bis ins Ziel schafft?"

 

Okay, wir nehmen die 50-Milliliter-Spritzen. Größer geht nicht, mehr Platz ist nicht unter dem Boot. Die Verbesserung ist nichtsdestoweniger minimal. Bing! Erkenntnis! "Was nützen 50 Milliliter Wasserstoff in der Spritze? Die müssen in die Brennstoffzelle!" Offenbar haben wir an dieser Stelle die Funktionsweise einer Brennstoffzelle nicht wirklich verstanden. Wir hatten angenommen, dass in ihr, wenn sie Wasserstoff und Sauerstoff zu Wasser verarbeitet, durch das nun zu Wasser gewordene Gas ein Unterdruck entstehen müsste, der frischen Treibstoff von selbst nachsaugt. Zweifellos ein Irrtum. Das wird einem aber auch in den tollen Handbüchern nirgends erklärt.

 

Es ist doch gut, von technischen Genies umgeben zu sein. Eine Schraube (Plastik) in den Kolben der Spritze, ein Gummiband herumgeschlungen, und wir haben einen Den-Wasserstoff-langsam-aus-der-Spritze-Press-Apparat. Ersetzen wir Wasserstoff durch sein chemisches Symbol H, so erhalten wir das eingängige Akronym HASPA (= H-Aus-Spritze-Press-Apparat. Wir gehen mal davon aus, dass die Hamburger Sparkasse etwas mehr Humor hat als jener bekannte Kölnisch-Wasser-Produzent mit der vierstelligen Hausnummer, der sogar noch 007 auf Unterlassung verklagt hat, nur weil das auch eine Nummer ist. Außerdem darf die Haspa uns als Gegenleistung für diese kostenlose Werbung gern sponsern!). Da wir derzeit nur eine Spritze auf diese Weise umrüsten können, testen wir es mit Luft statt Sauerstoff als Oxidator. Zaghafte Begeisterung: Eine Minute, und die Spritze ist noch halb voll. Nur das Gummiband ist nun schlaff und haspat nicht weiter. Wir müssen eine zweite Spritze und ein stärkeres Gummiband besorgen. Aber wir könnten den morgigen Testlauf (noch glauben wir daran) auch mit Luftsauerstoff fahren. "Johanna bringt Badezeug mit und steigt dann ins Schwimmbecken, um das Boot zu bergen, wenn es mittendrin stehen bleibt!" Der Vorschlag stößt leider nicht auf Johannas Zustimmung. Auch die Drohung, sie dann eben in voller Montur ins Wasser zu werfen, stimmt sie nicht um. Außerdem könnte der dabei entstehende Tsunami das Boot versenken.

 

"Was ist mit dem Controllerprogramm?" – "Fertig. Soll ich es in den Chip brennen?" – "Ich bitte darum."

 

Der Rest ist peinlich und schnell berichtet. Der Controller wird eingesetzt, die Stromversorgung angeschlossen, und nichts passiert. Der Chip ist tot. Nicht mal ein Oszillatortakt ist zu messen. Nein, an Masterclear lag es diesmal nicht. Halbherzig suchen wir weitere kalte Lötstellen, finden aber keine mehr. Halbherzig brennen wir einen zweiten Chip, der sich aber ebenso tot stellt wie der erste. Der Fehler muss wohl auf der Platine sein. "Vielleicht ist der Quarz durchgebrannt." – "Kaum. Der hält von allen Bauteilen am meisten aus." – "Na ja. Man hat auch schon Pferde vor der Apotheke..." – Halbherzig tauschen wir den Quarz aus, aber es ändert sich nichts. Mist. Und so kurz vor dem Ziel. Inzwischen ist es 18 Uhr durch, und auch die letzten müssen allmählich nach Hause. Das ist die Stelle, an der wir die Testfahrt absagen müssen. Und Johanna muss folglich morgen auch nichts ins Wasser.

 

Bleibt zu erwähnen, dass Jan-Hendrik inzwischen einen atemberaubenden Halter für den Laserwerfer entwickelt hat. Mit Leybold-Muffen. Damit müsste eigentlich jeder denkbare Höhenunterschied zwischen Wasseroberfläche und Beckenrand ausgeglichen werden können, um den Leitstrahl auf die Höhe der Sensoren zu justieren. Wenigstens etwas.

 

 

 

Da alle anderen inzwischen wegdiffundiert sind, räumen Jan-Hendrik und Herr Jäkel zu zweit das Chaos weg. Johanna hatte mit ihrer Prognose Unrecht. Nicht der Tisch sah am Ende so aus. Sondern der ganze Physiksaal.

 

10.5.2011

 

Sondersitzung einer kleinen Teilgruppe (die anderen haben keine Zeit und diese drei auch nur ganz kurz) der Elektronik-AG. Wir ziehen den Controller raus und setzen ihn auf eine Experimentierplatte. Bauen nur Stromversorgung und Quarzoszillator auf. Wir messen. Keine Schwingung. Es war nicht die Platine. Es war die eine einsame Zeile am Beginn des Codes, die mit _CONFIG anfängt. Man übersieht sie leicht, weil sie immer da steht. Aber am Ende der Konfigurationszeile müsste stehen _XTOSC für „Quarzoszillator“. Steht da aber nicht. Da steht _RCOSC für RC-Oszillator. Mit anderen Worten: Der Controller weiß überhaupt nicht, dass ein Quarz da ist. Wir sagen es ihm, brennen den Code neu, stecken den Chip in die Platine. Heureka: Quarz schwingt.

 

 

Nun wollen wir natürlich sehen, ob auch die Relais schalten. Der Laserwerfer wird justiert und leuchtet auf den mittleren Sensor. Wir erwarten jetzt eigentlich das Kommando „Beide Maschinen voll voraus“. Aber die Relais rühren sich nicht. Messung am zuständigen Ausgang des Controllers ergibt in der Tat kein Signal. Messung am zuständigen Sensoreingang allerdings auch nicht. Als wir die Zerhackerscheibe abschalten, geht das Signal kurzzeitig auf Eins. Hä? Noch mal. Scheibe an. Signal kommt, Signal geht. Scheibe aus. Signal kommt, Signal geht. That’s it: Die Drehzahl ist zu hoch, unsere Sensorschaltung ist optimiert auf 800 Hz, aber bei voller Tourenzahl sind das offenbar mehr. Wir werden mal eben so nebenbei auch noch eine Drehzahlregelung für den Zerhacker konstruieren müssen. Und das zwei Wochen vor der Deadline. Sagte nicht jemand, wenn gegen Ende kein Stress aufkommt, sei irgendwas falsch? So gesehen alles bestens, alles nach Plan.

 

11.5.2011

 

Janine und Johanna – obwohl, wie wir nun wissen, dem nassen Element eher abgeneigt – beschäftigen sich in dieser Sitzung vor allem mit der Elektrolyse von Wasser, um unsere Testläufe mit hinreichend Treibstoff zu versorgen. Der Controller macht in der Tat irgend etwas. Bei beleuchtetem Mittensensor gehen beide Maschinen auf „voll voraus“. Bei beleuchtetem seitlichen Sensor schaltet er die Motoren etwa im Sekundentakt kurz an. Das aber nicht im Sinne des Erfinders (also uns), denn wir hatten eigentlich an eine unterschiedliche Tourenzahl gedacht (zwecks Lenkung), und außerdem – Sekundentakt? Der Controller läuft mit 4 Megahertz! Womit, bitte, beschäftigt der sich die ganze Zeit zwischen Einschalten und Ausschalten der Relais?

 

 

 

Die Leute am Computer lassen das Programm auf dem Emulator laufen, aber das dauert ewig, da die Schleife 256 mal durchlaufen werden muss, ehe ein Schaltvorgang sichtbar wird, und der Emulator läuft natürlich nicht mit 4 Megahertz! Nebenbaustelle: Das Programm so modifizieren, dass es die Schleife weniger oft durchläuft. Aber natürlich ohne dabei groß in die Programmstruktur einzugreifen, sonst bauen wir nur neue Fehler ein.

 

Davon unabhängig wird mit der Konstruktion der HASPAs experimentiert. Man kann das Gummiband vorn um die Spritze schlingen, dann wird sie ganz leer gepresst. Aber dann ist die Spannung des Gummibandes so groß, dass es zu schnell geht. Ein schwächeres Gummiband löst das Problem nicht, dann ist die Kraft wieder so klein, dass die Spritze zwischendurch stecken bleibt. Vorschlag: Hohe Kraft, eventuelle sogar zwei Gummibänder, aber eine Querschnittsverengung des Schlauchs mittels eines Quetschhahns. In der Tat zeigt sich, dass damit der Durchfluss gut reguliert werden kann.

 

 

 

Nach der Neubetankung der Spritzen für einen nächsten Testlauf stellt sich nur leider heraus, dass trotz unveränderter Einstellung des Quetschhahns nun kein Gas mehr strömt. Offenbar ist das nicht reproduzierbar. Forschungsauftrag: Warum nicht?

 

Mehrere Versuche später steht fest: Die Zuordnung zwischen Hahnstellung und Durchfluss ist, mathematisch gesehen, keine Funktion (Definition: "Eine Funktion ist eine nacheindeutige Zuordnung"). Technisch gesehen: Der Quetschhahn hat eine Hysteresis. Das klingt so ähnlich wie hysterisch, ist aber (laut Wikipedia) auf einen ganz anderen etymologischen Wortstamm zurückzuführen: hysteros = hinterher.  

 

 

Wenn man weit genug aufdreht, strömt Gas. Dann kann man aber weiter zudrehen, uns es strömt immer noch Gas. Der Gasstrom hält vermutlich den Schlauch offen. Erst wenn man ihn total zudreht, hört die Strömung auf. Dann bleibt er aber zu, auch wenn man die Schraube wieder lockert. Kurz: Hinterher benimmt er sich anders als vorher. Deswegen hysteros. Für uns heißt das: Mit dem Quetschhahn geht das so nicht! Wir brauchen einen definierten Querschnitt, zum Beispiel einen Stopfen mit einer Bohrung. Die allerdings dürfte wohl wesentlich kleiner sein als unser kleinster Bohrer.

 

12.5.2011

 

Einmannsitzung, Herr Jäkel und der Programmcode. Erst einmal werden alle relevanten Programmabschnitte und -befehle kommentiert. Dann wird der ja als funktionsfähig erkannte JAVA-Code in einem zweiten Fenster daneben geöffnet. Schließlich wird verglichen. Und nun zeigt sich mal wieder, dass GOTO der Quell allen Übels ist (Einer der Gründe einer tief sitzenden Visual-Basic-Abneigung: "Ich fürchte BASIC, auch wenn es objektorientiert ist" – abgewandeltes Zitat. Im Original bezog es sich auf das Trojanische Pferd und lautete: "Timeo Danaos et dona ferentes"): Ein paar nicht ordentlich überlegte Sprünge quer durch das Programm, und schon läuft es in die Wildnis. Nach längerer Analyse dessen, was das Programm eigentlich tun sollte, und was es statt dessen tut, wird klar, dass man den größten Teil der GOTO-Sprünge durch CALL ersetzen kann. Nach einem CALL kann man sich darauf verlassen, dass die Programmausführung nach Absolvierung der Subroutine wieder genau an diesen Punkt zurückkehrt und nicht irgendwo landet. Tatsächlich steigt die Taktrate der Relais damit im Probelauf auf rund 50 Hz, was für die Motorsteuerung eigentlich schon optimal ist.

 

Kleine Nebenrechnung zur Kontrolle: 256 Schleifendurchläufe dauern demnach 1/50 Sekunden. Ein Schleifendurchlauf dauert 1/(50*256) Sekunden = 1/12800 Sekunden. Bei 4 Megahertz Taktrate sind das 4000000/12800 = 312,5 Maschinentakte pro Schleifendurchlauf. Das sieht realistisch aus. Die Halben sind schon okay, denn je nach Verzweigungen dauern die Durchläufe etwas unterschiedlich lange. Außerdem waren es nur rund 50 Hertz (begrenzte Auflösung des Oszilloskops).

 

17.5.2011

 

Jan-Hendrik und Herr Jäkel in einer Privatsession. Der Controller steckt im Experimentierboard in einer künstlichen Bootsumgebung (Sensorsignale werden mittels der bereits vielfach erprobten Prüfspitzen gegeben), die Motoren sind durch Glühlampen ersetzt. Steuert er nun richtig? Nein. Nach jeder simulierten Kursabweichung reagiert er zwar, fällt aber, sobald der Sensor nicht mehr beleuchtet ist, wieder auf „voll voraus“ zurück. Das kostet uns gefühlte zwei Stunden Schweiß. Dann kommen wir auf den Gedanken, dass er immer wieder einen Reset auslöst und von vorn anfängt.

 

Warum tut er das? Die Erkenntnis kommt am späten Abend durch Vergleich mit einem früheren Programm, das wir mal vor Jahren für einen Ultraschall-Entfernungsmesser geschrieben haben. Damals noch mit einer alten Entwicklungsumgebung für WIN 3.11. In jenen Tagen musste man das Konfigurationsbyte noch von Hand setzen, die neue Version setzt es automatisch. Nur leider falsch. Wobei falsch relativ ist, der Hersteller hat sich ja etwas dabei gedacht. Der Reset alle Sekunde ist gewollt, vermutlich zur Wiederbelebung des Programms, wenn ein unvorhergesehener Zustand aufgetreten ist. Das Ganze nennt sich "Watchdogtimer". (Man kennt das ja: „Es ist ein unerwarteter Fehler aufgetreten. Das Programm musste beendet werden!“). Da wir aber Murphy’s Gesetz  kennen, können bei uns keine unerwarteten Fehler auftreten, sondern selbstverständlich immer nur erwartete Fehler. Wir brauchen diesen Wachhund also nicht („It’s not a fault, it’s a feature“). Man kann dieses Feature im Konfigurationsbyte (um wieder auf dieses zu kommen) abschalten. Man muss es nur tun. Wir tun es. Der Prozessor läuft. Für Freudentänze sind wir nur inzwischen zu müde.

 

18.5.2011

 

Erneuter Versuch zur Endmontage. Die roten Schiffsschrauben, die man in den Bildern sieht, waren Dummies, weil wir zuerst noch keine gegenläufigen hatten, und später hatten wir zwar welche, hatten sie aber in unserem Chaos irgendwo verkramt (genauer: Herr Jäkel hat sie verkramt!). Jetzt sind sie wieder aufgetaucht (wie passend). In den Bildern erkennt man sie leicht daran, dass sie schwarz sind. Nun werden sie also angebaut. An den Spritzenhalterungen haben wir noch je zwei Schrauben und ein Gummiband eingespart. Das komplett ausgerüstete Boot kommt auf die Waage. 700 Gramm. Das ergibt unserer früheren Berechnung zufolge eine Eintauchtiefe von 3cm. Sollten wir gehofft haben, dass das Boot berührungsfrei über die Wasseroberfläche gleiten wird, so müssten wir jetzt enttäuscht sein. Aber wir hatten das eigentlich nie gehofft und überlassen das Gleiten der Konkurrenzgruppe (sorry: Mitbewerbergruppe) mit dem Luftkissenboot. Wobei wir natürlich insgeheim hoffen, dass deren Propeller falsch herum drehen und das Boot unter Wasser saugen wird. Nein, das ist nicht nett. Wir haben aber in der Liste der bekannten Verkehrsregeln (2. Mose 20, Vers 1 – 17) kein Statement gefunden, das uns das untersagt. Trotzdem prüfen wir in einem Anflug von schlechtem Gewissen noch einmal die Drehrichtung unserer Propeller. Sie drehen richtig herum.

 

 

Die Sache mit den HASPAs ist noch nicht endgültig im Griff; die Durchflussdauer einer Spritze variiert mehr oder weniger unvorhersagbar zwischen 30 Sekunden (dürfte zu kurz sein)  und zwei Minuten (könnte ausreichen), aber wir haben ja noch bis zum Wettbewerb Zeit, daran herumzuoptimieren. Zwei weitere Spritzen (im Handel übrigens unter dem Namen „Blasenspritzen“ erhältlich; ich glaube, wir möchten nicht wirklich wissen, was damit in einer Arztpraxis tatsächlich gemacht wird) sind besorgt, die mit der dicken Gummidichtung, die nicht so leicht schiefziehen und verkeilen. Die häufige Wiederholdung des Procedere zahlt sich aus. Das Betanken und Einsetzen der Spritzen ins Boot geht uns inzwischen flüssig von der Hand.

 

  

 

Hat eigentlich mal jemand untersucht, wie schnell reiner Sauerstoff (der ja trotz seines harmlosen Aussehens eine ziemlich aggressive Chemikalie sein soll) so eine Gummidichtung auffrisst? Wir hoffen, er wartet damit bis nach dem Wettbewerb, sonst haben wir eine weitere Nebenbaustelle.

 

Das Boot ist jetzt theoretisch fertig. Es war nur noch nie im Wasser. Da es bei uns nur erwartete Fehler gibt, erwarten wir, dass es (nach Murphy) gleich beim ersten Probelauf absäuft. Prophylaktisch stellt Johanna fest, dass sie nicht hinterhertauchen möchte. Damit ist eigentlich alles klar geregelt. Die im Vorfeld des Wettbewerbs abzuliefernde Dokumentation kann fertiggestellt werden. Hier ist sie:

 

Dokumentation

 

 

1. Das Boot

 

So sieht es aus; von vorn, steuerbord, oben, backbord, achtern und unten:

 

 

 

 

 

 

 

 

 

2. Die Steuerung

 

So ist sie geschaltet:

 

 

 

Hochpass

 

Mikro-Controller

16F84

 

PC-Schnittstelle

 

Brennstoff-

Zelle

 

 

Sensor 1

 

Verstärker

B1

A4

 

 

 

 

 

 

 

 

 

 

Integrator

 

A3

 

 

 

 

 

 

 

 

 

 

Hochpass

 

A2

 

 

 

 

 

 

 

 

Sensor 2

 

Verstärker

B2

A1

 

 

 

 

 

 

 

 

 

 

 

 

Integrator

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Hochpass

 

A0

Jumper

 

Program

 

 

 

 

 

Sensor 3

 

Verstärker

B3

 

 

 

 

Run

 

 

 

 

 

 

 

Integrator

 

 

 

 

 

 

 

 

 

 

 

Hochpass

 

 

 

 

 

 

 

 

 

Sensor 4

 

Verstärker

B4

B7

Verstärker

 

Relais

 

 

 

Motor 1

 

 

Integrator

 

 

 

 

 

 

 

 

 

 

 

Hochpass

 

 

 

 

 

 

 

 

 

Sensor 5

 

Verstärker

B5

B6

Verstärker

 

Relais

 

 

 

Motor 2

 

 

Integrator

 

 

 

 

 

 

 

 

 

 

3. Der JAVA-Emulator

 

Hier können Sie ihn selber ausprobieren.

 

 

4. Das Steuerprogramm

 

Dies ist der Code: (Langweilig? à Code überspringen)

 

;*****************************************************************************

;

;    Projectname:     rennboot

;    Date:            2011-03-09 to 2011-05-18

;    File Version:    2.0

;

;    Author:          Elektronik-AG

;    Company:         Elsa-Braendstroem-Schule Elmshorn, Germany

;

;*****************************************************************************

;

;    Files required: P16F84A.INC

;

;*****************************************************************************

;

;    Notes:

;    eon zero emission Wettbewerb 2011

;

;*****************************************************************************

 

    list      p=16F84A        ; list directive to define processor

    #include <p16F84a.inc>    ; processor specific variable definitions

 

    __CONFIG   0x3FF0 ; _CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC

 

; '__CONFIG' directive is used to embed configuration data within .asm file.

; The lables following the directive are located in the respective .inc file.

; See respective data sheet for additional information on configuration word.

 

;***** VARIABLE DEFINITIONS

          udata

w_temp         EQU     0x0C   ; variable used for context saving

status_temp    EQU     0x0D   ; variable used for context saving

 

data_in        res 1          ; buffer for incoming data from pc

bitcount       res 1          ; counter for incoming data from pc

motor1_0       res 1          ; engine control values engine 1 stop

motor1_1       res 1          ; engine control values engine 1 slow

motor1_2       res 1          ; engine control values engine 1 half

motor1_3       res 1          ; engine control values engine 1 fast

motor1_4       res 1          ; engine control values engine 1 full

motor2_0       res 1          ; engine control values engine 2 stop

motor2_1       res 1          ; engine control values engine 2 slow

motor2_2       res 1          ; engine control values engine 2 half

motor2_3       res 1          ; engine control values engine 2 fast

motor2_4       res 1          ; engine control values engine 2 full

takt_1         res 1          ; actual pulse length for engine 1

takt_2         res 1          ; actual pulse length for engine 2

zaehler_1      res 1          ; counters for pulse length modulation

zaehler_2      res 1

temp_1         res 1          ; buffers for comparison of registers

temp_2         res 1

 

sensor         res 1          ; actual state of sensors

sensor_alt     res 1          ; history of sensor states

sensor_uralt   res 1          ; -//-

sensor_ururalt res 1          ; -//-

temp           res 1          ; -//-

 

;*****************************************************************************

 

RESET_VECTOR      CODE 0x0000 ; processor reset vector

 

     goto    start            ; go to beginning of program

 

ISR               CODE 0x0004 ; interrupt vector location

 

Interrupt:

 

     movwf   w_temp           ; save off current W register contents

     movf    STATUS,w         ; move status register into W register

     movwf   status_temp      ; save off contents of STATUS register

 

;  Place ISR Here

 

     movf    status_temp,w    ; retrieve copy of STATUS register

     movwf   STATUS           ; restore pre-isr STATUS register contents

     swapf   w_temp,f

     swapf   w_temp,w         ; restore pre-isr W register contents

     retfie                   ; return from interrupt

 

;*****************************************************************************

 

MAIN_PROGRAM    CODE

 

start:

                              ; init data direction

     BSF     STATUS,RP0       ; select bank 1

     MOVLW   0x3E             ; pattern 00111110 <- sensor port

     MOVWF   TRISB            ; set direction port B; 1-5 in, 0,6,7 out

     MOVLW   0x0D             ; pattern 00001101 <- pc contact port

     MOVWF   TRISA            ; set direction port A; 1 out, 0,2-4 in

     BCF     STATUS,RP0       ; select bank 0

 

     clrf    sensor_alt       ; clear all vaules

     clrf    sensor_uralt

     clrf    sensor_ururalt

     clrf    zaehler_1

     clrf    zaehler_2

     clrf    takt_1

     clrf    takt_2

 

     movlw   0x00             ;

     movwf   PORTA            ; reset port A

     movwf   PORTB            ; reset port B

 

     bsf     PORTB, 06        ; set engine 1, 2 full

     bsf     PORTB, 07

                              ; load engine control default values

     movlw   0x30             ;

     movwf   motor1_0         ; engine 1 stopp

     movlw   0x60             ;

     movwf   motor1_1         ; engine 1 slow

     movlw   0x90             ;

     movwf   motor1_2         ; engine 1 half

     movlw   0xC0             ;

     movwf   motor1_3         ; engine 1 fast

     movlw   0xF0             ;

     movwf   motor1_4         ; engine 1 full

     movlw   0x30             ;

     movwf   motor2_0         ; engine 2 stopp

     movlw   0x60             ;

     movwf   motor2_1         ; engine 2 slow

     movlw   0x90             ;

     movwf   motor2_2         ; engine 2 half

     movlw   0xC0             ;

     movwf   motor2_3         ; engine 2 fast

     movlw   0xF0             ;

     movwf   motor2_4         ; engine 2 full

 

;*****************************************************************************

 

mainprog:

 

                              ; check jumper (port A0)

     BTFSC PORTA,0            ; portA0=0? -> running mode

     call pc_contact          ; portA0=1? -> programming mode

                              ; Programming procedure:

                              ; 1.Connect PC to uC Port A

                              ; 2.Start PC program

                              ; 3.Enter values to PC

                              ; 4.Set jumper to programming mode. Engine stops

                              ; 5.Start transmission on PC

                              ; 6.PC transfers data and confirms transmission

                              ; 7.Remove PC from uC Port A

                              ; 8.Remove jumper from programming mode.

                              ;   Engines will be set to full

 

;**************************************************

; check sensor section

;**************************************************

 

     movfw   PORTB            ; check sensors

     andlw   0x3E             ; select bits 1-5 for the sensor

     movwf   sensor           ; save the byte in 'sensor'

 

     incf    sensor,1         ; +1 -1 = 0 ?

     decfsz  sensor,1         ; skip if zero - no signal on any sensor

     call    set_sensor_alt   ; not zero: save actual state

     incf    sensor,1         ; +1 -1 = 0 ?

     decfsz  sensor,1         ; skip if zero - no signal on any sensor

     goto    uralttest

     call    set_sensor_uralt ; zero: save previous state

 

uralttest:

     movfw   sensor

     subwf   sensor_uralt,0

     movwf   temp

     incf    temp,1

     decfsz  temp,1           ; if state changed save old previous state

     call    set_sensor_ururalt

     call    Zaehle           ; increase counters, switch engine controls

     BTFSC   sensor,1         ; no signal on sensor 1

     goto    S1IS             ; signal on sensor 1

     BTFSC   sensor,2         ; no signal on sensor 2

     goto    S2IS             ; signal on sensor 2

     BTFSC   sensor,3         ; no signal on sensor 3

     goto    S3IS             ; signal on sensor 3

     BTFSC   sensor,4         ; no signal on sensor 4

     goto    S4IS             ; signal on sensor 4

     BTFSC   sensor,5         ; no signal on sensor 5

     goto    S5IS             ; signal on sensor 5

 

     goto mainprog  ; no signal on any sensor

 

;**************************************************

 

S1IS:                         ; case sensor 1 is set

     btfsc   sensor_uralt, 2  ; old sensor was 2

     call    Motor14

     btfsc   sensor_uralt, 1  ; old sensor was 1

     call    Motor43

     goto    mainprog         ; end of case 1

 

;**************************************************

 

S2IS:                         ; case sensor 2 is set

     call    Motor24          ; default if no special event

     btfsc   sensor_uralt, 1  ; old sensor was 1

     call    Motor42

     btfss   sensor_uralt, 2  ; old sensor was 2

     goto    mainprog         ; done, old sensor wasn't 1 or 2

     call    Motor42

     btfsc   sensor_ururalt, 2; old old sensor was 2, too

     call    Motor44

     goto    mainprog         ; end of case 2

 

;**************************************************

 

S3IS:                         ; case sensor 3 is set

     btfsc   sensor_uralt, 2  ; old sensor was 2

     call    Motor43

     btfsc   sensor_ururalt, 2; old old sensor was 2

     call    Motor34

     btfsc   sensor_uralt, 4  ; old sensor was 4

     call    Motor34

     btfsc   sensor_ururalt, 4; old old sensor was 4

     call    Motor43

     btfss   sensor_uralt, 3  ; old sensor was 3

     goto    mainprog         ; done, old sensor was not 3

     btfsc   sensor_ururalt, 3; old old sensor was 3, too

     call    Motor44

     goto    mainprog         ; end of case 3

 

;**************************************************

 

S4IS:                         ; case sensor 4 is set

     call    Motor42          ; default if no special event

     btfsc   sensor_uralt, 5  ; old sensor was 5

     call    Motor24

     btfss   sensor_uralt, 4  ; old sensor was 4

     goto    mainprog         ; done, old sensor wasn't 5 or 4

     call    Motor24

     btfsc   sensor_ururalt, 4; old old sensor was 4, too

     call    Motor44

     goto    mainprog         ; end of case 4

 

;**************************************************

 

S5IS:                         ; case sensor 5 is set

     btfsc   sensor_uralt, 4  ; old sensor was 4

     call    Motor41

     btfsc   sensor_uralt, 5  ; old sensor was 5

     call    Motor34

     goto    mainprog         ; end of case 5

 

;**************************************************

 

;**************************************************

; set engine control values subroutines

; MotorXY = set engine 1 to X and engine 2 to Y

;**************************************************

 

Motor14:

     movfw   motor1_1

     movwf   takt_1

     movfw   motor2_4

     movwf   takt_2

     return

Motor43:

     movfw   motor1_4

     movwf   takt_1

     movfw   motor2_3

     movwf   takt_2

     return

Motor42:

     movfw   motor1_4

     movwf   takt_1

     movfw   motor2_2

     movwf   takt_2

     return

Motor24:

     movfw   motor1_2

     movwf   takt_1

     movfw   motor2_4

     movwf   takt_2

     return

Motor34:

     movfw   motor1_3

     movwf   takt_1

     movfw   motor2_4

     movwf   takt_2

     return

Motor41:

     movfw   motor1_4

     movwf   takt_1

     movfw   motor2_1

     movwf   takt_2

     return

Motor44:

     movfw   motor1_4

     movwf   takt_1

     movfw   motor2_4

     movwf   takt_2

     return

 

;**************************************************

; history saving subroutines

;**************************************************

 

set_sensor_alt:               ; save actual state

     movfw   sensor

     movwf   sensor_alt

     return

 

set_sensor_uralt:             ; save previous state

     movfw   sensor_alt

     movwf   sensor_uralt

     return

 

set_sensor_ururalt:           ; save old previous state

     movfw   sensor_uralt

     movwf   sensor_ururalt

     return

 

;**************************************************

 

;**************************************************

; engine clock counter subroutine

;**************************************************

 

Zaehle:

 

     incf    zaehler_1

     incf    zaehler_2

 

abfrage1:

     movfw   zaehler_1

     subwf   takt_1, 0        ; compare zaehler_1 with takt_1

     movwf   temp_1

     incf    temp_1, 1

     decfsz  temp_1           ; skip if equal -> bit off

     goto    cont1

     bcf     PORTB, 06        ; set engine 1 bit off

cont1:

     incf    zaehler_1, 1

     decfsz  zaehler_1        ; skip if zaehler_1 = 0

     goto    abfrage2

     bsf     PORTB, 06        ; if zaehler_1 = 0 then set engine 1 bit on

 

abfrage2:

     movfw   zaehler_2

     subwf   takt_2, 0        ; compare zaehler_2 with takt_2

     movwf   temp_2

     incf    temp_2, 1

     decfsz  temp_2           ; skip if equal -> bit off

     goto cont2

     bcf     PORTB, 07        ; set engine 2 bit off

cont2:

     incf    zaehler_1, 1

     decfsz  zaehler_1        ; skip if zaehler_2 = 0

     goto    fertig

     bsf     PORTB, 07        ; if zaehler_2 = 0 then set engine 2 bit on

 

fertig:

     return

 

;********************************************************************

; pc contact subroutine

;

; read engine control data from pc

; using following data transfer protocol:

; port A1 send:    _/  ready to get data  /_

; port A2 receive: _//_//_//_//_//_//_//_//_ clock 1 = incoming data ready

; port A3 receive: _**_**_**_**_**_**_**_**_ 8 bits data

;

;********************************************************************

 

pc_contact:

 

     bcf     PORTB, 06        ; engines stop while data transfer

     bcf     PORTB, 07

 

     bsf     PORTA, 01        ; A1=1. Ready to get data

     bsf     PORTA, 04

 

     call    getbyte

     movfw   data_in

     movwf   motor1_0

 

     call    getbyte

     movfw   data_in

     movwf   motor1_1

 

     call    getbyte

     movfw   data_in

     movwf   motor1_2

  

     call    getbyte

     movfw   data_in

     movwf   motor1_3

 

     call    getbyte

     movfw   data_in

     movwf   motor1_4

 

     call    getbyte

     movfw   data_in

     movwf   motor2_0

 

     call    getbyte

     movfw   data_in

     movwf   motor2_1

 

     call    getbyte

     movfw   data_in

     movwf   motor2_2

 

     call    getbyte

     movfw   data_in

     movwf   motor2_3

 

     call    getbyte

     movfw   data_in

     movwf   motor2_4

 

     bcf     PORTA, 01        ; A1=0. Send no more data

 

disconnect:

     btfsc   PORTA,0          ; portA0=0? -> jumper is removed, goto running mode

     goto    disconnect       ; portA0=1? -> jumper is still set, continue waiting

 

     bsf     PORTB, 06        ; return from programming mode with both engines full

     bsf     PORTB, 07

 

     bcf     PORTA, 04

 

     return

 

;*****************************************************************************

 

getbyte:                      ; subroutine to get one byte from pc

 

     movlw   0x08             ; prepare reading 8 bits

     movwf   bitcount         ;

 

     clrf    data_in          ; clear data_in

 

nextbit:

 

wait1:

     btfss   PORTA, 02        ; A2=1? -> bit ready to transfer, read bit

     goto    wait1            ; A2=0? -> continue waiting

 

     rlf     data_in,1        ; data_in rotate left

     btfsc   PORTA, 03

     incf    data_in,1        ; increase data_in

 

wait0:

     btfsc   PORTA, 02        ; A2=0? -> bit transfer complete

     goto    wait0            ; A2=1? -> bit transfer yet pending, continue waiting

 

 

     decfsz  bitcount,1       ; decrease bitcount. bitcount=0? -> all bits received

     goto    nextbit          ; >0? -> further bits expected

 

     return

;*****************************************************************************

 

     END                      ; directive 'end of program'

 

 

5. Künstlerische Darstellung

 

Bei Zukunftstechnologien (wie Solarautobahn, Marsfähre, Mondstadt, Fernraumschiff) gibt es dann meistens noch eine so genannte künstlerische Darstellung, damit man sich das, was noch nicht existiert, besser vorstellen kann. Unser Boot existiert zwar schon, aber bisher nur an Land. Hier haben wir es mal ins Wasser geträumt.

 

 

25.5.2011

 

Es ist ja nicht so, dass wir jetzt nichts mehr zu tun haben. Der Versuch, „mal eben“ eine Hilfsplatine mit einem einzelnen Sensorkanal aufzubauen, um beim Einstellen der Zerhackerdrehzahl nicht immer mit Abgreifklemmen in das Boot fassen zu müssen, misslingt. Irgendwo ist ein Schaltfehler, aber wir finden ihn nicht. Vielleicht liegt es auch daran, dass wir den Verstärker, der eigentlich2 mal 6 Volt braucht, mit einmal 9 V zu betreiben versuchen. Egal. Nach mehreren Stunden fruchtlosen Bemühens beschließt Herr Jäkel: Schluss! Wir brauchen das Ding nicht! Vertane Zeit.

 

8.6.2011

 

Es ist an der Zeit, das Boot ins Wasser zu kriegen. Der erste Versuch findet mit einer Fixierschale statt, die größte Wanne, die wir in der Physiksammlung auftreiben können. Natürlich ist sie viel zu klein. Wir müssen sie randvoll mit Wasser füllen, damit das Boot nicht mit den Propellern auf Grund sitzt.

 

 

Beim Anwerfen der Motoren gilt das Newton’sche Reaktionsgesetz (actio = reactio), welches da besagt, dass ein nach vorn fahrendes Boot eine entsprechende Menge Wasser nach hinten schleudert. Da die Schale randvoll ist, bedeutet das, dass rund zwei Liter hinten überschwappen. Außer der Wassermenge messen wir die Zeit, die das Boot für die paar Zentimeter bis zum anderen Schalenrand braucht. Daraus erhalten wir v = s/t = 20cm/s. Wenn das stimmt, dann wird unser Boot für die 10m beim Wettkampf eine Zeit von t = s/v = 50 Sekunden brauchen. Allerdings lässt sich eine Zeit von einer Sekunde nicht sehr genau stoppen, wenn man mit der anderen Hand den Wischlappen bedient.

 

15.6.2011

 

Neuer Versuch. Holzlatten und Plastikfolie ergeben zusammengebaut ein Schwimmbecken von zwei Meter Länge und rund 80 Liter Inhalt. Das Boot fährt, und es bleibt sogar genug Zeit, die Wirkung der Steuerung zu beurteilen. Sie steuert mit den eingestellten Parametern sehr hart.

 

 

Wir beurteilen die Einschaltzeiten der Motoren bei verschiedenen Fahrstufen anhand der Oszillogramme an den Relais und verändern die Werte, so dass das Boot weicher steuert.

 

 

Die Plastikfolie ist eine Abdeckfolie für Maler und von vornherein sehr weich. Beim ersten Versuch mit dem Becken lässt es sich noch mittels Saugheber wieder entleeren. Beim zweiten Versuch reißt die Folie. Diesmal sind 20 Liter Wasser aufzuwischen. Ansonsten können wir nichts mehr tun.

 

22.6.2011 Der Tag des Wettrennens!

 

Da der Wettbewerb auch diesmal wieder während der Kieler Woche stattfindet – sicher kein Zufall, sondern als werbewirksamer Auftritt von e.on geplant – ist die Logistik der Anreise wieder mal schwierig. Das Boot samt Zubehör (batteriebetriebene Tankstelle für Wasserstoff, Werkzeug, Kabel, Messgeräte, Laserwerfer, Stativmaterial für alle Fälle) wird am Vorabend per Auto nach Kiel gebracht (als vor dem Landeshaus noch Parkplätze frei sind), die Anreise des Personals erfolgt dann am 22. per Bahn und Bus. Als wir eintreffen, ist der Wettbewerb schon im Gange. Mehrere Teams haben Katamarane gebaut. Allerdings hat keiner davon zwei Triebwerke. Die haben sich vermutlich nicht getraut, eine einzelne Brennstoffzelle mit zwei Motoren zu belasten. Wir ja. Ist alles perfekt berechnet, mit Ohm und Kirchhoff.

 

 

Das Wetter ist extrem schlecht: Strahlender Sonnenschein und wir haben fast volles Licht auf den Sensoren. Nicht gut. Das blendet die Elektronik und das kriegt auch der 47-Ohm-Widerstand nicht weg. Das Einstellen der Drehzahl gelingt nur im Bereich von 0,2 Volt. Egal, wir tanken das Boot auf, gleich sind wir dran.

 

 

Und dann müssen wir an den Start. Der Laser lässt sich bei der Helligkeit nur schlecht justieren und zielt beim ersten Versuch zu hoch. Das Boot fährt ungesteuert, Wegstoßen von der Wand ist aber erlaubt. Im Ziel nach 22 Sekunden. Wow! Auf einer Tafel sind die Zeiten aller Teilnehmer zu lesen, unsere gegnerischen Mitbewerber sind bisher in allen Versuchen langsamer!

 

 

Wolken ziehen auf, und es wird windig. Jetzt oder nie! Die Steuerung müsste funktionieren, und wenn sie funktioniert, ist unser Boot bei Seitenwind gegenüber allen anderen im Vorteil. Zweiter Versuch. Laserhöhe stimmt. Boot fährt los. Nach drei Metern verliert es den Leitstrahl und kurvt zur Wand. Mist! Rettung durch Anstoßen. Zeit: 21 Sekunden! Wir rechnen uns noch bessere Chancen im dritten Versuch aus (bei der kurzen Fahrzeit könnten wir mit dem Treibstoff etwas verschwenderischer umgehen und so noch mehr Speed rausholen, da brauchen wir nur stärkere Gummibänder für die HASPAs), aber nebenbei erfahren wir, dass die Bedingungen geändert worden sind, es gibt nur zwei Versuche, nicht drei. Schade, da wären wir sicher unter 20 Sekunden gekommen. Aber: Alle anderen Teams haben sich im zweiten Versuch verschlechtert. Und die beste Zeit gilt!

 

 

Pause, Eis essen (es ist nämlich Kieler Woche, müssen Sie wissen, und auf der Kiellinie tobt das Leben!), Ansprachen. By the way: persönlicher Händedruck von Peter Harry Carstensen (Ab jetzt nie mehr Hände waschen)! Tja, und dann Siegerehrung. Fett, kursiv und unterstrichen:

 

Hipp, hipp, Hurra! Platz eins!

 

 

Siehe auch: 1. Korinther 9, Vers 24