Autonomer Flieger- habt ihr Interesse?

[Rabenauge]

Sodele.
Heute ist Freitag, da soll man ja nicht so lange arbeiten- umso mehr Zeit am Drift zu basteln.

Eins hab ich schon einige Tage vor mir hergeschoben: den Motor- Regler mal neu programmieren.
Das _musste_ aber sein, weil ich ja nun mit Ionen-Akku fliege, und die viel tiefer entladen werden können als LiPo.
Beim LiPo hatte ich die höchstmögliche Abschaltspannung eingestellt: 3.2V. Da ist der LiIo vielleicht halb leer....wenn überhaupt.

Normalerweise werden diese Regler mit dem Gasknüppel programmiert, eigentlich ganz einfach: Regler an den Empfänger stecken, Gasknüppel auf Vollgas (dann kommt man in die Programmierungen), Strom dazu...und los gehts.
Klappt mit Inav (oder Ardupilot) nicht, denn die schalten sich gar nicht scharf, wenn man den Gasknüppel nicht im Leerlauf hat- der Regler bekommt dann schlichtweg nix.
Gut, im Testmodus (via Inav-Konfigurator) kann man Gas geben, aber auch erst, wenn eine Verbindung besteht. Wenn ich aber den FC, wie üblich, aus dem Flugakku versorge, dann muss zuerst die BT-Verbindung aufgebaut werden. Das heisst: er kann gar kein Vollgas-Signal beim einschalten kriegen.
Also mal wieder das USB-Kabel dran..das dauert, weil der Stecker, wo der USB-Adapter dran kommt, eigentlich nicht zugänglich ist, er liegt auf dem mittleren Board, genau unter der SD-Karte:



Kann man nicht besser fotografieren- und sehen auch nicht. Es ist die graue Linie unterhalb des SD-Slots.
Da muss der Stecker nun angefädelt werden:



und dann mittels Pinzette richtig reingedrückt:



Am anderen Ende sitzt dann ein USB-Adapter. So kann man das Teil jetzt mit dem Rechner verbinden, ohne dass der Regler was von merkt. Der FC läuft zwar, aber alles ringsrum ist weitgehend abgeschalten (GPS, REC-Empfänger, Regler, LED's).
Nun muss noch der Propeller ab (er sollte zwar nicht anlaufen bei der Prozedur, aber sicher ist sicher) , und wir können in Inav mal Vollgas geben:



Jetzt den Flugakku auch noch anstecken, und schon kann man den Regler programmieren, indem man mit dem Schieber da den Gashebel simuliert.
Die Abschalt-Spannung (wenn die unterschritten wird, schaltet der Regler den Motor aus, um Tiefentladung zu verhindern) ist nun bei 2.8V/Zelle- tiefer gehts bei diesem Regler nicht.
Da bleibt reichlich Reserve...auch gut. Die Flugzeit sollte nun trotzdem jenseits gut und böse liegen, neulich war ich insgesamt etwas länger als anderthalb Stunden in der Luft, da hab ich um die 900mAh nachgeladen. 3000 wären da...
Bei der Gelegenheit hab ich gleich die restlichen Einstellungen (der kleine ZOHD-Regler hat vorbildlich viele...) überprüft.

Mit nem ganz kleinen Uhrmacher-Schraubenzieher krieg ich das USB-Adapter-Kabel dann auch wieder rausgefummelt.
Dann noch die SD-Karte wieder rein und fertig.

Wieder was erledigt...

Jetzt wird es Zeit, mir mal Gedanken zu machen, wie ich weitere Flugmodi bedienen soll. Momentan liegen die drei verfügbaren auf nem Drei-Wege-Schalter: Stabilisierter Modus (oder Angle, wie es in Inav heisst), manuell und RTH. Die drei bleiben auch dauerhaft- RTH ist der Rettungsanker, stabilisiert flieg ich am meisten (weils einfach schön stressfrei ist) und der manuelle macht auch mal Spass...
Mindestens zwei weitere will ich haben: NavPoshold (auf ner Kreisbahn in der Luft parken) und den Wegpunkt-Modus.
Ich muss also nen zweiten Schalter dazu nehmen (was mit nem simplen Mischer erst mal auch ganz einfach ist), aber eben so, dass bestimmte Modi Priorität haben.
Mal sehen, was mir dazu einfällt...

[Rabenauge]

Ich habs geschafft, zwei Schalter für sechs Stellungen auf einen Kanal zu bekommen.
Der Trick sind die richtigen Mischer....
Nun hab ich sechs Flugmodi konfigurieren können, eigentlich hätten fünf mir genügt, aber wenn Lücken im Kanal-Mapping entstehen, dann fällt Inav auf die "Grundeinstellung" zurück- und _das_ ist der unerwünschte Acro-Modus.
Um das zu verhindern, musste ich also sechs Modi konfigurieren:

• stabilisiert (Flightcontroller kümmert sich um die Lageregelung, aber man kann innerhalb sicherer Limits alles selber steuern
• manuell (Fightcontroller erledigt _nur_ das Mischen (der Querruder und Spoiler zu den Querrudern) ansonsten hält er sich aus allem raus
• rth (automatischer Rückkehr-Modus, der sowohl im failsave-Fall (Funkverbindung weg) als auch manuell ausgelöst werden kann, der Rettungsanker schlechthin)
• navPosHold zusammen mit navAltHold (Parkstellung, der Flieger umkreist den Punkt, an dem die Funktion ausgelöst wird, bis der Akku leer ist oder man nen anderen Modus wählt, und hält dabei Position und Höhe)
• navWP (Wegpunktmodus, hier können vorher bis zu 60 Wegpunkte im Controller gespeichert werden, die autonom abgeflogen werden)
• horizon (das ist der Lückenfüller, dieser Modus stabilisiert den Flieger, wenn man _nichts_ steuert, tut man es aber, hat man volle Ausschläge- meiner Meinung nach ist _das_ ein richtiger "Acro-Modus")

Über den Horizon-Modus bin ich noch nicht ganz glücklich- der Drift ist viel zu wendig für unlimitierte Ruderausschläge. Zumindest werd ich den auf die Schalterstellung zu legen versuchen, wo ich im Sender über ne zweite Flugphase sowieso die Ausschläge begrenzt habe. Das hab ich im manuellen ja eh...

Was ich noch machen muss ist, die Modi so auf die Schalter aufteilen, dass ich mir merken kann, wann ich was auslöse. Die ersten drei hab ich ja von Anfang an drin, und da hat sich auch nix an den Schalterstellungen geändert, aber die anderen müssen so geordnet sein, dass es leicht "merkbar" ist.
Zwar sagt das Telemetrie-Skript die Flugmodi auch an, aber dann _hat man sie schon aktiviert_- und Horizon in Bodennähe könnte böse enden, wenn man es unbeabsichtigt aktiviert...

Ausserdem überlege ich noch, welche Strategie für den Rückkehr-Modus wohl die beste ist, da gibts viele Optionen.
Beispielsweise kann man ein Offset festlegen, also eine Art "Mindesthöhe"- die man wahlweise zur grössten, in dem Flug geflogenen Höhe dazu addieren kann (wenn ich also 100m hoch geflogen bin, und RTH aktiviere, dann wird er nicht auf 100m, sondern aus 100m+Mindesthöhe zurückkommen, und erst "zu Hause" auf die, separat definierte, Höhe gehen, um da zu kreisen.
Man kann aber auch festlegen,dass _immer_ zuerst die Mindesthöhe erreicht wird (durch steigen oder sinken) und dann zurück geflogen wird.

Ersteres ist natürlich sicherer (weil die Höhe für den Rückflug immer höher als die dort je geflogene sein wird)- hat aber auch den Nachteil, dass der Flieger unter Umständen so weit aufsteigt, dass er nicht mehr zu erkennen ist.
Grundsätzlich ist das nicht schlimm (wenn er da ist, kommt er ja auf die Parkhöhe runter), aber ich hab immer ein etwas ungutes Gefühl bei sowas...da muss man der Technik wirklich _blind_ vertrauen.

Die zweite Strategie kann auch mal dumm ausgehen, nämlich dann, wenn man in direkter Verbindung zwischen Home und Flieger nen Berg (oder ein anderes, höheres Hindernis) stehen hat. Da er den direkten Rückweg nimmt, ist das denkbar (so ne verdammte Windmühle, zum Beispiel).

Ich denke, dass ich vorerst trotzdem bei dieser Variante bleibe (ich hab die RTH- Höhe auf 70 oder 75m eingestellt, für die üblichen Springbäume reicht das), und das noch etliche Male testen, wenn es denn immer einwandfrei funktioniert, gehe ich auf Variante 1.

Ausserdem hab ich RTH jetzt so konfiguriert, dass er _vor dem Rückflug_ schon seine Höhe erreichen soll, indem er kreist. Erst beim Rückflug klettern, kann auch schief gehen...
Auf die Weise kann ich auch mal in eins der Täler eintauchen, und komme da sicher wieder raus.
Terrain-Following ist leider nicht- Terraindaten kann Inav nich verarbeiten. Und per Boden-Sensor (z.B. Lidar) nem Terrain flogen, wird beim Flugzeug an der ersten Baumreihe scheitern. Bei einem Copter auch.

Nebenbei hab ich mit der Mission-Planner-App fürs Tablet mal ein wenig rumgespielt. Die hat mehr drauf, als ich dachte: wenn man dort Wegpunkte erstellt, sieht man auch, wie hoch das Terrain dort, im Vergleich zum Startpunkt, ist.
Das ist grade hier im Gebirge enorm nützlich- und _das_ kann nicht mal meine Bebop2-Drohne.
Man sieht direkt, wie hoch man einen Wegpunkt legen muss, um den Berg zu überfliegen...
Ausserdem speichert die App, wenn man nen Flugplan erstellt und im Tablet abspeichert, auch die Kartendaten mit- auf die Weise kann ich ohne Internetanschluss meine bevorzugten Fluggebiet-Karten auch abspeichern.
Ich leg mir einfach zu Hause ne weitreichende Mission an und speichere die.
Vor Ort ändere ich diese Mission dann einfach ab.
Falls ich das mal vergessen sollte, kann ich immernoch per Handy nen Hotspot öffnen, über den sich das Pad die Kartendaten besorgen kann.

Zusätzlich ist eine Funktion eingebaut, mit der man das fragliche Gebiet nach verbotenen Zonen absuchen kann. Auch recht nützlich (Naturschutzgebiete, Flugverbotszonen, alles Mögliche).

Sollte also funktionieren, wie ich mir das vorstelle...

Einziger Wermutstropfen: die Bluetooth-Verbindung klappt -mehr oder weniger. Teilweise braucht man mehrere Versuche, um die App mit dem Flieger zu verbinden.
Wenn die Verbindung aber mal steht, gibts auch keine Abbrüche mehr, das ist also brauchbar.
Und von Reichweite reden wir gar nicht- auf nen Meter funktionierts (zwei vielleicht auch noch)...also mal eben, während der Flieger schon über mir kreist, nen Flugplan erstellen und rauf laden, ist so nicht. Der Flieger hat nur ein BLE-Modul drin.
Damit kann ich aber leben...
Die Alternative dazu wäre, mit 433MHz-Funkmodulen zu arbeiten, und aus dem Pad damit ne richtige Bodenstation zu machen. verlockend, aber wieder mehr Gewicht im Flieger- daher werd ich mir das wohl für später für den Ranger aufheben. Der kommt dann auch mit ner 17cm langen Antenne klar.

Ich denke, an Hardware kommt nur noch eine Runcam Split in den Drift, damit ich die Flüge filmen kann. Die 10g sind grade noch im Limit, immerhin kann ich noch einige Kabel im Flieger kürzen (an manche kommt man tatsächlich noch ran) und auch zwei Servostecker könnten durch Lötverbindungen und Schrumpfschlauch ersetzt werden...
Verhandlungen mit meiner Finanzabteilung laufen da schon...die Runcams sind Klasse, aber nicht ganz billig.

[Rabenauge]

Vorgestern abend hatte ich den grossen Ranger noch mal durchgecheckt, damit der (mit dem Kopilot Lite) auch endlich mal Luft unter die Flügel bekommen kann.
Zum Glück hab ich auch mal das failsave simuliert (Sender ausschalten, dann sollte automatisch return to home aktiviert werden), da gab es nämlich ein Problem:

RTH wurde aktiviert, aber dazu wurden die Landeklappen in Bremsstellung gefahren-also voll nach unten!
Bei den FrSky-Empfängern kann man failsave frei programmieren, es gibt die Möglichkeit, für jeden Kanal festzulegen,was der Empfänger bei unterbrochener Funkverbindung ausgeben soll. Daher hätte das nicht passieren dürfen..tat es aber.
Das hätte böse enden können- Rückflug mit ausgeworfenem Anker...vermutlich würden die Klappen das nicht überleben- oder der ganze Flieger.

Dank einem Hinweis aus nem anderen Forum hab ich den SBus als Übeltäter ausmachen können: der gibt _eben nicht_ die korrekten Failsave-Signale kanalweise weiter. Da haben die chinesischen Freude mal wieder gestümpert...zwar kommt eine Art Zusatz-Signal "wir sind im Failsafe-Modus", aber der kleine Kopilot kann damit, im Gegensatz zu richtigen Flightcontrollern, nix anfangen.
Würde der SBus einwandfrei funktionieren, bräuchte man das gar nicht...

Ich hab dann gestern die Klappen direkt an den Empfänger angesteckt (vorher waren sie am passthru-Kanal des Kopiloten, der _nur_ über den SBus erfährt, was zu tun ist), und nun klappt es.
Interessanterweise funktioniert Kanal 5, auf dem die Modi liegen, dennoch- nur Kanal 6 zickt rum.
Da bleibt ein etwas ungutes Gefühl...aber für ein paar Probeflüge wirds gehen, ich muss ja die Reichweiten-Limits nicht ausreizen. Ich setze eben die RSSI-Warnung etwas höher, dann erfahre ich rechtzeitig, wenn es eng werden kann.
Und später kommt ja der Kopilot eh wieder raus.

[Rabenauge]

Zurück zum Drift.
Gestern war ich mal wieder fliegen- und hab mich gewundert, dass er im Angle-Modus (=voll stabilisiert, man kann manuell alles steuern, aber die Ausschläge sind limitiert mit Ausnahme des Motors, den der Controller in diesem Flugmodus überhaupt nicht bedient) eigenartig schwammig fliegt, immer kurz vorm Strömungsabriss.
Als ich mir die Geschwindigkeit ansagen liess, lag die immer nen Stück unter 30 km/h....bis ich dann in nem tieferen Vorbeiflug gesehen habe, dass der Propeller langsam rotiert...als ich neulich den Regler umprogrammiert hatte, hatte ich _auch_ die Bremse eine Stufe zurück genommen. Offenbar reicht das nicht, um den Propeller zu stoppen- und der wirkt wie ein kleiner Bremsschirm, wenn er rotiert.
Noch besser wäre eine Klappluftschraube. Da der Motor aber ne 5mm-Welle hat, dürfte da nix zu kriegen sein in 5x3.
Die sind meistens für 2mm-Wellen....

Da ich den Drift ja ohnehin auf möglichst geringes sinken eingestellt hab, flog er so die ganze Zeit nahe an der Grenze zum Stall.
Das hab ich abends natürlich direkt wieder geändert. Gerade kleine Flieger müssen laufen, wenn sie nicht superleicht sind.

Ausserdem ist die Runcam Spilt4 bestellt- die hätte gestern schon kommen sollen, nur hatte der Postbote mal wieder keinen Bock die Treppe rauf zu kommen *grummel
Die hol ich nachher von der Post ab und hoffe, ich krieg sie noch irgendwie unter (wird knapp).
Wenn möglich, will ich sie gar nicht komplett verkabeln- da ich den Drift nicht fpv fliegen will (dazu müsste auch noch ein Videosender rein), muss die eigentlich gar nicht mit dem Controller verkabelt werden- und ich muss den nicht _nochmal_ ausbauen.
Aber das weiss ich erst, wenn sie da ist....ob das aufnehmen auch so funktioniert.
Die grosse Runcam 2 kann man so konfigurieren, dass sie beim einschalten automatisch aufnimmt, ich hoffe, bei der kleinen geht das auch.

Und falls ich mal wirklich Bock auf FPV haben sollte, geht das trotzdem, dann tausche ich die Runcam gegen diese ZOHD-Kamera aus, die hat ja nen Videosender verbaut. Gibts kein richtiges OSD (die hat schon eins, aber da sie nicht mit dem Flightcontroller redet, keinerlei Telemetrie im Bild), aber geht schon..

Mit den Flug-und Navigationsmodi kämpfe ich immernoch:
Die Konfiguration von neulich ist nicht gut. Ich hab das trocken geübt, das wird so nix.
Da passieren im Flug zu schnell Verwechslungen mit dem Layout.
Also noch mal ran...

[Rabenauge]

Sodele.
Die Kamera ist drin und läuft auch.

Nun musste ich tatsächlich am Heck noch anderthalb Gramm Ballast anbringen, um den Schwerpunkt wieder hinzukriegen- weiter nach hinten geht der Akku nämlich nicht mehr.

Ich hab mal nen Zollstock dazugelegt, damit man die Dimensionen erahnen kann:



Das gaaanz vorne ist die eigentliche Kamera. Die schräge Platine dahinter gehört aber auch dazu, dort könnte man den Flightcontroller anschliessen, an den dann wiederum den Videosender...das hab ich beides gelassen.
Meine wird einfach vom Flugregler versorgt, der hatte praktischerweise sowieso nen Anschluss dafür (die ZOHD-Kamera kann man dort auch anstecken).
Der Haken an der Sache: die nimmt ab dem einschalten auf- und das in 4k, weil ich die Auflösung nicht runter setzen kann ohne OSD.
Zumindest _das_ hätte ich erwartet, Schnäppchen sind die Runcams ja nun wirklich nicht (und womöglich geht das auch, nur schweigt sich die Anleitung drüber aus). Allerdings kann man mit einem der Buttons die Aufnahme wenigstens stoppen (z.B. während man wartet, bis das GPS ausgeschlafen hat).

Naja, wenn ich für den Ranger dann FPV-Equipment hab, kann ich die da ja mal anschliessen und umstellen, bis dahin muss es eben irgendwie mit der abartigen Auflösung gehn...
Mal sehen, ob ich morgen zum fliegen kommen werde.

[Rabenauge]

Gestern hats geklappt:


Das Flugverhalten ist aber immer noch etwas zu schwammig.
Da es _nur_ im Segelflug so ist (mit nem bisschen Motor ist das Problem komplett weg), muss ich die Grundgeschwindigkeit erhöhen. Der Propeller steht nun wieder, also war der nicht die Ursache.
Neulich hatte ich ja den Controller virtuell etwas gedreht ( um die X-Achse), vermutlich war das einfach zu viel des Guten.

Da gehe ich noch mal ran.
Ausserdem muss ich die Kamera irgendwie befestigen (momentan steckt sie einfach mit der Linse nur in der Schaum-Nase), denn der Drift fliegt nicht, wie es im Video aussieht, mit nem hängenden Flügel-die Kamera hatte sich verdreht.

Und wieso die Aufnahme kurz vor der Landung plötzlich aufgehört hat, frage ich mich auch (da ist nix geschnitten, ich hab nur am Anfang etwas weggeschnitten gehabt).

[inka]

gefällt mir was du da machst, danke...