Im Zeichen des Pinguins

Pinguin, Himbeere, das sind keine neuen Sternzeichen. Die Himbeere ist das Logo des Raspberry Pi. Der Pinguin ist das Logo von Linux, dem freien Betriebssystem.

Das ist ein ausschließlich technischer Artikel über Computer und hat mit der Programmierung des Tello nur indirekt etwas zu tun. Wer sich nur für das fliegen und fotografieren/filmen mit Quadrocoptern interessiert, findet die relevanten Artikel hier.

Linux ist ein open-source, also freies und kostenloses Betriebssystem, eine Alternative zu Windows. Es steht im Ruf, auch auf älteren und leistungsschwächeren Computern zu laufen. "Don't throw away that old computer yet".

Da liegt noch so ein altes Notebook herum, ein "Asus eee PC". Klein und handlich, war gedacht für unterwegs um z.B. Powerpoint-Präsentationen zu zeigen. Aber was ihm dazu fehlt ist die power, darum liegt er herum. Wegwerfen, also entsorgen, bzw. einem Sozialprojekt spenden?

Er wäre ja praktisch wenn ich den Tello mit meinen Programmen steuere. Da will ich nicht meinen 17" Laptop mit ins Freie nehmen. Und ich brauche ja meistens kaum Rechnerleistung um meine Python-Programme abzufeiern. Der eee wäre gerade recht. Ich müsste einiges an Software installieren, und dann bleibt noch das Problem dass er unter Windows 7 fürchterlich langsam läuft.

Also, tu den Pinguin in den PC. Wenn ich geahnt hätte wie viel Zeit ich damit verbringen würde, dann wäre ich trotz allem bei Windows geblieben oder hätte ihn weggeworfen. Aber es hat natürlich auch Spaß gemacht und war lehrreich. Wann hat man schon einen Rechner auf dem man beliebig herum ferkeln kann, Partitions erstellen, formatieren, löschen, den Bootsektor überschreiben usw. Wenn es schiefgeht und der Rechner gar nicht mehr geht dann ist es egal.

Zuerst einmal blauäugig Linux Mint mit "mate", dem default-Desktop installiert. Da hätte ich gleich bei Windows bleiben können, das Resultat war unbrauchbar. Nach ein paar Mausklicks war das Ding so langsam dass man es nur mehr mit dem Einschaltknopf (lang drücken) wieder dazu bringen konnte irgendetwas zu tun, und zwar einen Neustart.

Eine Liste mit "Linux für alte Rechner" gefunden. Mit dem LinuxLive USB Creator einen bootfähigen USB-stick erstellen, PC mit dem stick booten und die jeweilige Linux-Variante erst einmal probieren ohne sie zu installieren. Da hat es welche gegeben die gleich gar nicht gelaufen sind, manche waren hoffnungslos veraltet, bei einem konnte ich keine Software nach-installieren. Die die so einmal gut ausgeschaut haben habe ich versucht auf die Festplatte zu installieren. Ohne Rücksicht auf vorhandene Daten, einfach drüber installieren. Das ist jedes mal mit mit gehörigem Zeitaufwand verbunden. Manchmal hat das Installationsprogramm mit einer Fehlermeldung abgebrochen, manchmal ist es einfach nur stehen geblieben, manchmal war die Installation erfolgreich aber der Rechner konnte nicht booten. Der Versuch, den Bootloader händisch nach zu installieren, ist gescheitert.

Eine Rückfall-Ebene wäre ein Linux ohne GUI (graphical user interface) sondern nur mit einem CLI (command line interface) installieren. Aber so schnell gebe ich nicht auf.

Zurück zu Mint. Bei Linux ist - im Gegensatz zu Windows - das Betriebssystem nicht fix mit dem Desktop verbandelt. Desktops, auch window manager genannt, gibt es viele. Das ist eine Geschmacks- und Hardware-Frage. Mint statt mit dem default-desktop "mate" mit dem Desktop XFCE downloaden. Der braucht weniger Ressourcen. Später noch den IceWM desktop dazu installieren, der braucht noch weniger, ist aber nicht so komfortabel.

Linux Mint mit dem Memorystck im abgesicherten Modus booten, installieren - Fehlermeldung: Kann die boot-partition nicht lesen. Kein Wunder, die ist mit ext2 statt fat32 formatiert. Ein Fehler des Installationsprogramms oder ein Überbleibsel von früheren Versuchen. "gparted", den "GNU Partition Editor" aufrufen (der ist praktischerweise gleich am Memory Stick drauf) und die boot-Partiton der Harddisk umformatieren. Wann traut man sich das schon? Noch einmal installieren.

Und siehe da: Es läuft!

Aber nicht schnell. Probehalber eine große Powerpoint-Präsentation in LibreOffice Impress geöffnet - es geht, besser als mit Powerpoint unter Windows, aber nicht viel besser. Lieber nicht mehr als 2-3 Fenster öffnen, sonst wird's fad.

Den Video-Stream von Tello empfangen und in einem Fenster darstellen? Bricht nach ein paar Sekunden ab. Also kein Video-Stream auf diesem PC, das geht am Handy besser.

Die meisten meiner Programme brauchen kein GUI sondern laufen im CLI. Normalerweise öffnet man dazu einen Terminal-Emulator.

Ja, früher ist der Rechner im Rechenzentrum gestanden und der Benutzer ist vor einem Terminal gesessen das über serielle Schnittstelle mit dem Rechner verbunden war. Auf heutigen Betriebssystemen kann man ein solches Terminal emulieren. Ursprünglich war dieses Terminal aber ein Fernschreiber, die serielle Schnittstelle heißt heute noch "tty" für "teletype". Und dieser Fernschreiber konnte auch über eine Telefonleitung mit dem Rechenzentrum verbunden sein, das war die Globalisierung von damals. Ich habe in der HTL auf einem Computer programmieren gelernt der in Cleveland Ohio gestanden ist und dessen Rechenzeit in der dortigen Nacht in alle Welt verkauft wurde. Ja, man hat für die Rechenzeit bezahlt. Und für die Telefonleitung sowieso.

Terminals mit Bildschirm waren dann die große Sensation. Die ersten PC's, also persönliche Computer die nicht im Rechenzentrum sondern auf dem Schreibtisch des Benutzers Platz fanden, hatten ebenfalls einen solchen schwarzen Röhren-Bildschirm auf dem weiße (oder grüne, oder bernsteinfarbene) Zeichen zu sehen waren. Zeichen. Linien, Kreise, das war nicht so einfach zu bewerkstelligen. Und an Fotos oder gar Filme hat sowieso niemand gedacht. Farb-Bildschirme waren noch Luxus. Das Betriebssystem hieß MS-DOS, Microsoft Disk-Operating-System. Der Massenspeicher war eben eine Disk, eine Floppy Disk mit der Speichergröße 360KB. Kilo(!)-Byte. Das war viel, dazu brauchte man schon double-side, double-density fünf-ein-viertel-Zoll Floppies. Die wurden in absperrbaren Boxen verwahrt. Cyber Security von damals.

Ach ja, zurück zu unserem Thema, ich bin beim Terminal-Emulator stehen geblieben bzw. abgeschweift. Die meisten meiner Programme laufen in einem Terminal-Emulator, also einem schwarzen Fenster mit weißer Schrift in dem man Befehle eintippen kann. Für junge Leute schaut das ungeheuer nerdig aus.Wie im Film "Matrix".

Linux hat ja noch ein feature das selten genutzt wird, aber brustschwachen Rechnern entgegen kommt. Mit der Tastenkombination Ctrl-Alt-F1 kommt man in ein CLI. Wie damals. Und mit Ctrl-Alt-F2, Ctrl-Alt-F3 usw. bis 6 in weitere CLI's, mit Ctrl-Alt-F7 wieder ins GUI. 

In der MS-DOS-Zeit gab es ein geniales Programm, geschrieben von Peter Norton, den Norton Commander. Er nutzte die (erweiterten) ASCII-Zeichen um Fenster darzustellen. Und das lange vor Windows. Zwei Fenster, mit einem Tastendruck lässt sich ein file oder directory von einem ins andere Fenster kopieren, verschieben, vergleichen, directories vergleichen, synchronisieren, etc. Unter Linux gibt es den "midnight commander", eine Portierung des alten Norton Commander.
That old feeling....

Alles was kein GUI braucht im CLI machen. Dann ist sogar dieser Rechner wieder flott genug.
Wer sagt dass Pinguine nicht fliegen können?

Im Zeichen der Himbeere

Was da auf dem Tello drauf ist, das Ding mit den zwei Metallzylindern die wie Augen aussehen, das ist ein Ultraschall-Sensor. Was man erst auf den zweiten Blick erkennt ist ein Computer. Ein kompletter Linux-Rechner. Ein Raspberry Pi Zero W. Montiert am Dachträger des Tello.

Ein "Spielzeuggeschäft" an dem ich nicht vorbei gehen konnte. Voll mit Raspberry Pi's aller Arten, Zubehör, Sensoren (eben auch dem Ultraschall-Abstands-Sensor).

Der Ultraschall-Sensor soll verhindern dass Tello gegen ein Hindernis fliegt. Das gilt natürlich nur solange er vorwärts fliegt, ein Quadrocopter kann ja in beliebige Richtungen fliegen. Aber als erster Versuch und als Bastelei.

Hier ein Plot der gemessenen Distanz, ich fliege zu einem Möbelstück und wieder weg. Es war zu befürchten dass die Rotoren das Ultraschall-Signal stören, und diese Befürchtung ist eingetreten. Ich habe gleich einen Infrarot-Sensor gekauft, den werde ich als nächstes testen.

Der Raspberry Pi kann auch fotografieren und filmen. Film in Full-HD-Auflösung, auf der lokalen SD-Card gespeichert und nicht am Handy. Damit entfallen die Störungen durch die Übertragung per WLAN.

Aber das ist alles noch Bastelei. Technische Spielerei. Wenn's funktioniert werde ich berichten.

nix wia bresln mit dem Brezlbrett

(für nicht-österreichische bzw. nicht-ost-österreichische Leser: "nix wia bresln" heißt so viel wie "nichts als Schwierigkeiten" (Bresln = Brösel = Krümel))
Und warum Brezlbrett? Weiß ich auch nicht. Wir kommen gleich dazu.

Das ist ein vorwiegend technischer Artikel über die Programmierung des Tello. Wer sich nur für das fliegen und fotografieren/filmen mit Quadrocoptern interessiert, findet die relevanten Artikel hier.

Die Steuerung des Tello mit Arduino und PC funktioniert gut und war ein Spaß zu bauen. Aber in Gedanken war ich, wie ich bereits angedeutet habe, schon weiter.

Statt den PC herum zu schleppen könnte der Arduino direkt mit dem Tello kommunizieren. Dazu gibt es einen Arduino mit eingebautem WLAN-Modul, also genau das richtige für mein Vorhaben. Es handelt sich um einen Nano-kompatiblen Mikroprozessor mit einem ESP 8266 Modul das für die Kommunikation sorgt. Das ganze nennt sich NanoESP oder  "Pretzelboard". Fragt mich nicht woher der zweite Name kommt.

NanoESP ist nicht viel größer als ein Nano alleine. Tello kann ja an seinem Ladestecker 5V liefern (dazu braucht man ein OTG-fähiges USB-Kabel). Dann könnte das Pretzelboard ja mitfliegen und z.B. mit einem Distanz-Sensor (Laser. Ultraschall,...) Kollisionen vermeiden.

Wie sieht die Spannung aus, ist sie stabil, kann man ihr einen Prozessor anvertrauen? Interessanterweise wird die Spannung erst nach dem Selbsttest eingeschaltet, und dann in zwei Stufen. Dies zeigt das folgende Oszilloskop-Bild:

(übrigens ein screenshot vom Raspberry Pi 4, auf dem die Oszlloskop-Software läuft)

Aber erst einmal das Pretzelboard in Betrieb nehmen. Ich habe schon länger eines herum liegen. Ich habe einen Webserver damit realisiert. Mit CGI-Funktionen konnte der Server auf Benutzer-Eingaben reagieren. Ich wollte es verwenden um Reglerparameter für ein autonom fahrendes Segelboot einstellen zu können ohne den PC per Kabel mit dem Boot verbinden zu müssen. Die Kommunikation hat gut funktioniert, aber ich war bald mit dem Speicherplatz zu ende. Ein Micro-SD Kartenleser der Abhilfe hätte schaffen sollen hat aber nicht gut funktioniert sodass das Projekt ins Stocken geraten ist.

OK, TCP/IP geht, UDP sollte ein Kinderspiel sein. Sollte man meinen.

Zuerst einmal kryptische Compilerfehler. Die Ursache: Ich habe zwei ähnliche libraries auf meinem Rechner gehabt die das gleiche h-file beinhaltet haben. Das sollte der Compiler zwar bemerken, hat es aber nicht. Gut, ich habe es bemerkt. Eine library löschen.

Der ESP 8266 wird über AT-Kommandos angesprochen, die der Nano per Software-Serial an den ESP schickt. Ein simples sketch verbindet den PC mit dem ESP indem er die Kommandos durchreicht. Ein typischer Kommunikationsvorgang kann so aussehen:

AT+RST
OK

Das sollte den ESP resettieren. Ich bekomme aber:

AR+RST
ERROR

Jeder Befehl wird mit ERROR verweigert. Was ist los? Im Internet suchen, natürlich hat jemand das gleiche Problem gehabt. Der serielle Monitor muss auf CR/LF eingestellt sein. Steht übrigens in der (sehr knappen) Bedienungsanleitung. RTFM.Read the fabulous manual.

Nachdem diese Hindernisse aus dem Weg geräumt sind geht es an die UDP-Kommunikation. Beispiel-Programme gibt es ja - wie bei fast allem was mit dem Arduino zu tun hat - genug.

Tello mag keine CR/LF's, daher stelle ich den Monitor wieder um und füge CR/LF's dort ein wo der ESP 8266 sie braucht, aber nicht dort wo ein Kommando an Tello weitergereicht wird. 

Aber es will nicht klappen. Ich bekomme zeitweise "gallische Schimpfwörter" wie wenn ich die falsche Baudrate eingestellt hätte. Delays einfügen - nicht sehr sauber - dann funktioniert das.

Das eine Beispielprogramm kann - nach etwas Modifikation - Daten an den PC senden, das andere kann Daten vom PC empfangen. Der jeweils andere Weg funktioniert nicht. Mit etwas Bastlerei gelingt es, ein Programm zusammen zu schustern bei dem Senden und Empfangen funktionieren.

Also Tello einschalten und das Pretzelboard mit dem Tello verbinden, dann kann der erste Probeflug stattfinden!

Geht nicht, ich kann mich nicht mit dem Tello verbinden. Mit allen anderen Netzen hat es bisher geklappt. Ich konnte den NanoESP überall mit dem Internet verbinden, auch im Urlaub über das WLAN des Hotels. Umgekehrt, mit allen anderen Geräten (PC, Handy, Raspberry Pi) konnte ich die Verbindung zum Tello herstellen. Nur diese Kombination geht nicht.

Frust. 

Okay, es gibt einen workaround. Würg-around. Da ich den Tello EDU habe, kann ich ja, umgekehrt, Tello und NanoESP mit einem anderen Netz verbinden, z.B. einem handy-hotspot.

Tello's IP-Adresse mit einem IP-scanner feststellen und diese Adresse ins Arduino-Programm eingeben (vorerst hard-coded). 

So klappt es. In den beiden screenshots sieht man die AT-Kommandos die ich zum Debuggen anzeige. Wie man hier sieht bin ich die gallischen Schimpfwörter nicht ganz los geworden, wahrschenlich  hat Tello etwas "unanständiges" geschickt (das kommt vor, weil auch nicht-ASCII-codierte Informationen ausgetauscht werden, siehe hier). Aber das betrifft nur die Kommunikation zwischen Pretzelboard und PC (der in diesem Stadium der Entwicklung noch dran hängt), über's WLAN scheint es glatt zu gehen. Immerhin, ein Probeflug mit dem Pretzelboard ist geschafft.

Und dann Tello umstellen so dass er wieder einen access point zur Verfügung stellt. Auch ein bisschen kryptisch. Heute bin ich froh dass Tello auf dem Ventilator steht und nicht dauernd überhitzt.

------

Ich habe den Raspberry Pi erwähnt. Den könnte man als Bindeglied zwischen Controller bzw. RC-Sender  und Tello verwenden, obgleich das hieße mit Kanonen auf Spatzen zu schießen.

Leute montieren einen Raspberry auf den Tello, das scheint doch ein bisserl zu viel Gewicht zu sein??

Aber halt! Nicht den normalen Raspberry Pi 3 oder 4, sondern den den "Raspberry Pi Zero W". Kaum größer als das Pretzelboard, mit WLAN, SD-Karte, Kamera-Anschluss und Linux. Und kostet die Hälfte. Ich glaube, er wird auf den Tello gepackt.

Aber das ist eine andere Geschichte und die soll ein anderes Mal erzählt werden.

Links:

https://www.mikrocontroller-elektronik.de/wifi-board-nanoesp-bzw-pretzel-board/

https://iot.fkainka.de/library

 https://iot.fkainka.de/day-3

Kühlen Kopter bewahren

Beim Programmieren kommt es vor dass ich länger sitze und nachdenke. Wenn ich dann so weit bin die neue Version zu testen funktioniert es nicht weil Tello sich inzwischen ausgeschaltet hat. Aber warum?

Ich habe mir ja ein Programm geschrieben mit dem ich Daten auslesen und in ein spreadsheet kopieren kann. Der Versuch bestätigt den Verdacht: Tello ist überhitzt weil ihm der Luftstrom fehlt. Das folgende Diagramm zeigt den Temperaturverlauf, nach 10 Minuten ist die Temperatur auf 95 Grad angestiegen und Tello schaltet sich ab.  

Also ein Gestell entwerfen in dem ein Lüfter eingebaut ist der von unten auf die Kühlrippen bläst. Natürlich wird das Gestell mit dem 3D-Drucker realisiert.

Tello möge mir dieses Portrait verzeihen,
um das Gestell zu entwerfen ist es gut genug.

Weil andere das gleiche Problem haben, gibt es das Gestell auf thingiverse zum Nachdrucken:
https://www.thingiverse.com/thing:4144048

Weiters wird ein Lüfter mit den Maßen 25 x 25 x 10mm benötigt, wie z.B. dieser.
Zur Stromversorgung habe ich ein USB-Kabel durchgeschnitten und die Versorgungsleitungen an den Lüfter gelötet. So kann ich den Lüfter von einem USB-Netzgerät, vom PC oder von einer power bank betreiben.

Ich wiederhole den Versuch mit Lüfter: Die Temperatur bleibt konstant.

Guter Schüler

Das ist ein vorwiegend technischer Artikel über die Programmierung des Tello. Wer sich nur für das fliegen und fotografieren/filmen mit Quadrocoptern interessiert, findet die relevanten Artikel hier.

Statt des Controllers der für Kinderhände gebaut ist hätte ich auch meinen guten, alten 35MHz Sender zerlegen und umbauen können. Auch er hat Potentiometer die man anzapfen könnte, und in seinem Gehäuse hätte ich den Arduino locker untergebracht.

Mein guter, alter 35MHz Sender

Aber ich habe es nicht übers Herz gebracht den Sender kaputt zu machen, auch wenn wir aus guten Gründen nicht mehr mit 35MHz fliegen. Wie viele Abstürze gehen auf das Konto der Funkstörungen! Heute fliegen wir mit 2,4GHz und die Funkstörungen sind Geschichte.

Der Sender hat eine Lehrer-Schüler-Buchse, praktischerweise ein 2,5mm Klinkenstecker den man leicht bekommt. Sie ist dazu gedacht, zwei Sender miteinander zu verbinden. Der Schüler-Sender schickt seine Knüppelstellungen über das Kabel an den Lehrer-Sender. Der Lehrer kann über einen Schalter entscheiden ob sein Sender das Signal des Schülers an das Modell schickt oder die Daten des Lehrer-Senders. Ich verwende meinen Sender als Schüler-Sender und den PC als "Lehrer-Sender".

Das Signal das bei der Schüler-Buchse heraus kommt lässt sich auslesen und verarbeiten.

8-Kanal PPM-Signal

Das PPM (Puls-Pause-Modulation) Format kodiert die Information in Pulsen, deren Dauer von der Knüppelstellung der jeweiligen Kanäle abhängt. Wie man im obigen Oszillogramm sieht, handelt es sich um einen 8-Kanal-Sender. Wenn ich die Knüppel bewege verschieben sich die Pulse.

Ich habe mir schon überlegt wie man ein Programm realisieren könnte das diese Zeitdauern misst. Relativ kompliziert, mit Interrupts. Aber ich bin doch sicher nicht der erste der das versucht und habe Tante Gugl gefragt. Sie hat mir zwei nützliche Informationen gegeben.

1. Arduino stellt einen Befehl "pulseIn" zur Verfügung der Pulslängen misst 
2. Jemand hat schon ein Arduino-Programm geschrieben das genau das macht

Dieses Programm nehme ich als Basis um mein eigenes Programm daraus zu entwickeln. Werte umrechnen, ins richtige Format bringen und an der seriellen Schnittstelle ausgeben. Fertig. Na ja, ganz so einfach wie ich es mir vorgestellt habe war es dann doch nicht.

Man könnte jeden Arduino dazu verwenden, aber ich bin zufällig auf eine besondere Ausführung gestoßen: Beetle BadUSB. Ein Arduino auf einer winzigen Platine die sich direkt in USB-Buchse des Computers stecken lässt.

Zusätzlich handelt es sich um einen 32U4-Prozessor mit dem man die Maus- und Keyboard-Bibliotheken des Arduino verwenden kann. Für meinen konkreten Anwendungsfall brauche ich dieses Feature nicht, weil ich auf der PC-Seite auf die (simulierte) serielle Schnittstelle zugreifen kann. Aber mit Maus- und/oder Keyboard-Simulation kann man jedes beliebige Programm steuern, z.B. Spiele.

Ob du es glaubst oder nicht,
das ist ein Arduino!

Naturgemäß ist die Anzahl der IO-Pins auf dieser Platine eingeschränkt, es stehen nur je 3 digitale und analoge Ein/Ausgänge zur Verfügung. Mit meiner angedachten Interrupt-Lösung hätte ich keine Chance weil es leider keine interrupt-fähigen Eingänge sind, aber für die (blockierende) pulsIn-Funktion kann man jeden Eingang verwenden.

Ein bisschen Schrumpfschlauch und fertig.

Ich habe damals noch einen zusätzlichen Schalter in den Sender eingebaut. Diesen verwende ich jetzt um den Befehl zum Landen zu geben. Außerdem baue ich mein Programm so dass es den Befehl zum Landen schickt wenn das PPM_Signal ausfällt. Sender ausschalten und Tello landet. Sender wieder einschalten und Tello ist startklar.

Und dann der erste Probeflug mit der neuem Konfiguration. Der "richtige" Sender vermittelt ein ganz anderes Gefühl als die als die kleinen Spielkonsolen und erlaubt eine wesentlich feinfühligere Steuerung. Trimmung, Expo und einstellbare Rückholfedern stehen zur Verfügung. Das steigert das Flugvergnügen noch einmal!

Wie immer gibt es mein Programm als open-source auf GitHub, siehe hier. 

Projekt abgeschlossen. Abgehakt? Dann kennst du mich schlecht. Die nächsten Ideen geistern schon in meinem Kopf herum. Den Sender mit nach draußen nehmen, aber den Laptop auf der Parkbank platzieren? Oder auf dem Schoß (dazu ist er ja gedacht)? Nicht so gut. Wie wäre es mit einem kompakteren Rechner? Da gibt es doch den Raspberry Pi. Das Python-Programm auf dem Raspberry zum Laufen bringen und den Raspberry an den Sender montieren. Und noch ein paar Schieber, Schalter, Taster in den Sender einbauen. Und den Raspberry mit dem Handy verbinden,.....

Oder einen Arduino NanoESP ins Gehäuse des Sender einbauen und direkt, ohne zusätzlichen Rechner, mit dem Tello kommunizieren.

Hier wird es bald wieder etwas neues zu lesen geben.

Eigenbau-Controller

Am PC programmieren macht Spaß. Während Tello gerade nicht automatisch und von einem Programm gesteuert fliegt gebe ich Befehle per Hand ein. Über die Tastatur. Das ist nicht sehr komfortabel.

Ich habe doch noch einen Controller von so einem 15€-Quadrocopter herum liegen der nicht mehr fliegt. Zu viel Staub, Haare, vielleicht auch überhitzt, und immer noch nicht entsorgt. Sein Controller kommt jetzt zu Ehren.

Ein Arduino findet sich auch noch in der Bastelkiste, und so entsteht ein Drahtverhau der wie Daniel Düsentrieb's neueste Erfindung aussieht.

Der Arduino wird in das Gehäuse eingebaut, ein entsprechendes Python-Programm auf der PC-Seite, und der Controller darf jetzt ein viel edleres Fluggerät steuern.

Mit den winzigen Joysticks hat man wenig Gefühl, kein Wunder dass der zugehörige Quadrocopter so oft gegen die Wand geklatscht ist. Aber für den eigenstabilen Tello reicht es. Und die Bastlerei an einem verregneten Wochenende hat Spaß gemacht.

Das Rezept zum Nachkochen ist hier: homebrew-usb-controller-for-tello

tell Tello oder Der Barometermacher auf der Drohneninsel

Von einem Fliegerkollegen
vorgeschlagener Testaufbau ;-)
© Terry

Viele Stunden sind in die Programmierung gelaufen. So wie es Raimund's Barometermacher auf die Zauberinsel verschlagen hat, hat mich die Programmierung des Tello in ihren Bann gezogen. Diverse features kann man nur ausprobieren indem man ein Programm schreibt. Aus einem einfachen demo-Programm das man im Internet findet wird ein kleines Testprogramm das immer weiter wächst.

Eine beispielhafte Anwendung war der Test des Luftdruck-Sensors um ihn später für eine Regelung der Flughöhe einzusetzen.

Der Versuch, ein graphisches user interface (GUI) mit tkinter zu bauen, ist gescheitert. Es hat zwar funktioniert, aber das timing hat nicht gepasst und Werte die ich von Tello ausgelesen habe waren zwar auf den ersten Blick plausibel aber nicht korrekt.

So bin ich reumütig zum guten alten Console-Programm zurückgekehrt. So schlecht ist das aber auch nicht. Was mein Programm kann:

• Fly Tello with text commands (like "ccw 90") or with keys (like w/a/s/d and cursor keys)
• execute commands from a text file
• watch selected variables from the status string and write them to a comma-separated list (csv-format)

Die erste Probe war eben das Auslesen der Luftdruck-Werte. Nach ein paar Fehlversuchen und geschredderten Zimmerpflanzen war es so weit.

Tello wird vom Programm gesteuert und die Werte werden im csv-Format ausgegeben. In's spreadsheet kopieren und mit wenigen Klicks ein Diagramm erstellen - fertig!

Das Programm kann nicht nur Barometerwerte auslesen sondern auch vieles andere. Unter dem Namen "tellTello" steht es frei zugänglich im Internet.

Have some fun with it!

Links: 

cozmobotics/tellTello

telltello-a-console-based-frontend-to-the-sdk-written-in-python3

https://tellopilots.com/threads/testing-the-barometer.4743

Tello GoLang - programming beyond SDK

Das ist ein rein technischer Artikel über die Programmierung des Tello. Wer sich nur für das fliegen und fotografieren/filmen mit Quadrocoptern interessiert, findet die relevanten Artikel hier.

Das SDK erleichtert die Erstellung eigener Programme, ist aber nicht zwingend erforderlich.
Es gibt einige Besipiel-Programme im Internet, die ohne SDK auskommen.

Das tello Go (golang) package ist von Stephen Merrony aus Frankreich geschrieben. "The tello Go (golang) package is an unofficial, easy-to-use, standalone API for the Ryze Tello® drone."

Was ist go, was ist golang? Go ist eine Programmiersprache (siehe Wikipedia). Also die (n+1)te Programmiersprache erlernen!
Zuerst einmal den Compiler installieren und mit einem "hello world" - Programm testen.
Dann ein - gut gemachtes - tutorial durchlaufen.

Einiges ist anders als gewohnt. Bei Variablendeklarationen steht der Typ in C vor dem Variablennamen, bei go danach. Der Funktionsrumpf wird wie in C in geschweiften Klammern geschrieben, aber anders als in C ist es nicht egal welche und wie viele whitespace-character vor der ersten geschweiften Klammer stehen. Schlimmer noch: Man muss die Klammer so setzen wie ich es nicht mag. Na gut, Gewohnheitssache.

Open Source ist ja ein erstaunliches Phänomen in unserer von Kommerz geprägten Welt. Der Compiler ist frei downloadbar, und das tello golang Paket ist ebenfalls kostenlos und im source code verfügbar.

https://github.com/SMerrony/tello
und um das package zu testen ein Terminalprogramm das die Funktionen aufruft:
https://github.com/SMerrony/telloterm

Downloaden und zu übersetzen beginnen. Erste Fehlermeldung - ein fehlendes package downloaden - nächste Fehlermeldung - wieder ein package ergänzen, nach 5 zusätzlichen Packages bekomme ich ein exekutierbares Programm!

Tello einschalten, PC mit dem WLAN verbinden und telloterm starten.

Ich kann Tello mit Tastendrücken abheben lassen, steigen, sinken, drehen, landen.
Ich bekomme die Koordiantenangaben die mir das SDK 2.0 vorenthalten hat.

Videostram darstellen - dazu musste ich mplayer downloaden - funktioniert!

Bild im Bild im Bild...
Kamera auf den Bildschirm gerichtet
immer wieder lustig

Das Programm verwendet nicht die SDK sondern die "normale" Kommunikation die auch die apps verwenden. Hier wird nicht mit ASCII-Strings gearbeitet sondern mit Bitfeldern in denen die Angaben binär codiert auf gewissen bits liegen. Unter anderem sind Einträge für die Position der Steuerknüppel, die eine harmonische Steuerung des Tello erlauben. Das ganze ist natürlich unabhängig von der Programmiersprache.

Und schon juckt es mich in den Fingern das Programm abzuwandeln oder zu verbessern, seine Funktionen für eigene Programme zu verwenden. Im code herum stierln um draufzukommen wie die Kommunikation zum Tello funktioniert.

Links

 Compiler installieren

Go tutorial "A Tour of Go"

https://github.com/SMerrony/tello

https://github.com/SMerrony/telloterm

tello package documentation https://godoc.org/github.com/SMerrony/tello

https://github.com/SMerrony/tello/blob/master/ImplementationChart.md Hex-Codes für Befehle

https://gobot.io/blog/2018/04/20/hello-tello-hacking-drones-with-go/

Tello EDU

© Ryze Robotics

Das ist ein rein technischer Artikel über die Programmierung des Tello. Wer sich nur für das fliegen und fotografieren/filmen mit Quadrocoptern interessiert, findet die relevanten Artikel hier.

Per Programm Befehle zum Tello zu schicken macht Spaß, gerade auch in Verbindung mit dem Cozmo. Aber im Vergleich zum Cozmo bietet das SDK sehr wenig. Was mir gefehlt hat, das waren Befehle zum Abfragen der aktuellen Position, zum Positionieren an eine absolute Koordinatenangabe und zum Streamen des Videos.

Ich habe die Beschreibung der SDK 2.0 gefunden, wo genau diese Features enthalten sind.
Aber wie, bitte, kommt man zur SDK 2.0?

In der Beschreibung der SDK 2.0 wird ein anderer UDP Port verwendet. Das wird es wohl sein! UDP Port geändert, das Verhalten ist unverändert.Eingabe von sdk?" ergibt "unknown command".

Firmware updaten, schließlich läuft das SDK in der firmware - nichts.

-grübel-grübel-und-studier-

Des Rätsels Lösung: Es gibt einen Tello EDU ("educational") der mechanisch identisch ist und die gleichen Daten aufweist, aber eine andere Firmware hat.

SDK 2.0 kann mehr, die zusätzlichen Fähigkeiten sind:

• Zusätzliche Kommandos wie SDK-Version und Seriennummer abfragen sowie an eine vorgegebene Position fliegen
• Seinen Status melden der aus Position, Geschwindigkeit, Beschleunigung und Temperatur besteht EDIT: Das kann der normale Tello auch 
• "Mission pads" erkennen, das sind Karten mit aufgedruckten Mustern, und sich relativ zu einem mission pad positionieren 
• Den Video-stream empfangen EDIT: Das kann der normale Tello auch
• Mit einem existierenden WLAN verbinden statt einen eigenen WLAN access point bereitzustellen (so lässt sich ein Drohnen-Schwarm realisieren)

Im Prinzip muss das eigentlich auch mit dem normalen Tello gehen, weil die Entwickler von apps Zugang zu diesen Daten haben, mit Ausnahme der mission pads.

Ich finde die Idee des EDU gut: Jugendlichen spielerisch das Programmieren beibringen. Wie ich begonnen habe programmieren zu lernen, war unser Erfolgserlebnis  eine Textausgabe auf einem Fernschreiber (Bildschirme sind erst später gekommen). Als Assistent an der TU konnten wir Studierenden das Erlebnis bieten, mit ihren Programmen etwas reales bewegen zu können. Industrieroboter und einfache Manipulatoren. Einen Quadrocopter per Programm durchs Zimmer fliegen zu lassen finde ich faszinierend.

Hätte ich doch die - um einiges teurere - EDU-Variante nehmen sollen? Tello hat noch keine Gebrauchs-spuren und die Original-Verpackung habe ich sicherheitshalber aufgehoben. Also sorgfältig verpacken, auch der Akku kommt ins originale Säckchen, und wieder zum Conrad pilgern. Der Verkäufer (ein anderer als der der mich beim Kauf beraten hat) beäugt den Tello kritisch, bemerkt Haare die mir nicht aufgefallen waren und geht seinen Chef fragen ob er den Tello zurück nehmen darf. Mit etwas Verhandlungsgeschick und dem Hinweis auf die lobende Erwähnung in diesem Blog erreiche ich dass Tello zurückgenommen wird und Tello EDU bestellt wird.

Er ist nach drei Tagen da. Bei der Inbetriebnahme gibt es ein Problem: Die Tello FPV app meldet dass ich zuerst die Original-app verwenden muss um den Tello zu "autorisieren". Wozu dieser Schritt dienen soll ist mir nicht klar. aTelloPilot gibt zwar keine Fehlermeldung aus, aber Tello startet nicht. Also die original-app öffnen - geht nicht. Mein Handy hat sich in der Zwischenzeit auf Android 10 ge-updated, und die original-app läuft nicht unter Android 10.

Was tun? Auf dem PC habe ich Bluestacks installiert, einen Android-Emulator. Dort die original-app installiert und gestartet - geht. Wieder auf's handy, Tello FPV und aTelloPilot funktionieren. Wer meinen Tello beim Conrad erworben hat, dem ist dieses Problem erspart geblieben.

Das Demo-Programm auf dem PC starten und "sdk?" eingeben - Antwort: "20". Gut, ich habe SDK 2.0.

Die bisherigen Programme testen - geht nach ein bisschen herumbasteln. Tello EDU ist abwärts-kompatibel mit dem normalen Tello.

Ein Problem: Während ich herum probiere und Tello EDU auf dem Schreibtisch liegt, läuft er heiß und schaltet sich ab. Offensichtlich fehlt ihm der kühlende Luftstrom der Rotoren. Das hat der normale Tello nicht gemacht.

Und jetzt mache ich mich daran, die neuen Funktionen zu implementieren. Für den Videostream gibt es ein ziemlich aufwändiges Demo-Programm, das aufwändige daran ist die Installation von unterstützender Software. Also doch etwas am PC installieren - aber das kann warten.

Vorher ein Programm schreiben das den Status ausliest. Dafür gibt es kein Beispielprogramm.

Aus der Beschreibung des SDK 2.0:

OK, einen UDP server aufsetzen. Das habe ich bei Siemens gemacht, mit einer anderen Programmiersprache und auf einem anderen Prozessor. Es gelingt - überraschenderweise - auf Anhieb. Jetzt ballert Tello auf den Bildschirm. 

Was ich mit diesen Daten anfangen werde, das werdet ihr später hier lesen können.

Tello EDU hat mich in zwei Punkten enttäuscht: 

1. Die Abfrage des Status ist bei der SDK 2.0 beschrieben. Ein Freund hat den normalen Tello, auf seinem Tello sollte diese Abfrage nicht funktionieren. Sie funktioniert aber bei ihm.
   Habe ich um 60€ zu viel ausgegeben?
2. Die Abfrage der Position funktioniert nur im "mission pad" Modus, nur wenn ein mission pad erkannt wurde und nur relativ zum mission pad (was auch so in der Dokumentation steht, ich habe sie nicht genau genug gelesen).
   Ich habe erwartet dass ohne mission pad eine Position relativ zur Start-Position ausgegeben wird, was mit dem optischen Positionierungssystem zumindest ungefähr möglich sein sollte. 

Natürlich hätte ich mit dem normalen Cozmo versuchen können, den Status zu empfangen. Ich abe aber nicht damit gerechnet, den UDP-Server auf Anhieb hinzukriegen. Wenn es dann nicht geht dann weiß man nicht ob man einen Fehler gemacht hat oder ob es prinzipiell nicht geht.

Gleiches gilt natürlich auch für den Video-stream.

Links:

https://tellopilots.com/threads/let-the-swarm-begin.3452/#post-21129
Nicht nur der Drohnenschwarm ist hier interessant, auch die Verwendung von packetsender