Wenn irgendwo auf der Welt die ebenso seltsame wie bedrohte Fauna und Flora der Tiefsee nur wenige Meilen vor einer Küste liegt, ist meist eine Meeresforschungsstation nicht weit. Ein Besuch im kalifornischen Moss Landing, wo Wissenschaftler Linux-gesteuerte Tauchroboter entwickeln und auf Mission schicken.
Rund zwei Autostunden südlich von San Francisco liegt das kalifornische Küstenstädtchen Monterey, vielen bekannt aus John Steinbecks “Die Straße der Ölsardinen”. Nicht weit vor der Halbinsel ist der Pazifik ungewöhnlich tief, kalt und besonders nährstoff- und artenreich. Bei Moss Landing in der Monterey Bay befindet sich der Eingang zu einer mehrere Tausend Meter tiefen Unterwasserschlucht, dem Monterey Canyon (Abbildung 1). Auf dem Weg in diese Tiefe präsentiert sich Meeresforschern eines der artenreichsten Gewässer der Welt, viele Spezies sind noch unerforscht.
Dass die Standortwahl für ein Meeresforschungsinstitut gerade auf Moss Landing fiel, ist somit kein Zufall. Das Monterey Bay Aquarium Research Institute (MB-ARI, [1]) hat David Packard, einer der beiden HP-Firmengründer, 1987 gegründet. Drei Jahre zuvor und ebenfalls dank einer Spende vom Packard entstand in den Gebäuden einer ehemaligen Ölsardinen-Fabrik das Monterey Bay Aquarium. Das MBA ist in den USA nicht das größte, gilt aber als eines der besten Aquarien weltweit. Formal sind MBARI und das Aquarium voneinander unabhängige Institutionen, sie kooperieren jedoch eng.
Die gut 200 Mitarbeiter des MBARI decken interdisziplinär die Gebiete Meeresbiologie, -geologie, -chemie und Ozeanografie ab. Neben wissenschaftlichen Erkenntnissen produziert das Institut – ganz im Sinne von David Packard – auch Forschungstools und -verfahren sowie Technik für Meeresbeobachtungsstationen jedweder Art. So betreibt die Einrichtung mehrere Schiffe, ROVs (Remote Operated Vehicle), AUVs (Autonomous Underwater Vehicle) und ein weltweit einzigartiges Unterwasserlabor (ESP, Environmental Sample Processor).
ROVs sind unbemannte Unterwasserlabore von der Größe eines Kleinwagens, die per Kabel mit ihrem Mutterschiff verbunden sind und von ihm gesteuert Proben jedweder Art entnehmen, Video-Aufnahmen und Sensordaten liefern, Experimente durchführen und Unterwasserstationen warten (Abbildung 2).
AUVs sind autonome Tauchroboter, welche die Daten ihrer Sensoren sammeln und damit nach Wochen zu einem Ausgangspunkt zurückkehren. AUVs sind deutlich kleiner als ROVs und ähneln Torpedos, viele werden von Propellern angetrieben, können mehrere Tausend Seemeilen zurücklegen (Long Range) und einige Hundert Meter abtauchen (Abbildung 3). Es gibt aber auch AUVs, die in mehrere Tausend Meter Tiefe vordringen. So dokumentierte 2011 ein MBARI-AUV den gigantischen Unterwasser-Lavafluss eines Vulkanausbruchs vor der Küste Oregons.
Environmental Sample Processor
Weder ein ROV noch ein AUV ist MBARIs Environmental Sample Processor (ESP, [2], [3], [4]), sondern ein Unterwasserlabor, das keinerlei Antrieb zur Fortbewegung besitzt. Denn die Wissenschaftler verankern das Labor für den Einsatz kurz über dem Meeresboden und führen ein Kabel zu einer Boje, die ein Funkmodem samt Antenne trägt. Die Boje baut eine Datenverbindung zum Land auf und wird von dort ferngesteuert.
Das ESP entnimmt mikrobiologische Wasserproben und unterzieht sie DNA- und RNA-Tests. Eine sehr typische Aufgabe besteht in der Bestimmung und Quantifizierung von Toxinen noch unter Wasser. Blühende Algen etwa setzen in zunehmender Menge Gifte frei, die für Menschen und das Unterwasser-Habitat gleichermaßen abträglich sind. Das Innenleben eines ESP zeigt Abbildung 4.
Für die Entnahme und Analyse von Wasserproben verfügt das Labor über elektrisch angesteuerte Mechaniken in Form von Wasseransaugpumpen, Aktoren und eines Drehkarussells. Zu Beginn saugt das ESP Wasser an und drückt es durch einen Filter, um die Mikroorganismen darin zu isolieren. Dies geschieht in so genannten Pucks, kleinen runden Metallbehältern, die zwischen 0,5 und 4 Milliliter Flüssigkeit fassen.
Danach versetzt das Labor die Proben mit Chemikalien oder erhitzt sie, um die Zellen aufzubrechen und deren DNA und RNA zu extrahieren. Anschließend transportiert eine Vorrichtung die Pucks zu einer CCD-Kamera, die ein Lumineszenz-Muster aufnimmt. Die Digitalbilder gehen per Datenmodem an das Labor an Land zur Auswertung. Das ESP behält die Proben zudem in seinem Inneren bis zum Ende der Mission.
Jedes Watt zählt
Das ESP ist auf einen möglichst geringen Energieverbrauch hin optimiert. Das gilt nicht nur für die Elektromechanik-Komponenten und Motoren, sondern auch für die Embedded-Rechner. Dort setzen die MBARI-Entwickler auf die ARM-Architektur. Auf den am MBARI entwickelten Motherboards arbeiten Wandler, die aus den 10 bis 16 Volt ESP-Bordspannung rechnerfreundliche 5 Volt und 3,3 Volt machen.
Die PC/104-Schnittstelle des Mainboards nimmt ein handelsübliches TS-7200-Board von Technologic Systems auf samt ARM9-CPU, 32 MByte RAM, 16 MByte Flash. Die Ingenieure sind gerade dabei, auch dieses Board durch eine Eigenentwicklung abzulösen. Auf der neuen Platine wird eine NXP-LPC3141-CPU sitzen, die mancher aus früheren Apple-Mobilgeräten kennt, 64 MByte RAM sowie 256 MByte NAND-Flash.
Am USB-Interface arbeitet eine Kamera. Das Motherboard hat sieben RS-232-Ports, an denen das Funkmodem, Analysemodule und so genannte kontextuelle Sensoren hängen. Dazu zählen Fluorometer zur Analyse organischer Stoffe sowie CTD-Instrumente (Conductivity, Temperature, Depth), die neben Temperatur und Tiefe den Salzgehalt über die Leitfähigkeit des Wassers messen.
Rechner und Steuerungselektronik verbindet ein I2C-Bus mit 100 KBit/s. Die Servosteuerungen für die Pumpen und Manipulatoren sind mit Microcontrollern der TI-MSP430-Familie bestückt, die genug Intelligenz mitbringen, um die Haupt-CPU von Low-Level-Steuerungsfunktionen zu entlasten. Die fünf Servocontroller im ESP verbrauchen zusammen knapp 2 Watt. (Die Ingenieure vor Ort berichten, dass das MBARI künftig auf Cortex-M3-basierte ST32L152-Controller umstellen wird, weil deren GNU-Tool-Unterstützung besser sei.)
Um transiente Übertragungsfehler zu erkennen, haben die MBARI-Ingenieure das Low-Level-I2C-Busprotokoll um eine Prüfsumme und ein ACK-Bit für alle Bus-Nachrichten erweitert. Um weiterhin mit I2C-Bus-Standardkomponenten kommunizieren zu können, lässt sich die Erweiterung wieder abschalten.
Implementierung mit Ruby
Anders als bei der ersten ESP-Generation arbeitet der aktuelle 2G ESP nicht mehr mit einem proprietären Realtime-Betriebssystem, sondern mit Linux. MBARI-Ingenieur Brent Roman hat die gerade mal 4 MByte große Distribution mit Hilfe von LTIB [5] gebaut. Die Chance für das Redesign bot sich, weil wie erwähnt separate Microcontroller die zeitkritische Servosteuerung erledigen.
Die in C++ geschriebene Userland-Software für das 1G ESP und den Interpreter für die ESP-Makrosprache, deren Funktionen die Analyseabläufe steuern, hätten die Entwickler für das 2G anpassen und erweitern müssen. Eine Evaluation ergab, dass eine moderne Neu-Implementierung günstiger ist. Die Wahl fiel auf Ruby, weil der Benutzer Steuerkommandos für die Analysen sowohl in eigenen Skripten verwenden wie auch interaktiv eingeben kann. Außerdem ist Ruby frei von Interpunktion und bei Whitespaces und Einrück-Regeln nicht pingelig.
Bei der Neu-Implementierung wurde das Gros der High-Level-ESP-Kommandos als Methodenaufrufe für definierte Ruby-Objekte implementiert. Endbenutzer kodieren daher auf einfache Weise Versuchsabläufe oder geben sie interaktiv ein, ohne viel von objektorientierter Programmierung verstehen zu müssen. Listing 1 zeigt ein Beispiel, entnommen von [6].
Listing 1
Beispiel für ESP-Kommandos
01 # Lower the puck elevator in the carousel 02 Elevator down 03 # Rotate the carousel so the elevator will 04 # lift pucks in tube #3 05 Carousel.to 3 06 #Close the collection clamp 07 CC. close
Viele Patches
Das ESP-Projekt verwandte eine ältere Ruby-1.8-Version, die laut Brent Roman unter Stabilitätsproblemen beim Einsatz von Continuations für Checkpoint-Threads litt. Seine in [7] beschriebenen und teilweise upstream gegangen Patches beheben diese Crash-Neigung und verringern zudem den Speicherverbrauch in Multithreaded-Skripten.
Außer Ruby bringt das Mini-Linux folgende Software mit:
- PPP des Samba-Projekts (wegen Race Conditions gepatcht)
- MBARI-Busybox-Version (gepatcht wegen Backports einiger Kommandos aus neueren Busybox-Versionen)
- U-Boot, Libusb, Libtiff
Die erwähnten Patches hat Brent Roman selbst entwickelt.
Foce misst die CO2-Absorption
Das Free Ocean Carbon Enrichment [8] ist ein weiteres interessantes MBARI-Projekt. Es untersucht in einem kontrollierten Experiment den Verlauf der CO2-Anreicherung des Meeres in Abhängigkeit von den CO2-Werten der darüber befindlichen Luftsäule. Der Foce-Versuchsaufbau besteht im Wesentlichen aus einem unten offenen Gefäß, das Luft enthält und direkt auf den Meeresboden aufgesetzt wird. So lässt sich die CO2-Absorption des Meeresbodens untersuchen. Foce-Ergebnisse liegen bereits aus der Antarktis, dem Mittelmeer, Australien und der Monterey Bay vor.
Die Software muss die Messwerte erfassen, wobei die einfachste Foce-Konfiguration zwei Knoten benutzt. Das entspricht einer Größenordnung von 15 Devices mit mehr als 100 Datenkanälen pro Knoten. Fürs Online-Datastreaming setzt Foce auf Zero MQ [9], eine unter der LGPL stehende Bibliothek für asynchrones High-Performance-Messaging.
Als Distribution tut Ångström-Linux [10] Dienst, das sich durch einen sehr schlanken Kernel ohne ladbare Module auszeichnet. Da hier das ARM-Board Beagle Bone ([11], [12]) den Single Board Computer stellt, ist Ångström vorinstalliert.
Tools beschleunigen die Entwicklung
Zum Cross-Entwickeln der Userland-Software benutzen die kalifornischen Meeresforscher die Embedded-Frameworks Yocto [13], Open Embedded [14] und Bitbake [15] in einer Ubuntu-12.04-VM, die auf einem Mac-OS-Host läuft. Die Yocto-Ångström-Kombination gefiel im MBARI wegen der guten Abstimmung beider Projekte, denn Yocto stellt eine komplette Embedded-Entwicklungsumgebung bereit, einschließlich Emulator, Debugger und Application Toolkit Generator. Dadurch gelingt es, im Projektverlauf eigene Anpassungen und Optimierungen mitzuführen.
Außer auf ARM funktioniert Yocto-Software auch auf Power PC, Mips, x86 und x86-64, wobei das jeweilige Board Support Package (BSP) Unterstützung leistet. Yocto bietet zudem ein Eclipse-Plugin und ein GUI für das Buildsystem namens Hob. Mit Yocto gleichsam verheiratet ist Bitbake [15], das seinerseits eine wesentliche Grundlage des Open-Embedded-Projekts darstellt. Bitbake ist eine Distributions-unabhängige Build-Engine mit Fokus auf Distributionen und Packages für Embedded Linux. Das Open-Embedded- und das Yocto-Projekt pflegen das Paket gemeinsam.
Open Embedded [14] schließlich ist als Crosscompile-Umgebung ein Buildframework für Embedded Linux. Es läuft auf allen Linux-Distributionen, ist leicht anpassbar und besitzt Tools, die bootfähige Distributionen nach Code- oder Konfigurationsänderungen im Handumdrehen erzeugen. Gerade dies nennen die MBARI-Entwickler als großen Vorteil, zumal die Entwicklungsphase eines Embedded-Systems reich an Änderungen ist.
Um Linux-Anwender und -Freunde unter Forschern in vielen Diziplinen zu treffen, muss eigentlich niemand so weit reisen. Das Linux-Magazin hat es trotzdem getan und stieß am Ziel auf fabelhafte Welten: unter dem Meeresspiegel genauso wie an Land.
Infos
- MBARI: http://www.mbari.org/about/
- Aktueller ESP: http://www.mbari.org/ESP/esp_2G.htm
- ESP-Geschichte: http://www.mbari.org/ESP/esp_history.htm
- ESP-Technik: http://www.mbari.org/ESP/esp_technology.htm
- LTIB: http://savannah.nognu.org/projects/ltib
- “Controlling a Robotic Marine Environmental Sampler with the Ruby Scripting Language”: http://jla.sagepub.com/content/12/1/56.full.pdf
- Ruby-Patches: https://sites.google.com/site/brentsrubypatches/
- Foce: http://www.mbari.org/highCO2/,http://www.xfoce.org
- Zero MQ: http://zeromq.org
- Ångström Linux: http://www.angstrom-distribution.org
- Beagle Board: http://beagleboard.org
- Maximilian Batz , Markus Feilner, “Einplatinen-Rechner der Raspberry-Klasse im Vergleich”: Linux-Magazin 01/15, S. 28
- Yocto Project: https://www.yoctoproject.org
- Open Embedded: http://www.openembedded.org/wiki/Main_Page
- Bitbake: http://www.openembedded.org/wiki/BitBake_%28user%29










