Bei unserem Roboter handelt es sich um einen Zeppelin, der durch einen heliumgefüllten Ballon in der Luft gehalten wird. Eine unserer Hauptaufgaben war es, die Steuerung zu ermöglichen, welche über eine Bluetooth-Verbindung zwischen dem Arduino am Zeppelin und dem Laptop funktioniert. Auf letzterem läuft ein Processing-Programm, welches den Großteil unseres Codes ausmacht und Daten und Befehle als Key-Value-Paare an den Arduino übermittelt. Dieser wiederum leitet die Befehle an Motoren und Servos weiter. Gleichzeitig sendet der Arduino die gesammelten Daten von Ultraschallsensoren und Phototransistoren zurück an den Laptop. Erstere verwendet Processing, um Kollisionen mit Gegenständen zu vermeiden, während die Phototransistordaten es ermöglichen, den Zeppelin einer Lichtquelle folgen zu lassen.

Ein ähnliches Projekt, welches unserem als Inspiration gedient hat, ist der silent runner vom Windreiter-Projekt.

Damit ihr euch vorstellen könnt, wie das am Ende aussieht, hier ein Bild unseres Zeppelins:

Abb. 1

Unser Zeppelin besteht aus dem Ballon, der Motoraufhängung inklusive Electronic Speed Controller (ESC) mit Akkus, der Aufhängung der Finnen mit den Servos, einem Steckbrett mit Arduino und Bluetooth-Modul und den Sensoren (Phototransistoren und Ulltraschalldistanzsensoren).

Die größte unserer Aufgaben war die Steuerung unseres Zeppelin über Bluetooth. Durch das Füllen mit Helium wurde das Problem des zum Fliegen bringen an sich umgangen, welches wir zum Beispiel bei einer anderen Art von Drohne gehabt hätten, aber die Steuerung ist notwendig, damit der Zeppelin nicht einfach nur unter der Decke des Raumes hängt. Die Steuerung teilt sich in mehrere Bereiche auf: das Ansteuern von Motor, ESC und der Servos, sowie die Verbindung dieser mit dem Propeller und den Steuerflossen.

Beim Einfüllen des Heliums stellte sich noch ein weiteres Problem heraus: zwar flog der Zeppelin, aber die Aufhängung der Flossen war deutlich schwerer als die Vorderseite, was zu einem Ungleichgewicht führte, gegen das man schwer gegensteuern konnte. Zuerst haben wir versucht, dies mit einem Gegengewicht auszugleichen, mussten aber feststellen, dass der Zeppelin dann zu schwer war zum fliegen. Deswegen waren wir gezwungen, das Steckbrett mit Arduino und allen Kabeln weiter nach vorne umzuordnen, um den Zeppelin in eine senkrechte Lage zu bringen.

Ein weiterer Punkt, den es zu lösen galt, war die Befestigung der Mechanik am Ballon. Dies haben wir fast ausschließlich mit Gaffa Tape gelöst, was unserem Roboter den Namen „Gaffelin“ eingebracht hat, der auch auf der Seite des Ballons zu sehen ist.

An der Spitze des Ballons sitzen zwei Ultraschallsensoren und drei Phototransistoren. Erstere sollen eigenständig die Entfernung des Zeppelins von einem Hindernis feststellen und im Zweifel ausweichen bzw. den Motor stoppen, letztere sollen es ermöglichen, den Zeppelin Licht folgen zu lassen.

Als letztes haben wir uns vorgenommen, die Werte in Diagrammen grafisch darzustellen, Winkel der Steuerflossen und Beschleunigung des Motors in Kreuz-, Sensorwerte in Liniendiagrammen und den Akkustand wie er auch bei Smartphones angezeigt wird.

Bewusst ausgeklammert haben wir aus Zeitgründen die Implementierung einer Sprachsteuerung und die eigenständige Orientierung des Zeppelins im Raum, sowie die bereits in der Projektplanung erwähnte autonome Ansteuerung einer Ladestation und die Bildverarbeitung zur 3D-Modelierung des Raums.

Abb. 2

Obwohl wir das Windreiter-Projekt als Vorlage hatten, konnten wir die Maße aus deren Dokumentation nicht eins zu eins übernehmen, da wir beispielsweise eine andere Ballongröße hatten. Das Projektlabor verfügte derzeit noch nicht über einen eigenen 3D-Drucker, sodass Zugriff auf einen solchen schwierig war. Um deshalb mit möglichst wenigen Fehlversuchen – denn diese hätten uns im Zweifel viel Zeit gekostet – die Teile zu drucken, die wir für die Aufhängung der Finnen und des Propellers brauchten, erstellten wir also ein 3D-Modell des Zeppelin im Programm Fusion 360. So konnten wir die genauen Maße errechnen und schließlich die benötigten Teile drucken lassen, welche auch alle passten.

Die Finnen aus Depron-Platten wurden zugeschnitten und an CFK-Stäben befestigt, welche wiederum durch Löcher in der Aufhängung der Finnen geschoben werden konnten. Das Ganze wurde mit Gaffa Tape gesichert.

Abb. 3

Auch an der Aufhängung des Propellers wurden CFK-Stäbe angebracht.

Abb. 4

Dieser Schritt war sehr wichtig im Bau unseres Zeppelin, hatte jedoch eine einfache Lösung. Breadbord und Akkus wurden mit aufklebbaren Klettverschlüssen am Ballon befestigt, nahezu alle anderen Teile und Kabel mit Gaffa Tape.

Da das Labor nicht den passenden brushless Motor für unseren Zeppelin hatte, mussten wir diesen Online bei eBay bestellen. Das musste außerdem sehr schnell geschehen, weil der Motor aus China verschickt wurde. Die Auswahl des Motors war auch keine einfache. Denn wir hatten einen Beispielmotor aus dem Windreiter-Projekt, doch konnte man diesen nicht mehr bestellen. Deswegen haben wir einen ähnlichen gesucht, der die Anforderungen erfüllt. Eine davon war zunächst das Gewicht. Der Motor musste sehr leicht sein, damit wir kein Problem mit dem Gesamtgewicht des Zeppelin haben. Außerdem musste beim Motorkauf auf den Schub geachtet werden, und damit zusammenhängend die Umdrehungen des Motors. Damit unser Motor auch mit dem ESC zusammenpasst musste auch darauf geachtet werden, dass der Motor mit „2s“ Spannung versorgt wird. Das „2s“ steht bei RC Fahrzeugen für die Anzahl an Akkus. Wenn nur ein Akku angeschlossen wird spricht man somit von „1s“, bei zwei Akkus von „2s“, und so weiter. Hierbei ist es sehr wichtig, dass die Akkus in Reihe geschaltet werden, um die Spannung der angeschlossenen Akkus zu addieren. Um die tatsächlich anliegende Spannung unterschiedlicher Akkus besser darzustellen hier eine Tabelle.

Der ESC ist das Herzstück der Stromversorgung. ESC steht für Electronic Speed Controller und wie der Name sagt, ist es die Geschwindigkeitsregelung für den brushless Motor. An den ESC werden die Akkus (in unserem Fall 2s) angeschlossen. Nun wird die Spannung zunächst in 5V umgewandelt und an den Arduino weitergegeben. Wenn dieser über die Signalleitung ein Signal mit dem Wert zwischen 0-1028 sendet, wird der Strom der Akkus außerdem an den Motor weitergegeben und der Motor beginnt sich zu drehen.

Die Servos haben wir einfach an die Arduino Pins 9 und 10 angeschlossen. Um bei der Stromversorgung Kabel zu sparen, haben wir die Positiven und Negativen der Servos zusammengelötet und dann an den Arduino angeschlossen.

Die Kommunikation wollten wir erst über WLAN erfolgen lassen, sind dann aber auf Bluetooth umgestiegen, die Umstellung der seriellen Kommunikation von USB auf Bluetooth keine größeren Anpassungen erfordert.

In Processing haben wir eine Klasse angelegt, die für das Senden und Empfangen von Daten verantwortlich ist. Dabei hat jeder Sensor und Aktuator einen bestimmten key, in Form einer Zahl, die ihm zugeordnet wird und mit welcher jeweils erkannt werden kann, woher der übergebene Wert stammt. So kann es nicht vorkommen, dass beispielsweise ein Wert der Ultraschallsensoren mit dem eines Phototransistors verwechselt wird. Alle Daten werden in der Form {key:value}[Zeilenumbruch] übertragen. Abgesehen von den Sensoren und Aktuatoren gibt es auch keys zur Übertragung von Zeitstempeln, Fehlern und zum Debuggen.

Wir haben unseren Code so aufgeteilt, dass der Großteil auf Processing läuft. Dies hat den Vorteil, dass der Arduino nicht an die Grenzen seiner Speicherkapazität kommt. Allerdings ist der Arduino so auch abhängig von der Bluetoothverbindung mit dem Computer und Processing, sodass er nicht eigenständig betrieben werden kann, wie es bei den meisten anderen Robotern des Projektlabors der Fall ist.

Die manuelle Steuerung erfolgt in unseren Tests über einen (Xbox-)Gamecontroller, der an den Computer angeschlossen wird. Ebenfalls ist es möglich, auf der normalen Laptoptastatur die w Taste für Motorschub, a für links und d für rechts zu nutzen, sowie ↑ und ↓ für die dementsprechende Richtung. Dabei muss der Controller jedoch trotzdem an den Computer angeschlossen sein. Steht kein Controller zur Verfügung, muss der Code dementsprechend geändert werden.

Hierfür sind an der Spitze des Zeppelins drei Phototransistoren angebracht, die über Kabel mit dem Arduino verbunden sind. Zwei von ihnen zeigen jeweils nach links und rechts, der dritte nach unten.

Abb. 2

Vom Arduino werden die Daten der Sensoren an Processing auf dem Computer weitergeleitet, wo sie verglichen werden. Ist der Wert des unteren PT um eine bestimmte Toleranz höher als die beiden Oberen, wird auf die entsprechende Steuerfunktion zugegriffen und die Servos bewegen die Flossen so, dass der Zeppelin nach unten fliegt.

Sendet einer der oberen Phototransistoren einen höheren Wert als der Untere, wird geprüft, ob dieser um eine bestimmte Toleranz höher ist als der rechte, bzw. linke PT. Ist dies der Fall wird wieder auf eine Steuerfunktion zugegriffen, die den Zeppelin nach links oder rechts fliegen lässt.

Dies erfolgt komplett autonom, ohne manuelle Steuerung. Dabei wird durch Ultraschallsensoren eine Kollision vermieden.

In folgendem Video haben wir die Kollisionsvermeidung ausgeschaltet, da das Handy zu nah war und der Zeppelin sonst nicht geflogen wäre:

Am vorderen Ende des Zeppelin befinden sich zwei Ultraschallsensoren, die über Kabel mit dem Arduino verbunden sind. Sie senden durchgehend Werte, die der Arduino über Bluetooth an Processing weitergibt, wo der Abstand des rechten und des linken Ultraschallsensors vom nächsten Hindernis verglichen wird. Sinkt einer der Werte unter eine festgelegte Schwelle, d.h. kommt ein Gegenstand zu nahe, wird auf die zuvor ensprechende Steuerfunktion zugegriffen und der Zeppelin in die jeweils entgegengesetzte Richtung gelenkt, begleitet von der Nachricht „Eisberg voraus“.

Die vom Arduino empfangenen Daten werden in Processing in Arrays gespeichert, die sich ständig aktualisieren. Auf diese greift die Klasse des Kreuzdiagramms zu, um Servowinkel und Schub des Motors darzustellen. Obwohl wir keine Vorlage hierfür hatten, ließ es sich nach einigem Ausprobieren gut umsetzen.

Für das Liniendiagramm haben wir zuerst ebenfalls versucht, eine eigene Klasse zu schreiben, die auch auf die gespeicherten Arrays zugreifen sollte. In einer simpleren Umgebung getrennt von unserem restlichen Code hat dies auch funktioniert, allerdings gab es Probleme beim Umformen in eine Klasse und bei der Eingliederung in den restlichen Code. Wir haben festgestellt, dass die Umsetzung zu aufwendig geworden wäre und verwenden deshalb nun die bereits existierende Library grafica.

Für das Darstellen des Akkustandes verwenden wir ein einfaches Rechteck, welches mit einem weiteren, farbigen Rechteck gefüllt ist, das den Akkustand darstellt. Es ist angelehnt an das entsprechende Symbol bei Smartphones oder Computern. Die Akkuspannung berechnen wir mit folgender Formel:

U_in = (U_out * (R₁+R₂)) / R₂

wobei unsere Widerstände jeweils 22kOhm haben. V_out wird an einem analogen Pin gemessen.

Wenn unser Programm läuft, sieht die Processing-Oberfläche insgesamt folgendermaßen aus:

Abb. 6

Abb. 7

(Was leistet die entwickelte Lösung und woran scheitert sie?)

Unser Zeppelin kann alles, was wir in der Projektplanung beschlossen haben, das er können sollte. Zwischen dem Arduino und einem Computer mit Processing besteht eine Bluetoothverbindung, über welche Befehle und Daten gesendet werden können. Eine Echtzeitsteuerung ist möglich, entweder mit der Tastatur oder einem Controller; der Großteil des Codes liegt in Processing, wodurch der Arduino nicht überfordert ist. Mithilfe der Ultraschallsensoren können Hindernisse erkannt werden und wenn diese zu nahe kommen, weicht der Zeppelin aus oder der Motor wird gedrosselt, um eine Kollision zu vermeiden. Lichtfolgen funktioniert, muss jedoch in einem abgedunkelten Raum erfolgen, da sonst das Tageslicht stärker ist als die Lichtquelle, der eigentlich gefolgt werden soll.

Da ein Heliumballon von sich aus fliegt, mussten wir uns um das Fliegen selbst nicht so viele Gedanken machen. Allerdings gab es Schwierigkeiten mit unserer Heliumflasche, die einen zu geringen Druck hatte und deshalb den Ballon nicht ausreichend füllen konnte. Das wurde allerdings mit einer weiteren Heliumflasche behoben. Übrig blieb das Problem der Gewichtsverteilung, welches wir lösten indem wir das Breadboard weiter nach vorne an den Ballon klebten. Mit einem Stift glichen wir den Rest des Ungleichgewichts aus. Während ohne Akkus der Zeppelin leicht genug ist um an die Decke zu steigen, sinkt er mit ihnen langsam nach unten, so wie es im Windreiterprojekt als optimal beschrieben wird. Läuft der Motor, kann man gegensteuern und den Zeppelin so in der Luft halten; verliert man aus irgendeinem Grund die Kontrolle, z.B. bewegt sich der Zeppelin außerhalb der Reichweite der Bluetoothverbindung, kommt er selbstständig zurück zum Boden und fliegt nicht davon.

Wir haben also alle Must-haves und Should-haves unserer Projektplanung erfüllt. Zu den Nice-to-haves sind wir leider aus Zeitgründen nicht gekommen.

Trotzdem gibt es natürlich auch negative Aspekte. Abgesehen von den im nächsten Punkt genannten Verbesserungsmöglichkeiten, hat unser Projekt im Gegensatz zu anderen den Nachteil, dass der Arduino immer eine Verbindung zum Computer braucht, damit der Zeppelin funktionieren kann. Auch die Füllung des Ballons ist ein Problem, da das Helium langsam entweicht und es eine komplette Füllung braucht, damit der Zeppelin fliegen kann. Diese Punkte waren jedoch von vornherein klar und wurden von uns in Kauf genommen, damit wir den ersten fliegenden Roboter des Projektlabors bauen konnten:

Was uns bei unseren Tests am meisten negativ beeinflusst hat, war die Laufzeit der Akkus, die wir verwendet haben. Wir konnten jeweils nur ein paar Minuten (höchstens) fliegen, bevor sie nicht mehr genug Spannung erzeugen konnten, um den Motor zu betreiben. Schon wenn unsere Anzeige 90 Prozent Akkustand anzeigte, mussten wir uns darauf vorbereiten, dass die Akkus gleich aufgeben würden. Danach mussten sie immer ein paar Minuten laden. Dies hat das Testen sehr in die Länge gezogen, da wir immer wieder warten mussten. Es hat sich allerdings bewehrt, die Akkus mit Klettverschluss am Zeppelin zu befestigen, da uns dies ermöglicht hat, sie mit minimalem Aufwand anzubringen und wieder zu entfernen. Die Lösung wäre, Akkus mit mehr als 500mAh zu verwenden. Allerdings haben wir festgestellt, dass wir an der Grenze des tragbaren Gewicht des Zeppelins angekommen sind, sodass andere Akkus nicht bedeutend schwerer sein dürften als die jetzigen.

Ebenfalls gibt es wahrscheinlich bei jedem Projekt immer noch Codepassagen, die übersichtlicher oder effizienter geschrieben werden könnten. Allerdings sollte es durch die Unterteilung unseres Codes in Klassen gut möglich sein, einzelne Dinge zu verändern, ohne das Gesamtsystem negativ zu beeinflussen.

Was man auch noch verbessern kann, ist die Übersichtlichkeit. Durch die vielen Sensoren und Aktuatoren gibt es entsprechend viele Kabel, welche alle auf dem Breadboard zusammenkommen. Teilweise haben wir diese schon beschriftet, teilweise ist vom Pin, an welchem sie mit dem Arduino verbunden sind, ersichtlich, worum es sich handelt. Trotzdem würde es einen schnelleren Überblick ermöglichen, wenn man alle Kabel entsprechend beschriften würde.

Auch ästhetisch gibt es Verbesserungspotential. Dadurch, dass wir wegen der Gewichtsverteilung kurzfristig die Anordnung der Elektronik am Zeppelin verändern mussten, gibt es an der Vorderseite einen Überschuss an Kabeln, die wir aus Zeitgründen einfach nur mit mehr Gaffa Tape am Ballon befestigt haben. Hierfür gäbe es sicherlich schönere Lösungen, welche gleichzeitig auch zur besseren Übersicht beitragen könnten.

Ebenfalls, falls in Zukunft eine andere Gruppe auf unserem Projekt aufbauend arbeiten will, empfehlen wir genügend Helium zu beschaffen. Wir hatten 400l zur Verfügung, was nach Datenblatt des Ballons sogar mehr war, als benötigt. Allerdings war mit 45bar der Druck in der Flasche zu gering, um den Ballon ausreichend zu füllen und zum Fliegen zu bringen. Wir hatten Glück, dass uns von einem freundlichen Menschen aus einem TU-Labor eine Flasche Helium mit deutlich mehr Druck überlassen wurde.

Bei unserem Zeppelin besteht noch großes Entwicklungspotential. Abgesehen von der Verbesserung der bereits genannten Punkte könnte man mithilfe der bereits vorhandenen Phototransistoren Lichtsignale erkennen und bestimmte Befehle festlegen, die bei einem jeweiligen Signal ausgeführt werden.

Da wir festgestellt haben, dass das Traggewicht des Ballons bereits fast an seiner Grenze ist, kann man nicht viel mehr am Zeppelin befestigen, ohne auf andere Sachen zu verzichten, aber anstatt zum Beispiel eine Kamera am Ballon zu befestigen, könnte man eine Kamera im Raum aufstellen, die eine selbstständige Orientierung des Zeppelin in besagtem Raum ermöglicht.

Auch könnte man das gesamte Programm nutzerfreundlicher gestalten, eine App fürs Smartphone schreiben, und das Erkennen von Sprachbefehlen ermöglichen.

Unser kompletter, lauffähiger Programmcode befindet sich hier:

Source-Code

Ebenfalls stellen wir das 3D-Model zur Verfügung, welches wir für das Drucken der Teile erstellt haben:

Fusion 360 Dateien