ein Projekt von Laura Grossner und Lena Sparberg

Wer kennt das nicht: Sich voll bepackt den ganzen Tag durch die Uni zu schleppen? Rückenschmerzen vom schweren Rucksack? Keine Hand frei für die persönliche Begrüßung des Profs? Immer häufiger hat man den Wunsch, von diesem Ballast im Alltag befreit zu werden, leicht durch das Leben zu gehen und trotzdem alles parat zu haben… So entstand die Idee zum BagBuddy: ein kleiner, fahrender und Tasche tragender Roboter, der mir auf meinem Weg folgt und mich durch meinen (Uni-)Tag begleitet.

Ziel des BagBuddys ist es, mich zu erkennen und mir mit meiner Tasche folgen zu können, Hindernissen auszuweichen und im richtigen Abstand zu mir fahren zu können…

1. Wie soll der Roboter aufgebaut sein?
2. Wie erkennt mich der BagBuddy?
3. Wie bekommen wir den Roboter zum Fahren?
4. Wie kann er Hindernissen ausweichen und im richtigen Abstand zu mir fahren?

Der Aufbau des Roboters orientiert sich an seiner Funktion: Um fahren zu können benötigt er Räder, einen Motor, der diese betreibt, eine Antenne, die WLAN-Signale messen kann, und eine Steuerung des Gesamtssystems: den Rasperry Pi und Arduino. Über den Arduino, einem Microcontroller, wird beispielsweise der Servo, auf dem die Antenne montiert ist, betrieben. Der Rasperry Pi, ein Einplatinencomputer, ersetzt den Laptop: Über ihn wird das Processing-Programm ausgeführt und die Kommunikation mit dem Arduino organisiert.

Der Roboter benötigt mindestens zwei motorbetriebene Räder, um sich selbstständig fortbewegen zu können. Zudem braucht er eine Antenne (zum WLAN-Empfang, s. Frage 2) und schließlich die Möglichkeit, die Tasche abzustellen. So entschieden wir uns, an einer rechteckige Plattform zwei Räder mit Getriebemotoren zu montieren, eine Laufrolle anzubringen und den Arduino mit dem entsprechenden Board auf der Plattform zu befestigen. Die Kabel und Drähte werden durch Löcher in der Plattform, die aus einer Holzspanplatte besteht, von den Motoren zum Arduino geführt.

Bild 1: Roboter-Grundplattform mit Rädern, Arduino und Antenne

Auf diese Plattform wird eine zweite Plattform montiert, auf die dann die Tasche gestellt werden kann. Die Antenne wird vorne rechts befestigt. Auf der zweiten Plattform wird zudem ein Holzstab senkrecht befestigt, um an einem dort angebrachten Haken die Tasche zu befestigen und ihre Henkel einzuhängen.

Bild 2 (links) und 3 (rechts): Roboter mit beiden Plattformen und Taschen-Haken und Seitenansicht des Roboters

Damit der Roboter mir auch wirklich folgen kann, darf er natürlich nicht an einem Laptop angeschlossen sein. Dafür brauchen wir eine Alternative: den RasperryPi.

Der BagBuddy erkennt eigentlich gar nicht mich, sondern mein Smartphone! Wir haben uns für eine Erkennung per Wlan-Signal entschieden, bei der der Roboter das Signal, das von meinem Smartphone-Hotspot ausgesendet wird, empfängt und ihm folgt. Andere Möglichkeiten, die uns jedoch nicht überzeugt haben, wären die Erkennung per Infrarotmessung oder mit einer (Kinect-)Kamera gewesen. Bei der Infrarotmessung hätte die Bezugsperson einen Infrarotempfänger tragen und auf dem Roboter ein Infrarot-Sender montiert werden müssen. Der Sender könnte Strahlungen aussenden, die dann vom Empfänger empfangen werden, sodass der Roboter dorthin fährt, wo er empfangen wird. Diese Installation wäre jedoch sehr aufwendig gewesen. Zudem hätte man die Sonneneinstrahlung beachten müssen, die auch zum Teil aus Infrarotstrahlung besteht, sodass der Empfänger so präpariert hätte werden müssen, dass er nur die Strahlungen des Roboters empfängt und nicht die z.B. von der Sonne. Mit der (Kinect-)Kamera stünde der Roboter vor folgendem Problem: Die Kamera erkennt Menschen, unterscheidet diese jedoch nicht. Der Roboter würde also jedem Menschen folgen und während seiner Route einfach seine Bezugsperson wechseln, würde der Weg von einer anderen Person gekreuzt. Man könnte dies höchstens durch ein auffälliges, äußeres Erkennunsgmerkmal beheben. Da er aber nur mir folgen soll, weil er ja meine Tasche trägt, ist diese Möglichkeit für den BagBuddy nicht günstig. So entschieden wir uns für die Wlan-Signal-Erkennung. Hierfür benötigt man: einen Handy-Hotspot, eine Wlan-Antenne und eine Richtantenne zur Verbesserung und Lokalisierung des Signalempfangs. (Während der Entwicklungsphase nutzten wir jedoch anstatt des Handy-Hotspots einen anderen WLAN-Hotspot.)

Um die Aufnahme des Signals zu verbessern und die Richtung, aus der das Signal kommt, erkennen zu können, bauten wir eine Yagi-Richtantenne, die auf die Wlan-Antenne gesteckt wird. Diese Richtantenne besteht aus einem rechteckigen Styroporstück, in das in bestimmten Abständen Kupferdrähte in bestimmten Längen gesteckt wurden. Eine Anleitung zum Bau mit detaillierter Abstands- und Längenangaben findet man unter : www.heise.de/netze/artikel/Die-0-Euro-Antenne-223704.html. Der Bau der Antenne muss sehr präzise ausgeführt werden, da schon kleinste Ungenauigkeiten, z.B. bei den Abständen oder Längen der Kupferdrähte, die Messungen beeinflussen. So erfolgte auch bei uns der Bau der Antenne zweimal, doch auch mit dem erneuten Bau der Antenne konnten das Problem der Ungenauigkeit nicht vollständig behoben werden.

Bild 4 und 5: Die Yagi-Richtantenne in Seitenansicht(links) und von oben(rechts)

Zudem kommt auch, dass das WLAN-Signal durch metallene Gegenstände beeinflusst wird und die Antenne dadurch zum Teil verfälschte Signale empfängt.

Um die Wlan-Signale, die wir mit dieser Antenne empfangen können, nun auch auswerten zu können, brauchen wir ein Programm, das uns die Signalstärken ausgeben kann und anschließend den höchsten (also stärksten) Wert ermittelt, damit der Roboter dann in die Richtung, aus der der höchste Wert bzw. das stärkste Signal kam, also zu dem Smartphone/zu mir, fahren kann. Dieses schrieben wir in Processing. Um die Richtung herausfinden zu können, aus der das stärkste Signal kommt, muss die Antenne auf einem Servo montiert werden, damit die Antenne auf der horizontalen Ebene geschwenkt werden kann. Dieser wird (über Arduino) so programmiert, dass er sich ein Stück dreht, dann die Antenne eine Messung macht und der Servo sich dann um einen Winkel weiter dreht. Dieser Prozess wird solange wiederholt, bis der Servo sich (mit der Antenne) einmal um 180 Grad gedreht hat. Das Processingprogramm speichert diese Messwerte und ermittelt daraus den höchsten Wert mit dem dazugehörigen Winkel. Dieser Winkel soll dann an den weitergeleitet und an den Arduino übertragen werden, damit dieser weiss, wohin der Roboter sich drehen und anschließend hinfahren soll.

Mit der Signalstärke wird zugleich der dazugehörige Winkel ausgegeben, also der Winkel, an dem die entsprechende Signalstärke gemessen wurde. Beide Werte, also Winkel und Signalstärke, werden in einem Array gespeichert. In der im Programm darauffolgenden For-Schleife wird nun der höchste Signalmesswert ermittelt, indem jeder neue Messwert mit dem zuvor gespeicherten, letzt-höchsten Messwert verglichen wird und entweder als neuer höchster Wert gespeichert wird, wenn er höher als der vorige ist, oder „vergessen“ wird bzw. unbeachtet bleibt, wenn er niedriger ist. Bei gleichem Wert gab es (zunächst) das Problem, dass die Variable nicht überschrieben wurde, sondern unbeachtet blieb, sodass das Ergebnis verfälscht war und der Roboter in eine falsche Richtung gefahren ist.

Bild 6: schematische Darstellung des Problems

Oben geschildertes Problem lässt sich an folgendem Beispiel zeigen: Wir führten eine Reihe von Messungen durch, wobei die Entfernungen zwischen Hotspot und Roboter variierten (komplette Messreihe: diagramme), aber beispielsweise auch ein Höhenunterschied betrachtet wurde. Ziel dieser Messreihe war es, die Genauigkeit der Antenne zu erproben. Die Antenne sollte aus der Richtung, in der sich der Hotspot befindet, die stärksten bzw. höchsten Signale empfangen. Das Ergebnis war jedoch ein anderes: In einer Messung der WLAN-Signalstärke, bei der der Hotspot sechs Meter vom Roboter entfernt stand, sich jedoch auf gleicher Höhe befand, wurde, als der Servo bei dem Winkel 3 Grad stand, die Signalstärke 61 (erstmals) gemessen, wie man in dem Diagramm (Bild 7) bei Messung 1 (blau) sehen kann. Somit wird an dieser Stelle die Signalstärke 61 bei 3 Grad als größter Wert gespeichert. Nun werden auch bei 90 Grad und bei 100 Grad die gleichen, höchsten Messwerte (Signalstärke =61) gemessen. Die Variable wird jedoch nicht überschrieben, sondern der erste Wert, also der Messwert 61 beim Winkel 3 Grad, bleibt gespeichert. Somit werden alle nachfolgenden Signalstärken mit gleichem Wert nicht berücksichtigt.

Bild 7: Diagramm zur Messung der Signalstärken

Dieses Problem konnte dadurch behoben werden, dass bei mehrmaligem Auftreten des gleichen, höchsten Wert alle zunächst gespeichert werden, dann jeweils mit ihrem vorhergegangen und nachfolgenden Wert addiert werden und anschließend durch drei dividiert. Hierdurch werden die Durchschnittswerte ermittelt. An der Stelle, an der das Signal am stärksten war, müsste das jeweils vorherige und nachfolgende Signal höher sein als bei den anderen Werten, sodass hier auch der höchste Durchschnittswert errechnet wird. Also: [Signalstärke(-1) + Signalstärke + Signalstärke(+1)]/3

Zu diesem höchsten Durchschnittswert wird dann der Winkel, an dem die ursprüngliche (höchste) Signalstärke gemessen wurde, ausgegeben. Dieser Winkel wird dann an die serielle Schnittstelle weitergeleitet, an der der Winkel „ausgelesen“ wird und der Befehl zum Drehen des Roboters gegeben wird.

Die aufgetretenen „Messfehler“ bzw. Ungenauigkeiten könnten vermutlich durch eine Optimierung des Baus der Antenne verhindert werden: Mit einer endgültigen Fixierung des Styropor-Arms an der schwarzen Antenne würden Verwackelung oder Verrutschen des Arms und damit einhergehende Veränderungen oder Verfälschungen der Messwerte verhindert. Dies wurde hier jedoch nicht umgesetzt. Dass man eine Berechnung des Fehlers dadurch hätte vermeiden können, ist erst zum Ende der Projektarbeit deutlich geworden.

Für die Fortbewegung hat der BagBuddy zwei motorbetriebene Räder, die durch die Laufrolle, die auf die Bewegung der anderen beiden Räder reagiert, unterstützt werden. Die Räder und deren Getriebemotoren werden durch einen Motortreiber (https://www.pololu.com/product/777) gesteuert, der vom Arduino über die Pins RX und TX Befehle zum Bewegen der Räder bekommt.

Bild 8: Motortreiber TReX DMC mit Arduino-Anschluss (Anschlüsse an der linken Seite hier nicht relevant; bearbeitete Darstellung nach: https://www.pololu.com/picture/view/0J290)

Die Motoren werden über den Motortreiber mit Strom versorgt, wurden also jeweils an die Spannung vom Akku (also z.B. 8V) und GND am Motortreiber angeschlossen.

Bild 9: Motortreiber mit angeschlossenen Getriebemotoren 1 und 2 (bearbeitete Darstellung nach: https://www.pololu.com/picture/view/0J294 )

Der Motortreiber wiederum wird durch einen Akku mit Strom versorgt. Damit man nun die Motoren auch einsetzen kann, muss man wissen, wie weit sich die Räder drehen sollen. Hierfür werden die Encoder verwendet, die pro Radumdrehung eine bestimmte Anzhal an Signalen geben (2400, nach eigener Berechnung). Die Signalausgänge wurden an die digitalen Pins 2 und 4 für den rechten, und 3 und 5 für den linken Motor am Arduino-Board angeschlossen. So kann das Arduino-Programm die Anzahl der Encodersignale auslesen und berechnen, wie weit sich die Räder drehen sollen.

Im folgenden Schaltplan sieht man, dass der Motortreiber an den Akku mit 8V angeschlossen wird. Diese Spannung wird für das Betreiben der Motoren benötigt. Der Raspberry Pi und der Servo vertragen jedoch nur eine Spannung von maximal 5V, sodass ein Konverter zwischen Akku und Raspberry Pi bzw. Servo geschaltet wurde. Dieser Konverter regelt, nach entsprechender Einstellung, die Spannung, die vom Akku aus mit ca. 8V kommt, auf 5V herunter.

Bild 10: Schaltplan

Damit der Roboter nun weiss, wo er hinfahren soll, damit also die Motoren entsprechend gesteuert werden können, muss das stärkste Wlan-Signal bzw. der Winkel davon an den Arduino übermittelt werden, damit dieser dann die Motoren dementsprechend steuern kann. Wir schrieben also einen Algorithmus, nach dem der Winkel, an dem das stärkste Signal empfangen wurde, an den Arduino übermittelt wird und dieser den Winkel zu Motorbefehlen umrechnet. Hierzu wird aus Processing der Winkel übermittelt, in einer Variablen gespeichert und anschließend in Arduino in zwei Fälle („switch- case“) eingeordnet, entweder in „Winkel ist größer als 90 Grad“ (im Bild 11 blau gekennzeichnete Fläche) oder „Winkel ist kleiner als 90 Grad“(gelb gekennzeichnete Fläche). Der Roboter ist mit seiner rechten Kante (und seinem rechten Rad) auf 90 Grad positioniert, wie in Bild 11 zu sehen ist. Je nach Fall wird nun berechnet, ob sich der Roboter nach vorne (also nach rechts,im Bild blau) oder hinten (nach links, im Bild orange) drehen muss.

Bild 11: schematische Darstellung zum Fahralgorithmus

Um die Berechnung zu erleichtern wurde festgelegt, dass sich ausschließlich das linke Rad bei der Drehung bewegen soll. Das heißt, dass das rechte Rad an einem festen Punkt bleibt und das linke entweder nach vorne fährt, um den Roboter in einem Winkel zwischen 90 und 180 Grad zu positionieren, oder nach hinten, also rückwärts, fährt, um einen Winkel zwischen 0 und 90 Grad zu erreichen. Das rechte Rad ist also eine Drehachse, um die das linke Rad herumfährt, die rechte Kante des Roboters, an der vorne auch die Antenne montiert ist, ist maßgebend für den Winkel, d.h. sie muss in diesem Winkel positioniert werden.

Bei der Ausrichtung zu einem bestimmten Winkel stießen wir auf folgendes Problem: Woher weiß der Roboter, wann er sich weit genug gedreht hat? Hierzu gab es verschiedene Lösungsansätze:

1. Möglichkeit: Die Zeit messen: Man kann ausmessen, wie lange der Roboter braucht, um sich zu einem bestimmten Winkel zu drehen und dieses für alle anderen Winkel berechnen. Nachteil hierbei: Die Berechnung ist sehr ungenau, da die Motorbeschleunigung nicht einberechnet wird bzw. nicht zuverlässig einberechnet werden kann. Zudem verändern sich die Zeiten je nach Gewicht der zu tragenden Tasche, wobei sich eben auch die Motorbeschleunigung ändert. Daher scheidet diese Möglichkeit für den BagBuddy aus.

2. Möglichkeit: Drehung des Rades messen: Wenn ein konkreter Winkel angefahren werden soll, kann man berechnen, wie weit bzw. wie oft sich das Rad drehen muss, um diesen Winkel zu erreichen. Ein Vorteil hierbei ist, dass exakt der berechnete Winkel angefahren werden kann.

3. Möglichkeit: Sich drehen, an neuer Position WLAN messen und mit der soll-Position vergleichen: Hier könnte der Roboter sich zunächst nach Zeitberechnung drehen, dann erneut messen und anschließend gegebenenfalls die Position berichtigen. Dieses Vorgehen ist sinnvoll, wenn man die Verbindung und die korrekte Richtung sicherstellen möchte. Nachteil hierbei ist, dass der Roboter viel Zeit für die Messung benötigt. Wenn er also nicht nur einmal misst, sondern nach der Drehung nochmal, um dann eventuell den Winkel zu korrigieren, hat er keine Chance, einer sich bewegenden Person zu folgen.

Nach Abwägung der Vor- und Nachteile dieser drei Möglichkeiten entschieden wir uns für die zweite. Im Programm wird der Winkel nun wie folgt mit Hilfe der Encoder berechnet und umgerechnet: Ist der Winkel größer als 90 Grad, wird wie folgt gerechnet: -(1400/27)*(winkel-90). Das Ergebnis hierbei ist eine Anzahl von Encoder-Signalen, die ereicht werden muss, um im entsprechenden Winkel angelangt zu sein. Das linke Rad soll sich also solange drehen, bis die berechnete Encodersignalzahl mit der umgesetzten übereinstimmt. Gleiches geschieht bei einem Winkel, der kleiner als 90 Grad ist, mit folgender Berechnung: (1400/27)*(90-winkel).

Wie man zu dieser Berechnung kommt, kann man in folgender Aufstellung sehen:

Folgende Variablen werden eingeführt:

B = Breite des Roboters = Abstand der Räder zueinander = 35 cm

D = Durchmesser des Rades = 9 cm

R = Radius des Rades = 4,5 cm

Anschließend werden Gleichungen für den Umfang vom Rad und vom Kreis, auf dem sich der Roboter bewegen soll, aufgestellt:

So kann die Anzahl der Umdrehungen, die zum Zurücklegen der Strecke notwendig sind, berechnet werden.

Nun muss man wissen, wie viele Signale die Encoder pro Radumdrehung geben. Dazu wurden folgende Zählungen und Berechnungen gemacht:

Bild 12: Tabelle zur Berechnung der Encodersignalzahl pro Radumdrehung. Rot markierter Wert: berechnete Encodersignalzahl pro Umdrehung

Der ermittelte Durchschnitt sagt uns, dass ein Encoder 2400 Signale pro Umdrehung gibt. Mithilfe der Anzahl der Umdrehungen können wir also nun die benötigte Encodersignalzahl berechnen:

Nachdem sich der Roboter erfolgreich gedreht hat, wird aus Processing ein Signal an den Arduino gesendet, der dem Motortreiber daraufhin den Befehl zum Geradeaus-Fahren gibt, d.h. dass beide Motoren, durch den Motortreiber gesteuert, mit gleicher Geschwindigkeit solange die Räder vorwärts bewegen, bis aus Processing ein Befehl zum Anhalten kommt.

Der gesamte Programm-Prozess läuft also wie folgt ab: Zuerst wird mit dem Processing-Programm die Signalstärke gemessen, dann der Befehl von dort aus an den Arduino gegeben, den Servo zu drehen, was dieser dann auch tut. Das Processing-Programm wartet eine bestimmte Zeit, damit der Servo genug Zeit zum Drehen hat, und beginnt dann wieder zu messen. Dieser Prozess wird 180 Mal wiederholt, bis also der Servo sich mit der WLAN-Antenne um 180 Grad gedreht hat. Anschließend wird in Processing die höchste Signalstärke berechnet und der dazugehörige Winkel ermittelt. Dieser wird dann an Arduino geschickt. Daraus berechnet dieser die Encoderzahl, sodass der Arduino den Befehl an den Motortreiber geben kann, wie oft und wie lange sich das linke Rad drehen muss. Daraufhin wird das Rad solange gedreht, bis die Encoderzahl erreicht ist. Währenddessen wartet Processing und gibt danach den Befehl zum Geradeaus-Fahren, der wieder an Arduino übermittelt wird. Dieser gibt den Befehl weiter an den Motortreiber und der Roboter fährt geradeaus. Processing wartet erneut und gibt dann den Befehl an den Arduino, zu stoppen, was dieser dann auch umsetzt.

Bild 12: Kommunikationsdiagramm für Arduino und Processing

Damit unser Roboter nun aber nicht vom Laptop abhängig ist, gibt es die Möglichkeit, den Raspberry Pi, einen Einplatinencomputer, anstelle des Laptops zu verwenden. Der Raspberry Pi sorgt nun (anstelle es Laptops) dafür, dass die Antenne die WLAN-Signalstärken misst und im Programm auf dem Rasperry Pi das höchste Signal berechnet wird. Er muss natürlich auch mit einer externen Stromquelle versorgt werden, da ein Laptop als Stromquelle ja nun nicht mehr zur Verfügung steht. Als eine solche dient uns ein Akku. Da der Raspberry Pi eine Versorgungsspannung von genau 5 Volt benötigt, der Akku jedoch mindestens 7-8 Volt abgibt, wird ein Konverter benötigt, der die Spannung auf 5 Volt herunterregelt. Von dort aus wird auch der Servo mit Strom versorgt, da eine Versorgung direkt über den Arduino zum Zusammenbruch des Systems führt, da der Servo dort zu viel Strom zieht. Ein Nachteil des Raspberry Pis ist, dass er im Vergleich zum Laptop sehr langsam ist. Die Messung der WLAN-Signalstärken benötigt mehr Zeit, daher läuft auch der Servo nicht ganz so flüssig und schnell, wie vom Laptop aus gesteuert. Aber auch beim Durchlauf mit dem Laptop ist die Geschwindigkeit der Servodrehung relativ niedrig, sodass ein Einsatz des BagBuddys im Alltag schon allein deswegen eher unwahrscheinlich wäre. Auch der Versuch, das „delay“ bezüglich des Servos im Programm zu reduzieren oder ganz wegzulassen, führte zu einem Aussetzen des Servos, sodass dieses „delay“ nötig für einen zuverlässigen Programmablauf ist.

Dieses Problem haben wir zunächst bewusst ausgeklammert und die Prioriät auf die Wlan-Erkennung und den Fahralgorithmus gesetzt. Für ein Ausweichen vor Hindernissen gibt es die Möglichkeit von Infrarot- oder Ultraschallsensoren, mit Hilfe derer der Roboter den Abstand zu einem Hindernis erkennen könnte. Nach dieser Erkennung müsste der BagBuddy den Abstand einstufen und bei zu wenig Platz ausweichen, also stehen bleiben, sich in eine andere Richtung drehen und dann weiterfahren. Hierbei kommt er jedoch von seinem eigentlichen Weg ab, sodass er dann wieder stoppen, eine neue Messung der WLAN-Werte machen und sich dann neu ausrichten müsste, um anschließend wieder in die richtige Richtung zu fahren.

Einen Mindestabstand könnte man mit Abstandssensoren einhalten, wobei hier darauf zu achten ist, wie sich der Roboter verhält, wenn zwischen zu folgender Person und Roboter ein anderer Gegendstand/ eine andere Person kommt. Also müsste der Roboter auch unterscheiden können, ob „nur kurz jemand dazwischen läuft“ oder ob der Roboter im Begriff ist, gegen einen Gegenstand zu fahren.

Abschließend können wir sagen, dass das Hauptziel des BagBuddys erreicht ist: Der BagBuddy kann zu einem WLAN-Signal fahren und eine Tasche tragen! Er kann das Signal eines Handy-Hotspots erkennen, sich zu dem entsprechenden Winkel ausrichten und dann zu dem Signal fahren. Was er (noch) nicht kann, ist das Folgen im zu mir entsprechenden Abstand und das Ausweichen von Hindernissen. Ein Problem des BagBuddys ist seine Langsamkeit im Messen der Signalstärken. Ab einer bestimmten Geschwindigkeit bei der Drehung des Servos funktioniert die Übermittlung der Daten nicht mehr. Dass heißt, dass der Roboter insgesamt ziemlich lange braucht, um zu mir zu fahren. Daher kann sein Gebrauch im Alltag zu diesem Zeit- und Entwicklungspunkt noch nicht sehr effektiv sein.

Ebenso ist die Umsetzung des Antennenbaus, wie oben schon erwähnt, nicht optimal: Durch eine bessere Fixierung hätten Messfehler und -ungenauigkeiten verhindert werden können.

Bei einer Weiterentwicklung des Roboters könnten also beispielsweise die Antenne stabilisiert und verbessert, das Fahren des Roboters zu einem Handy-Hotspots anstatt der fest stationierten WLAN-Quelle oder das Folgen mit entsprechendem Hindernisausweichen ausprobiert werden.

Hinzu kommen außerdem: Styropor, Kupferdraht, Schrauben, Muttern, Unterlegscheiben, ein Holzstab und ein Haken.

Pinbelegung des Arduino