Neu: Quatos Adaptive Control for AutoQuad
- Themenstarter kinderkram
- Beginndatum
2,5 Kg sind nicht viel. Einen 500'er Hexa mit FPV Equipment, Gimbal und Gopro geht schnell über 2,5 Kg. Gerade wenn man länger als 10 Minuten fliegen möchte. Denn die Akkus wiegen allein schon fast ein Kilo... Und mein neuer X8 wird über 4Kg wiegen. Auch nur Hobby. Von daher wäre eine weitere Staffelung sicherlich nicht schlecht.
Aber warten wir mal ab. Da kommt bestimmt noch etwas ;-)
Aber warten wir mal ab. Da kommt bestimmt noch etwas ;-)
So, nochmal ein Update:
Es wird erstmal keinen Upgrade Weg für Hobbylizenzen geben. Alles über 2,5kg wird als kommerziell angesehen.
http://autoquad.org/wiki/wiki/quatos-adaptive-control/quatos-adaptive-control-license-for-the-m4/
Nochmal zur Erinnerung: Quatos wird keinerlei Effekt auf die Open Source Firmware haben! Diese wird weiterhin kostenlos zum Download angeboten. Ginge auch garnich anders - einmal Open Source, immer Open Source.
Es wird erstmal keinen Upgrade Weg für Hobbylizenzen geben. Alles über 2,5kg wird als kommerziell angesehen.
http://autoquad.org/wiki/wiki/quatos-adaptive-control/quatos-adaptive-control-license-for-the-m4/
Nochmal zur Erinnerung: Quatos wird keinerlei Effekt auf die Open Source Firmware haben! Diese wird weiterhin kostenlos zum Download angeboten. Ginge auch garnich anders - einmal Open Source, immer Open Source.
Menno zeigt mal, wie Quatos Motorausfälle und zusätzliche Payload kompensiert:
[video=youtube;dl9VPmEqbPU]https://www.youtube.com/watch?v=dl9VPmEqbPU[/video]
Bei 3 Ausfällen benimmt sich der X8 aber wie ne Bleiente - Höhe halten is schwierig.
Aber gibt im Notfall ein ordentliches Polster, um den Vogel sauber runter zu holen.
Interessant wäre, wie er sich im schnellen Vorwärts- oder Kurvenflug verhält. Da trennt sich die Spreu vom Weizen...
[video=youtube;dl9VPmEqbPU]https://www.youtube.com/watch?v=dl9VPmEqbPU[/video]
Bei 3 Ausfällen benimmt sich der X8 aber wie ne Bleiente - Höhe halten is schwierig.
Aber gibt im Notfall ein ordentliches Polster, um den Vogel sauber runter zu holen.
Interessant wäre, wie er sich im schnellen Vorwärts- oder Kurvenflug verhält. Da trennt sich die Spreu vom Weizen...
Sieht ja ganz gut aus das Video. Die Frage ist aber ja, wie sich der Kopter ohne Quatos verhalten würde. Bei einem Ausfall sollte da ja das Verhalten vermutlich ähnlich sein, vielleicht aber ja auch nicht.
Gruß, hexakopter
Ps.: Und von 3 Ausfällen sieht man ja auch nichts im Video. Wenn ich es richtig sehe ist der Ausschnitt mit dem Zusatzgewicht auch nur auf einen und nicht auf zwei Motoren bezogen.
Gruß, hexakopter
Ps.: Und von 3 Ausfällen sieht man ja auch nichts im Video. Wenn ich es richtig sehe ist der Ausschnitt mit dem Zusatzgewicht auch nur auf einen und nicht auf zwei Motoren bezogen.
Zuletzt bearbeitet:
Da hat er Recht, Norbert. In dem Video ist eigentlich nix zu erkennen, was nicht jeder normale X8 kann. Selbst zwei gleichlaufende Props gehen in der Regel gut, sofern der Copter ausreichend motorisiert ist.
EDIT: fseider: tut er mit dem PID-Controller genauso wenig. Ich hab Motorausfälle mit eigentlich jeder FC getestet.
EDIT: fseider: tut er mit dem PID-Controller genauso wenig. Ich hab Motorausfälle mit eigentlich jeder FC getestet.
Zuletzt bearbeitet:
Ich kann auch bestätigen, dass der AQ mit halbwegs passenden PID auf einem Octo auch bei Ausfall von zwei Motoren noch gut fliegt. Den Ausfalls eines Motors im realen Einsatz auf einem 4kg Flat Octo habe ich gerade unfreiwillig getestet... man hat beim Fliegen gespührt, dass etwas nicht stimmt - aber ansonsten keine größeren Probleme. Konnte ihn trotz mäßigen Windböen sicher meinem "Fänger" in die Hände steuern.
Wenn wir über das Thema Sicherheit und Verlässlichkeit sprechen, habe ich leider mit dem AQ derzeit andere Probleme... Versteht mich bitte nicht falsch, ich mag den AQ nach wie vor, fliege zwei der Boards und hoffe mir zu Weihnachten einen Ladybird-M4 bauen zu können. Aber ich fühle mich mittlerweile echt unwohl wenn ich mit der Gefahr von Sachschäden oder über Wasser fliege.
Weitere Anstrengungen den AQ an sich so zuverlässig wie möglich zu machen (beides, Hard- und Software) empfinde ich subjektiv derzeit als wichtiger als ein weiterer (zusätzlich komplexer) Controll-Algorythmus, der eine "Black-Box" ist. Es ist da ja auch der Anspruch, dass der AQ einen kommerziellen Schwerpunkt haben soll...
Noch einmal betont: Diese Gedanken sind kein Zweifel an der Leistung der Teammitglieder oder dem Projekt an sich - nur wäre es schön die innovativen Teile dieses Projektes auf eine solide Basis stellen zu können.
Wenn wir über das Thema Sicherheit und Verlässlichkeit sprechen, habe ich leider mit dem AQ derzeit andere Probleme... Versteht mich bitte nicht falsch, ich mag den AQ nach wie vor, fliege zwei der Boards und hoffe mir zu Weihnachten einen Ladybird-M4 bauen zu können. Aber ich fühle mich mittlerweile echt unwohl wenn ich mit der Gefahr von Sachschäden oder über Wasser fliege.
Weitere Anstrengungen den AQ an sich so zuverlässig wie möglich zu machen (beides, Hard- und Software) empfinde ich subjektiv derzeit als wichtiger als ein weiterer (zusätzlich komplexer) Controll-Algorythmus, der eine "Black-Box" ist. Es ist da ja auch der Anspruch, dass der AQ einen kommerziellen Schwerpunkt haben soll...
Noch einmal betont: Diese Gedanken sind kein Zweifel an der Leistung der Teammitglieder oder dem Projekt an sich - nur wäre es schön die innovativen Teile dieses Projektes auf eine solide Basis stellen zu können.
Kann ich so nicht nach vollziehen. Sicherlich, haben wir nicht denn höchsten Verbreitungsgrad mit unserer FC, aber Angst damit zu fliegen habe ich keine.
Ich Empfinde unsere aktuellen FW extrem stabil.
Zwei "Fehlerquelle" die ich weiß, ist ein "falsch" kalibrierter esc32V2, und eine alte FW für den Esc32V2.
Hier kann es dazu kommen das ein Esc disarmt.
Ich Empfinde unsere aktuellen FW extrem stabil.
Zwei "Fehlerquelle" die ich weiß, ist ein "falsch" kalibrierter esc32V2, und eine alte FW für den Esc32V2.
Hier kann es dazu kommen das ein Esc disarmt.
Wie gesagt, bitte nicht als Angriff verstehen!
Passt eigentlich nicht in dieses Thema - ggf kann ich auch ein neues Thema aufmachen.
Ein Punkt ist, dass ich mit einer bestimmten Kombination (ultraESC, 4S) leider wiederholtes Freezen des AQ gehabt habe. Sowohl in der Luft, aber auch mit einem am Boden festgezurrten Copter - mit zwei AQ-boards, mit und ohne DIMU.
R0sewhite hat vor einiger Zeit ein ähnliches Verhalten beschrieben. Er führte es auf eine vermurkste Konfiguration zurück - verursacht durch eine schlechte Bluetoothübertragung. Einen Beweis gibts dafür aber wohl nicht. Falls dem tatsächlich so wäre, warum tritt dies dann nach einer zufälligen Zeitspanne beim Fliegen auf? Und es wäre ein echtes Sicherheitsrisiko, wenn eine korrupte Parameterübermittlung zunächst unbemerkt bleiben könnte und erst im Flug nach einer variablen/zufälligen Zeit zu einem Crash der firmeware führen könnte. Exisitiert da irgendeine Art Plausibilitätsprüfung/der empfangenen Daten, bevor sie verwendet/abgespeichert werden?
Ich habe den ersten Crash auf diese Weise auch gehabt, nachdem ich Parameter per Blutooth mit der AndroidApp verändert habe. Auch habe ich beobachtet, dass man es mit dieser Variante tatsächlich schaffen kann, dass Werte "verschwinden". Aber ich konnte insgesammt nur mehrere Crashs der Firmeware nach dem Wechsel auf 4S Batterien beobachten, allerdings teilweise auch mit laufenden Motoren!!! Mit 3S konnte ich das nicht reproduzieren, hatte über 50 Flüge ohne Absturz. Auch jetzt scheint mit 3S alles gut zu gehen, aber das ungute Gefühl bleibt. Hatte jetzt eine Weile keine Zeit mich drum zu kümmern, aber bevor ich dieses System wieder zum Filmen einsetzen kann, muss die Ursache hierfür gefunden werden! Ein "vermutlich war es das und jetzt geht funktioniert es" ist bei sicherheitskritischen Systemen - und dazu gehört jeder Copter der in Akkureichweite der Zivilisation geflogen wird - einfach nicht genug. Ich habe darüber auch vor einigert Zeit im englischen Forum geschrieben, uA hat sich da auch Jussi gemeldet, aber ein Grund konnte bisher nicht gefunden werden. Ein Rückwirken der ESC auf die FC kann natürlich auch nicht ausgeschlossen werden... ich konnte da aber noch nichts finden (incl. Scopen der Signalleitungen) bei dem ich sagen würde "das ist es gewesen".
Weitere Punkte:
Der EKF KANN wegdriften würde ich sagen - dies generell mit "du hast zu viele Vibrationen" abzutuen, finde ich ebenfalls etwas heikel. Was ist wenn bei einem perfekten Copter im Flug ein Propeller oder ein Lager kaputt geht? Das ganze scheint mit der DIMU etwas weniger heikel geworden zu sein - ausschließen würde ich das aber nicht wollen. Findet eine Überwachung des EKF im Flug statt? Sollte doch realisierbar sein - ggf wäre dafür ein Status über Telemetrie sehr schön.
Die Steckverbindung des Powerkabels... sollte man weglassen - Kabel besser anlöten - ist aber Kleinigkeit.
Redundante Spannungswandler (RECOM) für die MCU... Insbesondere bei der heiklen Montage derselbigen auf dem AQ.
...
@ Norbert: Ja, über dem Wasser ist immer etwas mehr Adrenalin, aber gerade über dem Wasser ermöglicht der Copter Aufnahmen die anders nicht gehen. Anderseits riskiere ich da im allgemeinen nur mein Gerät und keine Schäden Dritter ...
Passt eigentlich nicht in dieses Thema - ggf kann ich auch ein neues Thema aufmachen.
Ein Punkt ist, dass ich mit einer bestimmten Kombination (ultraESC, 4S) leider wiederholtes Freezen des AQ gehabt habe. Sowohl in der Luft, aber auch mit einem am Boden festgezurrten Copter - mit zwei AQ-boards, mit und ohne DIMU.
R0sewhite hat vor einiger Zeit ein ähnliches Verhalten beschrieben. Er führte es auf eine vermurkste Konfiguration zurück - verursacht durch eine schlechte Bluetoothübertragung. Einen Beweis gibts dafür aber wohl nicht. Falls dem tatsächlich so wäre, warum tritt dies dann nach einer zufälligen Zeitspanne beim Fliegen auf? Und es wäre ein echtes Sicherheitsrisiko, wenn eine korrupte Parameterübermittlung zunächst unbemerkt bleiben könnte und erst im Flug nach einer variablen/zufälligen Zeit zu einem Crash der firmeware führen könnte. Exisitiert da irgendeine Art Plausibilitätsprüfung/der empfangenen Daten, bevor sie verwendet/abgespeichert werden?
Ich habe den ersten Crash auf diese Weise auch gehabt, nachdem ich Parameter per Blutooth mit der AndroidApp verändert habe. Auch habe ich beobachtet, dass man es mit dieser Variante tatsächlich schaffen kann, dass Werte "verschwinden". Aber ich konnte insgesammt nur mehrere Crashs der Firmeware nach dem Wechsel auf 4S Batterien beobachten, allerdings teilweise auch mit laufenden Motoren!!! Mit 3S konnte ich das nicht reproduzieren, hatte über 50 Flüge ohne Absturz. Auch jetzt scheint mit 3S alles gut zu gehen, aber das ungute Gefühl bleibt. Hatte jetzt eine Weile keine Zeit mich drum zu kümmern, aber bevor ich dieses System wieder zum Filmen einsetzen kann, muss die Ursache hierfür gefunden werden! Ein "vermutlich war es das und jetzt geht funktioniert es" ist bei sicherheitskritischen Systemen - und dazu gehört jeder Copter der in Akkureichweite der Zivilisation geflogen wird - einfach nicht genug
. Ich habe darüber auch vor einigert Zeit im englischen Forum geschrieben, uA hat sich da auch Jussi gemeldet, aber ein Grund konnte bisher nicht gefunden werden. Ein Rückwirken der ESC auf die FC kann natürlich auch nicht ausgeschlossen werden... ich konnte da aber noch nichts finden (incl. Scopen der Signalleitungen) bei dem ich sagen würde "das ist es gewesen". Weitere Punkte:
Der EKF KANN wegdriften würde ich sagen - dies generell mit "du hast zu viele Vibrationen" abzutuen, finde ich ebenfalls etwas heikel. Was ist wenn bei einem perfekten Copter im Flug ein Propeller oder ein Lager kaputt geht? Das ganze scheint mit der DIMU etwas weniger heikel geworden zu sein - ausschließen würde ich das aber nicht wollen. Findet eine Überwachung des EKF im Flug statt? Sollte doch realisierbar sein - ggf wäre dafür ein Status über Telemetrie sehr schön.
Die Steckverbindung des Powerkabels... sollte man weglassen - Kabel besser anlöten - ist aber Kleinigkeit.
Redundante Spannungswandler (RECOM) für die MCU... Insbesondere bei der heiklen Montage derselbigen auf dem AQ.
...
@ Norbert: Ja, über dem Wasser ist immer etwas mehr Adrenalin, aber gerade über dem Wasser ermöglicht der Copter Aufnahmen die anders nicht gehen
. Anderseits riskiere ich da im allgemeinen nur mein Gerät und keine Schäden Dritter ...
Ah ja, jetzt erinner ich mich an diesen merkwürdigen Fall.
Die Vermutung mit den korrupten Daten kam von mir - weil ich mir ansonsten keinen Reim drauf machen konnte was da los war.
Klar, wenn sowas ungeklärt im Raum schwebt, wär ich auch vorsichtiger. Hatte das mal mit ner MultiWii: war ums Verrecken nicht rauszufinden, warum der im Schwebeflug plötzlich die Motoren abstellte. Zum Glück ist er immer auf den Kufen aufgeprallt - aber nach dem 3. Vorfall hatte ich die Faxen dicke...
Ok - jetz simmer vollends OT.
Die Vermutung mit den korrupten Daten kam von mir - weil ich mir ansonsten keinen Reim drauf machen konnte was da los war.
Klar, wenn sowas ungeklärt im Raum schwebt, wär ich auch vorsichtiger. Hatte das mal mit ner MultiWii: war ums Verrecken nicht rauszufinden, warum der im Schwebeflug plötzlich die Motoren abstellte. Zum Glück ist er immer auf den Kufen aufgeprallt - aber nach dem 3. Vorfall hatte ich die Faxen dicke...
Ok - jetz simmer vollends OT.
Tja, kann halt viele Ursachen haben - habe jetzt die firmeware neu geflasht und das Blutooth-Modul komplett weggelassen, konnte damit tatsächlich bereits 6 Flüge a 10 Minuten mit 4S ohne einen Zwischenfall absolvieren. Das deutet zwar auf die Sache mit korruppten Parametern hin - ABER ist halt kein Beweis. Ist halt so die Sache mit der Statistik. Auf dem sicheren Flugplatz kann ich damit so jetzt gut rumfliegen - aber halt kaum wo anders. Und wenn es tatsächlich die Parameter sind - dann würde ich die FW nicht als robust bezeichnen.
Realistisch betrachtet ist bei mir die FC derzeit auf jeden Fall die Komponente mit der mit großem Abstand höchsten Wahrscheinlichkeit eines möglichen Fehlers. Und dat iss nich jut ... bzw. ist sehr schade. Würde es immer noch gerne vermeiden, auf eine andere FC ausweichen zu müssen...
Realistisch betrachtet ist bei mir die FC derzeit auf jeden Fall die Komponente mit der mit großem Abstand höchsten Wahrscheinlichkeit eines möglichen Fehlers. Und dat iss nich jut ... bzw. ist sehr schade. Würde es immer noch gerne vermeiden, auf eine andere FC ausweichen zu müssen...
@phynix: Also bei mir blieb es bei den beiden Einfrier-Vorfällen direkt nach der Parametrisierung via Bluetooth. Seitdem ich neu geflasht habe, läuft die Kiste brav, wie bisher jeder AQ bei mir.
Ich hab das Problem der Datenkorrumption auch mit anderen besprochen: Es ist zwar unwahrscheinlich, weil Checksummen übermittelt werden, doch man kann es nicht definitiv ausschließen.
Da ich darüber hinaus festgestellt habe, dass Graupner-Sender wahre Strahlenschleudern sind und dies der einzige Copter ist, der zu Telemetrie-Testzwecken mit einem Graupner-Sender geflogen wird, verzichte ich bei diesem Copter einfach auf die Konfiguration via BT und nutze die altmodische USB-Kabel/FTDI-Methode. Ist ein Copter einmal eingeflogen, muss man ja eh höchst selten etwas an den Parametern ändern. Bei mir ist es eigentlich nur ab und zu der Throttle Factor, wenn sich das Payload im Gimbal drastisch ändert.
Ich hab das Problem der Datenkorrumption auch mit anderen besprochen: Es ist zwar unwahrscheinlich, weil Checksummen übermittelt werden, doch man kann es nicht definitiv ausschließen.
Da ich darüber hinaus festgestellt habe, dass Graupner-Sender wahre Strahlenschleudern sind und dies der einzige Copter ist, der zu Telemetrie-Testzwecken mit einem Graupner-Sender geflogen wird, verzichte ich bei diesem Copter einfach auf die Konfiguration via BT und nutze die altmodische USB-Kabel/FTDI-Methode. Ist ein Copter einmal eingeflogen, muss man ja eh höchst selten etwas an den Parametern ändern. Bei mir ist es eigentlich nur ab und zu der Throttle Factor, wenn sich das Payload im Gimbal drastisch ändert.
japp, ich fliege auch mit der Hott -wie auch damals geschrieben kann es somit schon sein, dass der Hott-Sender die Blutooth Verbindung stört. Deswegen habe fliege ich derzeit ja auch testweise mal ohne jemals einen Telemtriesender angeschlossen zu haben. Wie gesagt funktioniert auf diese Weise bisher auch alles. ABER was mich bei mir daran noch etwas irritiert ist:
- Probleme gibts erst nach einer variablen Zeitspanne plötzlich im Flug, unabhängig vom Flugmodi. Warum nicht unmittelbar beim Booten, Armen, Losfliegen, Modi-Wechsel? Sollte sowas nicht am ehesten bei einem Zustandswechsel Probleme machen?
- Bei mir ist ein Crash der FM nur bei tatsächlich laufenden Motoren aufgetreten. Nicht im disarmed, nicht im armed mit abgezogenen ESC
- Habe das Problem erst bemerkt, als ich auf 4S gewechselt habe. Mit 3S über ein halbes Jahr lang keine Probleme mit der FW gehabt - trotz Nutzung von Hott sowie Blutooth für Parametertuning
- Falls dies das Problem sein sollte, dann tritt es auf jeden Fall keinesfalls nur sehr selten auf - hatte es immerhin mit zwei AQ-Boards! Dann würde ich den Sinn der Checksumme nicht verstehen bzw es gäbe beim Verarbeiten der Empfangenen Parameter in der FW Optimierungspotetial
Wenn jemand zu diesen Punkten etwas erklären kann, wäre ich sehr dankbar. Wie gesagt, es geht mir darum die ursache zu finden, nicht den AQ schlecht zu machen.
Sobald ich dazu komme, kann ich ja nochmal versuchen, Fehler im Parametersatz auf diese Weise zu provozieren.
Es scheint aber auf jeden Fall auch so, dass die ultraESC Spannungsspikes in der Signalleitung erzeugen. Bisher konnte ich diese aber noch nicht in Verbindung mit einem FW-Crash bringen. Habe aus Sicherheitsgründen aber auch schon mal über eine galvanische Trennung dieser Leitungen nachgedacht ... oder zumindest eine Schutzdiode. Ist so etwas zufällig in der Hardware bereits integriert?
- Probleme gibts erst nach einer variablen Zeitspanne plötzlich im Flug, unabhängig vom Flugmodi. Warum nicht unmittelbar beim Booten, Armen, Losfliegen, Modi-Wechsel? Sollte sowas nicht am ehesten bei einem Zustandswechsel Probleme machen?
- Bei mir ist ein Crash der FM nur bei tatsächlich laufenden Motoren aufgetreten. Nicht im disarmed, nicht im armed mit abgezogenen ESC
- Habe das Problem erst bemerkt, als ich auf 4S gewechselt habe. Mit 3S über ein halbes Jahr lang keine Probleme mit der FW gehabt - trotz Nutzung von Hott sowie Blutooth für Parametertuning
- Falls dies das Problem sein sollte, dann tritt es auf jeden Fall keinesfalls nur sehr selten auf - hatte es immerhin mit zwei AQ-Boards! Dann würde ich den Sinn der Checksumme nicht verstehen bzw es gäbe beim Verarbeiten der Empfangenen Parameter in der FW Optimierungspotetial
Wenn jemand zu diesen Punkten etwas erklären kann, wäre ich sehr dankbar. Wie gesagt, es geht mir darum die ursache zu finden, nicht den AQ schlecht zu machen.
Sobald ich dazu komme, kann ich ja nochmal versuchen, Fehler im Parametersatz auf diese Weise zu provozieren.
Es scheint aber auf jeden Fall auch so, dass die ultraESC Spannungsspikes in der Signalleitung erzeugen. Bisher konnte ich diese aber noch nicht in Verbindung mit einem FW-Crash bringen. Habe aus Sicherheitsgründen aber auch schon mal über eine galvanische Trennung dieser Leitungen nachgedacht ... oder zumindest eine Schutzdiode. Ist so etwas zufällig in der Hardware bereits integriert?
