Turnigy 5x - Arduino RcLib Hacking-Mainboard

Status
Nicht offen für weitere Antworten.
#81
haha, das wohl kaum.

Ich sehe die T5x eher als eine gute Ergänzung.
Die Taranis, möchte ich auf keinen Fall missen, zumal sie die leistungsfähigste Funke überhaupt darstellt, die ich jemals hatte.

Andererseits hat man mit der T5x mehr als genug für die meisten FCs & Copter.
Aufwendige Mischprogramme benötigt man da ja eher selten.
 

nique

Legal-LongRanger
#82
Jaja schon. Aber was, wenn sie zur "Experimentier-Funke" mutiert, bis du genau weisst was du brauchst und dann packst dus in die kleine rein?

Naja, was mich sicherlich auch hindern wird, sind die Gimbals. Da ist in der Mechanik schon noch ein doller Unterschied.

Du sprichst jetzt für die Copter-Fraktion, aber auch die Flächenflieger brauchen nicht all die Möglichkeiten. Klar, da haben einige nun sehr wahnwitzige Mischer aufgebaut. Und wenn man segelt oder "scale" fliegen will, dann brauchts das schon. Aber um im Fleiger zu sitzen und die Welt zu geniessen, genügt das kleine Teil und ein paar einfache Funktionen - und die Sprachausgabe ;). Mir ist da die Telemetriefähigkeit dann schon bald wichtiger als die Kanalmischung. Gut, ich kenne keine andere Funke und weiss es von da her vielleicht zu wenig zu schätzen...:p

Darum hab ich auch zwei Platinen, dann kann ich eine N1x bauen. Einen Pultsender mit Deiner Platine und (einem) Taranis-Gimbal. Ein Mini-Cockpit für die Knie das auch meinen ergonimischen Ansprüchen entspricht. Das kleine Gehäuse ist dann für die Kids und den Urlaub.

Hmm, wenn ich schon an der Telemetrie rumstudiere. Wie viel Platz ist noch im Nano? Sonst könnte man auch an eine Extension mit einem weiteren Nano nur für die Telemetrie und Sprachausgabe studieren. Für FPV müsste das ja dann eh in Richtung Kopf, und wenn am Headset noch ein Nano baumelt, wird man das nicht bemerken.... Hmmm ... Eine Verbindung von Brille zur Funke hab ich auch (geplant) für den Headtracker. Warum nicht ein Leiter mehr? Respektive zwei Leiter, damit die PPM-Daten auch "hoch" kommen und die Ansagen der Mischwerte auch gemacht werden können.

Ahh, dann noch eine Sprachsteuerung, damit man per Voice die Telemetriedaten abfragen kann.... (hmm hatte ich schon Alkohol?)
 
#83
Wow, da gibts ja reichlich Ideen!

Derzeit sind wir noch knapp unter der Hälfte der 32kB. Aber da lässt sich noch einiges optimieren. Auch die Konfig könnte man ins EEPROM schieben. Mal sehen wie da alles so weitergeht.

Gruß aus Wien,
Christian
 

nique

Legal-LongRanger
#84
Konfig in EEPROM klingt gut. Einfach sehr sparsam damit sein. Die Anzahl Schreibvorgänge sind endlich... Im OpenSensor wollte jemand jeden neuen Wert dort zwischenspeichern. Bei einem Vario wären dann nach einem Flug der Arduino futsch...
 
#85
Momentan hat für mich mal Priorität:
Übersichtlicher Code. Das machts von Haus aus mal kompakter und leichter erweiterbar.

als nächstes kommt im Bedarfsfall Code-Optimierung.

Dann kann man noch immer den Weg Richtung EEPROM einschlagen. ist an sich keine große Hexerei.
Allerdings muß man das mal durchrechnen, wie groß hier das tatsächliche Einsparungspotenzial ist.
Zumal die Handhabung für den User dann auch etwas anders aussieht, denn die Daten müssen ja auch mal ins EEPROM gelangen.

Schreibzyklen sollten in unserem Fall nicht viele anfallen, hat man mal die ersten Einstellungen getätigt, sollten sich die Schreibzugriffe in einem übersichtlichen Maß abspielen.
 

nique

Legal-LongRanger
#86
Da mein Hühnerfutter noch unterwegs ist, hab ich mal mein teensy angeworfen. Wow, da gibts es frisch aus der Presse eine ppm-lib. Ein Democode der was generiert und auf dem nächsten Pin wieder einliest (loopback) und am Monitor ausgibt läuft auf Anhieb. Wer weis, vielleicht bin ich so gut und kann dann Dein Package auf Teensy portieren...
 
#87
Da die Arduino Rc-Lib wirklich sehr sehr gut und modular aufgebaut ist, könnte das durchaus funktionieren.
Man müsste dann halt neben den Anschlusspins auf jeden Fall die Timer-spezifischen Dinge anpassen. D.h. größtenteils ist das dann der eigentliche PPM-Teil und der Flugtimer. Könnte mir durchaus vorstellen, daß sich das in einem überschaubaren Rahmen abspielt.
Ein 32bit ARM Cortex-M4 mit 72MHz und 256kB Flash, 3 Serielle und massig RAM/EEPROM klingt da schon recht lecker.
Allerdings müsste man wohl auf die Touch Pins an der Unterseite vermutlich verzichten, zumal diese beim Einsatz an einer Platine schwierig bis unmöglich zu verwenden sind und abgesehen davon dort auch jetzt schon Leiterbahnen verlaufen.
Aber auf jeden Fall mal interessant um diese Option im Hinterkopf zu behalten.

Ich persönlich finde andererseits (zumindest momentan mal) den Reiz an der 5x gerade darin, diese auch ohne Display mit minimaler Hardware maximal auf unsere Bedürfnisse als (FPV)-Copter Piloten anzupassen...

Eine Plattform, bei der man einfach so auf die Schnelle mit einem Arduino IDE sich die Funktion programmiert, die man gerne hätte und dann damit aufs Flugfeld geht hat schon was...
 

DerCamperHB

Erfahrener Benutzer
#88
Wie wäre es eine Kombination zu machen, aus der 5x und einem AndroidSoftware zur Konfiguration
So hätte man zum einen einen kleinen Sender zum dabei haben, zum anderen gutes Display und Einstellmöglichkeiten bei Wunsch
Während des Fluges braucht man ja zu 99% kein Display, wenn die Verbindung aber per BT gemacht wird,könnte man sein Handy immer noch an einer passenden Stelle hinlegen
 

nique

Legal-LongRanger
#89
Camp, klingt gut. Ich will eigentlich auch kein Display, will ja FPV fliegen. Und da sehe ich schöne Landschaften, wenn ich auf den Sender gucke [brüllundschenkelklopf]. Also mir wäre eine Sprachausgabe wie bei openTX viel wichtiger. Und die ganze Menufummelei kann man ja auch sprachgesteuert machen: "Für Mischer drücken sie SA nach unten - für Servowege drücken sie..." [okichlassdasjetztmalsostehen]

Ich werde schon erst die 5X nach Kornetto fertig bauen, aber auch ein paar Dinge für den nächsten Schritt ordern. Das dauert ja auch immer sooo lange.
 
#90
Genau sowas hätte ich vorgehabt, hab sogar schon ein CLI-Interface samt EEPROM-Speicherverwaltung fertig hier liegen, aber die Arduino-RC Lib benötigt zwecks PPM-Signal Hardware-Timer, die dann für ein Software-Serial nicht mehr zur Verfügung stehen und die (leider einzige) Hardware-Serial am Nano wird ja schon für Telemetrie verwendet.
Die Idee wäre gewesen einen Billig-Bluetooth/Serial Adapter an den Nano zu hängen um auf dem Weg Konfigurationen vorzunehmen.
Aber daraus wird wohl leider nix.


@Code-Optimierung: Ich hab soeben das Ermitteln der Kanal-Position von der absolut speicherhungrigen Arduino String-Klasse auf gute alte Pointer-Berechnung umgeschrieben. Im Endeffekt eigentlich nur 3 Code-Zeilen.
Und schon hat man auf einen Schlag mehr als 1.5 kByte gespart. klingt nicht viel, ist aber in Anbetracht der gesamt zur Verfügung stehenden 32kB schon einiges.
Derzeit liegt das Binary bei 12.9 kB, ist also schon noch einiges an Platz für Wahnwitziges...

Beim Auslagern der Modell-Profile ins EEPROM wäre nochmal ein halbes kB drin, aber ich hab zzt. keine wirkliche Idee wie man die Daten möglichst ergonomisch ins EEPROM bekommt.
Der Umweg über einen eigenen Sketch / Preprozessor-Switch nur um die Daten zu schreiben erscheint mir da etwas mühsam und umständlich.
Ein Weg wäre noch die Serielle entsprechend speziell zu behandeln, so daß man z.B. nach Verbinden mit dem Sender ein paar Sekunden Zeit bekommt oder ein paar "###" schickt um dann eine Konfig in den Sender zu schiessen.

Gefällt mir aber alles nicht so recht, vielleicht hat ja jemand von Euch ein paar Ideen dazu?

Gruß aus Wien,
Christian
 

nique

Legal-LongRanger
#91
So, Futter angeklebt. Was fehlt noch? Grrr, nur noch der Nano.

Habe beide Platinen fertig, eine sogar mit allen Steckern bestückt. Das gibt die Labor-Platine. Leider fehlen mir da auch noch Buchsenleisten für den Nano. Habe nur die Runden und die vertragen sich nicht so mit meinen Stiftleisten - grrrr.

Noch zum speichern. Da könnte man für den nächsten Print ev einen Switch vorsehen, den man (wie bei Reset-Switches) durch eine kleine Öffnung im Gehäuse bedient. Oder verwende gleich einen Switch auf der Vorderseite. Um zu üben hat es ja genügend freie Pins.
 
#92
ich würde den Nano nicht gesockelt verbauen, das könnte im Gehäuse knapp werden. Mußt Du vorher mal checken.
vor allem der ICSP-Stecker steht dann bestimmt am Batteriegefach innen an.
Ich hab bei mir den Nano direkt verlötet.

Ich versteh nicht ganz, wie Du das mit dem Switch für das Speichern meinst.
Problem ist ja nicht das Triggern des Speicherns, sondern vielmehr, daß man die Werte zuerst mal im RAM haben muß um sie ins EEPROM zu bekommen. zZt packt der Compiler die Werte mit dem Code ins ROM. also sprichwörtlich hard-coded.
Und genau hier beißt sich die Katze in den Schwanz.
Es ist auch kein Problem die Werte im EEPROM mal initial mit defaults zu füllen. Nur wie soll die eigentliche Änderung vonstatten gehen?
Ich persönlich mag eigentlich kein Display an der 5x, denn mit Menüführung, Tasten usw. wird das an der kleinen Funke wohl eher eine frustige Angelegenheit.

Die Serielle in einen speziellen Konfig-Mode zu versetzen um so von "aussen" die Werte zu verändern geht bestimmt.
Bleibt der Sender ausgeschalten bleibt auch der Telemetrie-Teil stumm und funkt somit nicht dazwischen.
Versorgt wird der Arduino nano dann ja ohnehin über USB.

Nur wie gehts hier weiter?

CLI ist nicht jedermanns Sache. Ich mags berufsbedingt, aber natürlich wäre hier eine Handy/Chrome-App mit einem relativ schlanken Protokoll zwecks Parameter setzen und lesen eine idee.
Was mir gefallen würde, wär sowas wie der Chrome Baseflight Configurator für die Naze32. Ist dann gleich Plattform-übergreifend. Das Übertragungsprotokoll der Daten sollte wenn möglich binär ausfallen um den Code möglichst schlank am Nano zu halten.
Ich denke beim Verlagern der Konfig-Parameter vom ROM ins EEPROM gehts dann weniger um Einsparungspotenzial des Speicherbedarfs als vielmehr um möglichst angenehmes Handling.

Leider hab ich weder mit dem Schreiben von Android-Apps noch Chrome-Apps oder ähnlichen Erfahrung.
Wie sieht's da draussen aus? Von Euch jemand?

Gruß,
Christian
 
Zuletzt bearbeitet:

nique

Legal-LongRanger
#93
Ach soo, dann hab ich das Problem falsch verstanden. Da hab ich auch keine Erfahrung, wie man das am besten löst. Immerhin - ich verstehs jetzt und sollte ich eine Eingebung haben.

Bei mir kriegt eine Platine alle Stecker / Stifleisten / Sockel, weil ich mit der auf dem Tisch dann rumspiele. Die zweite Platine kriegt dann nur das verpasst, was notwendig ist. Und da wird der Nano dann schon direkt verlötet.
 
#95
Heute hat sich die T5x soweit im echten Leben sowohl mit dem Hammerhead Nano sowie der guten alten Quadrixette 40 bewiesen. Rock-Solid, tut sie genau wofür sie gedacht ist. und das ganze noch dazu so wunderbar kompakt.
Hab heute 12 Akkus leer geflogen und es gab - erwartungsgemäß - überhaupt keine Probleme.

Hier noch ein Bild was das super Packmaß der kleinen Funke angeht, mein neuer FPV-Immer-Dabei Koffer:

Darin finden Platz: T5x, Hammerhead Nano mit CCD-Killer Cam und Mobius HD, 6x 2s1500mAh, SD-VCR mit Empfänger, CL/SPW-Set.

bzw. nochmal mit der Fatshark Dominator (die befördere ich extra in der original-Box) als Größenvergleich:


Neben dem FPV-Köfferchen sieht die kleine Quadrixette Q40 schon aus wie ein riesen-Kopter:


Heute ist endlich das Sound-Modul angekommen. Leider hab ich nicht bedacht, daß dazu eine 1GB microSD-Karte nötig ist und alle meine Karten im Fundus sind leider um vieles größer. Eine 2GB microSD konnte ich noch finden, hab aber damit bis dato dem Soundmodul noch keinen Ton entlocken können. Ich hoffe mal dass es nur an der Karte liegt, 1GB Karte ist schon bestellt...

Gruß aus Wien,
Christian
 

Anhänge

Terry

Erfahrener Benutzer
#97
Hallo Kornetto, super Vorlage die Kofferempfehlung von Nic 😚 ... derselbe hat bei mir im Moment sein leeres dasein... aber bald wenn die kleine Funke nicht mehr auf Backorder ist & hoffentlich nach dem Umbau alles funzt...da freu ich mich drauf! VG: Terry
 

nique

Legal-LongRanger
#98
WOW!

Leider läuft das Hackerboard wegen fehlender Teile noch nicht, dafür die Konkurrenz! Hab den XJT an ein Teensy gehängt und mit der PulsePosition-Lib tatächlich mit 4 Zeilen 2 Servos bewegt bekommen. Genommen hab ich natürlich ein Taranis Gimbal.

Christian, wenn es ok ist, werde ich mich von Deinem Code inspirieren lassen. Ich denke auch, dass ein Grossteil der RC-Lib verwendet werden kann. Ok, hier gibts nicht mehr dazu, weil OT. Poste alles in GitHub.

Ich hab nur gerade grosse freude, dass es funzt! Und freue mich auf die Kleine.
 
#99
Hey, das klingt ja sehr vielversprechend!
klar, gerne. Genau das ist ja das Schöne an Github. Zieh dir einfach einen Fork der aktuellen Version um davon ausgehend mal mit Teensy zu experimentieren.

Ich bin grade dabei mir was wegen der Konfig & EEProm zu überlegen und hab auch schon ein paar Ideen.

Sobald die Ideen konkrete Formen annehmen, halte ich Euch auf dem Laufenden. Leider komme ich immer nur in geringen Zeit-Dosen zum Testen und Experimentieren.

Verdammt, warum hat der Tag nur 24 Stunden?
 

nique

Legal-LongRanger
Was nur? Ich hoffe Du kannst rechnen:
Tag: 24h
Nacht: 6-8h
Mittag: 1h
Pausen: 0.5h

Was gibt das Total? 33.5h - und das soll nicht reichen? Dann muss Du an den Prioritäten arbeiten...

Spendet zwar kein Trost, aber mir gehts gleich. Und die wenige Zeit für den Modellbau verteile ich auch noch auf zig Projekte...
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten