Zum Inhalt wechseln


Foto

Langflug-Kopter für 1.1Kg Nutzlast

eigenbau modellbau multicopter

  • Bitte melde dich an um zu Antworten
384 Antworten in diesem Thema

#376 el Kopto

el Kopto
  • 2.624 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 27. November 2018 - 12:24

Ich denke auch, wir sollten hier die Spekulationen mal etwas runterfahren und uns auf das Sammeln von Fakten konzentrieren. Ob und welchen Anteil in der Nähe befindliche Sender (z.B. als Trigger) hatten, ist weiterhin unklar, muss aber im Auge behalten werden. Der dritte Fall (in Isreal) berichtete auch von einer Radiostation in 1-2 km Nähe. Ein vierter Fall hatte das Phänomen mit einer Futaba-Fernsteuerung - insofern also schon mal kein zwingender Zusammenhang mehr zur Taranis und FrSky Empfängern. Es gibt Anzeichen dafür, dass es im Code des HAL (Hardware Abstraction Layer) begründet ist.
 
Auch bei DJI gab und gibt es immer mal wieder Bugs, die ihren Weg bis zum End-User finden. Zuletzt kam eine Reihe von M210 runter, weil die Software für die "intelligent battery" einen Bug hatte. Natürlich kann man für seine Projekte einen Flightcontroller nehmen, der mittlerweile 5 Jahre alt ist und seit Jahren kein Software-Update mehr bekam. Man ist dann halbwegs vor neu eingebauten Bugs gefeit, profitiert aber auch nicht von neuen Features. Für einen Kopter, der sich einfach nur möglichst lange in der Luft halten und ein bisschen herumcruisen soll, ist eine Naza M V2 weiterhin eine brauchbare Wahl, sofern man sich nicht nennenswert mit Parametrisierungen befassen möchte. Es kommt eben immer darauf an, was man damit sonst noch vor hat.

EDIT:
 
Das macht Hoffnung: https://discuss.ardu...hawk-4/35537/23
 

I have now managed to reproduce the problem with Copter-3.6.2 stable on a Pixhawk4.
The problem does not happen with the ChibiOS based IO firmware. I will see if I can bring a fix into the stable release.


EDIT 2:

 

Synosystems / Unirobotics, die ich zu dem Problem ebenfalls kontaktiert hatte, hat nun auch von Holybro eine Rückinfo bekommen und versendet gerade an Pixhawk 4 Kunden einen Fix auf Basis Arducopter 3.6.1. Ob er an derselben Stelle ansetzt, wie der Fix von Tridge (ArduPilot Forum), wäre noch zu prüfen.

 

Gut ist, dass das Ganze nun (hoffentlich) so schnell zur Behebung kam. Ärgerlich ist allerdings, dass Holybro wohl schon vor Wochen auf ein mögliches Problem bei Nutzung von S-Bus im Zusammenhang mit Ardupilot aufmerksam machte, die Händler aber erst jetzt mit einem Fix versorgt werden, nachdem sich die Fälle nun offenbar häufen.


Bearbeitet von el Kopto, 27. November 2018 - 14:07.

  • fingadar gefällt das

#377 Upgrade 08/15

Upgrade 08/15
  • 518 Beiträge

Geschrieben 27. November 2018 - 20:07

Guten Abend miteinander,

 

So wie es im Moment aussieht, handelt es sich um einen Software-Bug in der Arducopter-firmware für chibiOs. 

Holybro wusste anscheinend bereits über diesen schwerwiegenden Bug bescheid, war aber nicht der Meinung, man müsse direkt die Käufer informieren.

 

Ich bin mir noch nicht sicher, wie ich weiter vorgehen werde. Das Vertrauen in den Pixhawk 4 ist dahin, zudem hat der Kopter eine Kopflandung hingelegt - ich weiss nicht, inwiefern das GPS Modul oder der Flugkontroller dabei beschädigt wurden. Aber bis auf weiteres fehlen mir Zeit (& Motivation & Geld) um den Kopter zu Testen, defekte Teile neu zu bestellen, reparieren, Testflüge zu unternehmen usw. 

 

Wie erwähnt bin ich kein Fan von den DJI Produkten, aber wenn man bedenkt, dass 1) Holybro als Hersteller seine Kunden nicht über einen schwerwiegenden Bug informiert hat und 2) ein solch schwerwiegender Softwarefehler in die 'Stable' Variante der Arducopter-Firmware gelangt ist, gibt mir schon zu denken. Will ich so ein Produkt auf einem Kopter in der Gewichtsklasse haben?

Mal ganz abgesehen davon, dass man mit Ardupilot & Pixhawk 4 jeglichen Anspruch auf finanzielle Entschädigung bei einem Software/Hardware-Bug sowieso vergessen kann. Ich nehme an, bei DJI sähe das anders aus.

 

Was Deine Tests angeht schlage ich vor, den Kopter mit Tape oder Klettbändern oder Kabelbindern an einer gefüllten Limokiste festzumachen. Da ist genug Bodenfreiheit für den Abwind, und das ist zum Abheben zu schwer. Du kannst Dann alle Tests inklusive einer vollständigen Akkuentladung "testfliegen". Und zwar mit Rotoren!

Wenn das 2-3 mal trotz manuellem Wackeln an allen Kabeln und Steckern problemlos durchläuft und das Log keine Auffälligkeiten aufweist, dann sollte das System eigentlich flugtauglich sein.

So mache ich das immer, wenn ich was völlig Neues gebaut habe, das bisher ohne vergleichbare Flugerfahrung ist - z.B. nach Systemwechseln.

Diese Methode hört sich auf jeden Fall gut an. Vermutlich werde ich dann, wenn ich den Kopter wieder flugbereit habe, so vorgehen.


Bearbeitet von Upgrade 08/15, 27. November 2018 - 21:14.


#378 fingadar

fingadar
  • 739 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 27. November 2018 - 21:06

Wieso habe ich das nur geahnt?
 

Wie erwähnt bin ich kein Fan von den DJI Produkten, aber wenn man bedenkt, dass 1) Holybro als Hersteller seine Kunden nicht über einen schwerwiegenden Bug informiert hat und 2) ein solch schwerwiegender Softwarefehler in die 'Stable' Variante der Arducopter-Firmware gelangt ist, gibt mir schon zu denken. Will ich so ein Produkt auf einem Kopter in der Gewichtsklasse haben?


Zu Beginn des Projekts:
 

Du wirst da von Ardupilot-Seite nicht anderes hören. Du warst Doch sicher derjenige, der auch schon von Matt im Discuss die gleiche Antwort erhalten hat, die Du auch schon von mir bekommen hast: ChibiOS, und damit erst recht die Unterstützung vom Pixhawk4 ist derzeit noch als experimentell anzusehen. Der Produktiveinsatz wird derzeit von den Devs noch nicht empfohlen und erfolgt auf eigene Gefahr. Egal, was manche hier sagen. [...]

Ob Du Deinen neuen Kopter mit nicht gerade geringem finanziellen und zeitlichem Aufwand damit ausstatten willst oder nicht, ist Deine Sache.

Ich würde mir bei dem ambitionierten Projekt keine weitere potentielle Fehlerquelle „Alpha/Beta-Flightstack auf neuem, wenig erprobtem Controller“ holen, sondern bei einer bewährten Kombi bleiben. Zumal Dir die Pixhawk4/Arducopter3.6dev/chibios-Kombination bei Deinem aktuellen Projekt derzeit faktisch keinerlei Vorteile bringen wird.


Und damit verabschiede ich mich hier.

Viele Grüße,
Stefan

#379 Upgrade 08/15

Upgrade 08/15
  • 518 Beiträge

Geschrieben 27. November 2018 - 21:23

Wir sprechen hier nicht mehr von einem 'Alpha/Beta-Flightstack' oder einem 'derzeit noch experimentellen System'. Auf dem Kopter war ein 'stable' Release der AC-Firmware. Den Pixhawk 4 gibt es nun seit wie lange? Ein halbes Jahr? Noch länger?

Wie du auch meinem Beitrag entnehmen kannst, sind meine Kritikpunkte nicht, dass es ein Problem mit einer experimentellen, total neuen Plattform gab sondern 1) dass nicht über den Bug informiert wurde, obwohl anscheinend bei Holybro schon bekannt und 2) dass solch ein Bug in eine stable firmware gelangt ist. 

 

 

Schönen Abend dir trotz des schnippischen Kommentars


Bearbeitet von Upgrade 08/15, 27. November 2018 - 21:25.


#380 el Kopto

el Kopto
  • 2.624 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 27. November 2018 - 21:41

So wie es im Moment aussieht, handelt es sich um einen Software-Bug in der Arducopter-firmware für chibiOs. 
Holybro wusste anscheinend bereits über diesen schwerwiegenden Bug bescheid, war aber nicht der Meinung, man müsse direkt die Käufer informieren.

 
Ich bin zwar genauso wenig amused und kann Deinen Frust verstehen. Bevor so pauschal verurteilt wird, muss man sich den Fall allerdings genauer anschauen.

  •  
  • Holybro als Hersteller hat keinen direkten Kontakt zu den Käufern, kann also allenfalls die Zwischen-Händler informieren. Ob, wann und in welcher Form das geschah, ist unbekannt und wir erfahren allenfalls die Darstellung eines Händlers.
     
  • Holybro liefert den Flightcontroller mit PX4. Wenn man sich da nun etwas anderes draufspielt, liegt das Schicksal dann auch nicht mehr so recht in deren Händen, bei Open Source Software noch weniger.
     
  • Der Händler hat darin dann auch praktisch keine Aktien mehr - wobei allerdings Synosystems in seinem Blog auf die Verfügbarkeit und erste positive Tests mit Arducopter hinwies, damit also zumindest ein Stück weit das Aufspielen der Arducopter Software mit motiviert hat - aber natürlich mit dem Hinweis, dass es sich noch um Beta-Software handelt...
     
  • Wenn ich es richtig verstanden habe, basiert der HAL (Hardware Abstraction Layer) derzeit noch gar nicht auf ChibiOS und wurde vermutlich für den Pixhawk 4 von Holybro beigesteuert - und damit sind sie dann doch wieder irgendwie mit drin.

Konkret schrieb "tridge":
 

One thing I would note is that it very hard to see how it could be a ChibiOS problem, as those copter releases do not use ChibiOS on the IOMCU. The IOMCU is a STM32F100 that does all the “main” output and is also responsible for RC input (including parsing of the SBUS signal that the X8R will be producing). The firmware running on the IOMCU is identical to the one used for copter stable releases running NuttX.
In master and for the next major release of copter (the 3.7.x release) we have changed that IOMCU firmware to be based on ChibiOS, and we have rewritten the SBUS parsing code. That does in fact make SBUS parsing more robust as it adds parity checking on the UART (a feature that NuttX doesn’t support).

 
Die noch auf NuttX basierenden Stable Releases müssten also genauso betroffen sein. Theoretisch könnte auch PX4, das ebenfalls noch auf NuttX basiert, betroffen sein (sofern sie den gleichen Code verwenden), ist es aber laut Hersteller nicht.
 
Vielmehr würde der Fix nun darauf hinauslaufen, dass auch dieser Layer anschließend auf ChibiOS basiert und hinsichtlich S-Bus Parsing stabiler wäre. Ob damit keine anderen, neuen Bugs reinkommen, garantiert Dir bei Open Source aber niemand...
 
Auf welche Art der von Holybro nun bereitgestellte Fix das Problem löst (Fix des alten, NuttX basierten Layers oder schon Austausch gegen den neuen ChibiOS basierten), wissen wir aktuell auch nicht.
 
Seit wann Holybro das (aus deren Sicht auch nur "potentielle" Problem) bekannt war und wie sie das letztlich kommuniziert haben, wäre interessant zu erfahren, wird aber auch nicht einfach sein.
 
Jedenfalls ist erkennbar, dass es bereits seit 02. November einen mutmaßlichen Fix gab, der nur bislang nicht ins Stable Release kam. Darüber entscheidet dann aber auch wieder nicht Holybro.
 

Ich bin mir noch nicht sicher, wie ich weiter vorgehen werde. Das Vertrauen in den Pixhawk 4 ist dahin, zudem hat der Kopter eine Kopflandung hingelegt - ich weiss nicht, inwiefern das GPS Modul oder der Flugkontroller dabei beschädigt wurden. Aber bis auf weiteres fehlen mir Zeit (& Motivation & Geld) um den Kopter zu Testen, defekte Teile neu zu bestellen, reparieren, Testflüge zu unternehmen usw.

 
Wie oben schon geschrieben, ist die Sache komplizierter und welchen Anteil Holybro bzw. der Pixhawk 4 an dem Verhalten haben, ist nicht eindeutig.
 
Das GPS Modul selbst kann sicherlich einiges ab. Der Mast wird sicherlich hin sein und das Kabel müsste man auf jeden Fall überprüfen.
 
Ich würde erst mal ein paar Nächte drüber schlafen und dann auf Basis der Sachlage neu entscheiden. Wenn das Vertrauen so angeschlagen ist, bleibt natürlich immer noch der Rückzug auf einen schon länger im Markt befindlichen Pixhawk (z.B. dem Cube 2.1) und einem älteren AC Release. Beim Cube kann aber auch wieder das Modul, wo er drauf steckt, eine Macke haben oder das GPS Modul, oder, oder, oder...
 

Wie erwähnt bin ich kein Fan von den DJI Produkten, aber wenn man bedenkt, dass 1) Holybro als Hersteller seine Kunden nicht über einen schwerwiegenden Bug informiert hat und 2) ein solch schwerwiegender Softwarefehler in die 'Stable' Variante der Arducopter-Firmware gelangt ist, gibt mir schon zu denken. Will ich so ein Produkt auf einem Kopter in der Gewichtsklasse haben?
Mal ganz abgesehen davon, dass man mit Ardupilot & Pixhawk 4 jeglichen Anspruch auf finanzielle Entschädigung bei einem Software/Hardware-Bug sowieso vergessen kann. Ich nehme an, bei DJI sähe das anders aus.

 
Zur Informationspolitik von DJI: Da gibt es auch genügend Beispiele, wo es nicht gerade optimal lief. Finanzielle Entschädigung bekommst Du auch von denen nicht. Allenfalls die konkrete Komponente von denen als Ersatz. Bei einem N3 also auch nur den N3 und nicht den ganzen Kopter samt Kamera. Nur sofern es ein RTF Kopter war, hast Du dann aber Glück und bekommst den Kopter komplett ersetzt, sofern der Fehler genügend klar auf DJI Seite lag. Da wir hier aber im Eigenbau-Forum sind, haben wir natürlich Gründe, warum wir keinen  RTF Kopter kaufen.
 

EDIT:


Du wirst da von Ardupilot-Seite nicht anderes hören. Du warst Doch sicher derjenige, der auch schon von Matt im Discuss die gleiche Antwort erhalten hat, die Du auch schon von mir bekommen hast: ChibiOS, und damit erst recht die Unterstützung vom Pixhawk4 ist derzeit noch als experimentell anzusehen.

 

Auch Stefan macht es sich damit vielleicht etwas zu einfach. Der Hinweis auf Beta Software war gerechtfertigt und kam auch von mir, aber der Bug ist auch im Dritten Stable Release noch enthalten und offenbar gar nicht im ChibiOS basierenden Teil enthalten, sondern auch schon in den noch auf NuttX basierten Releases.



#381 Upgrade 08/15

Upgrade 08/15
  • 518 Beiträge

Geschrieben 27. November 2018 - 21:51

Ich habe meinen Pixhawk 4 direkt bei Holybro bestellt (shop.holybro.com) also ohne Zwischenhändler. Mir ist durchaus bewusst, dass der Pixhawk 4 mit PX4 ausgeliefert wurde und nicht mit Ardupilot. Aber da wohl doch ein überwiegender Teil der nicht-forschenden Nutzer mit Ardupilot fliegen wird, sollte es aus meiner Sicht selbstverständlich sein, dass Holybro die Kunden bei einem solch relevanten Bug informiert (sofern sie tatsächlich schon davon wussten). 

 

Dass auch DJI nicht den ganzen Kopter ersetzen würde, bin ich mir bewusst. Aber ein ersetzter Flugkontroller - der ja den Absturz ausgelöst hat - wäre schon besser als nichts :)

 

 

Ich werde aber auf jeden Fall noch wie von Dir empfohlen abwarten, wie sich das ganze entwickelt bzw. ob/wie der Bug im Endeffekt gelöst wird. 



#382 el Kopto

el Kopto
  • 2.624 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 27. November 2018 - 22:14

Ich habe meinen Pixhawk 4 direkt bei Holybro bestellt (shop.holybro.com) also ohne Zwischenhändler. Mir ist durchaus bewusst, dass der Pixhawk 4 mit PX4 ausgeliefert wurde und nicht mit Ardupilot. Aber da wohl doch ein überwiegender Teil der nicht-forschenden Nutzer mit Ardupilot fliegen wird, sollte es aus meiner Sicht selbstverständlich sein, dass Holybro die Kunden bei einem solch relevanten Bug informiert (sofern sie tatsächlich schon davon wussten). 

 

OK, das ist was anderes. In dem Falle hätte in der Tat Holybro selbst eine Chance gehabt, Dich rechtzeitig zu informieren.

 

Dass auch DJI nicht den ganzen Kopter ersetzen würde, bin ich mir bewusst. Aber ein ersetzter Flugkontroller - der ja den Absturz ausgelöst hat - wäre schon besser als nichts :)

 

Wenn Dein Pixhawk 4 jetzt beschädigt sein sollte, würde ich davon ausgehen, dass Holybro den zumindest auch auf Kulanz austauscht. Wenn das Vertrauen in einen FC aber grundsätzlich gestört ist, nützt Dir ein neuer auch nicht mehr viel. Auch DJI wird Dir in den seltensten Fällen den tatsächlichen Grund für einen Absturz nennen, es sei denn, er ist klar auf Dein Verschulden zurückführbar gewesen. Bei den M200/M210, die aufgrund fehlerhafter Battery-Firmware runterkamen, dauerte es auch eine Weile, bis DJI dazu klar Stellung bezog und ein Update lieferte.


EDIT:

 

Wen das Thema "S-Bus Parsing" genauer interessiert:
Im Zuge der Entwicklung meiner BVLOS-Funklösung durfte ich mich damit auch genauer auseinandersetzen. Die Spezifikation ist unscharf und lässt (zu) viele Freiheitsgrade. Futaba, die es einführten, schickte darüber ursprünglich alle 14 ms ein Datenpaket, in neueren Versionen auch alle 7 ms. FrSky schickt alle 10 ms ein Paket. Mangels eindeutiger Marker kann man ein neues Paket nur an der "Lücke" im Bitstrom erkennen. Je kleiner die ist, umso größer die Gefahr, da etwas falsch zu interpretieren. Eine CRC8 oder CRC16 Prüfsumme, wie sonst in seriellen Protokollen üblich, gibt es auch nicht. Bleibt also lediglich die Auswertung der Parity Bits. Wenigstens das macht nun der ChibiOS Layer - und ist damit schon mal etwas besser gegen Parsing Fehler gehärtet, als der bisherige Layer der NuttX basierten Releases.

 

Des Weiteren gibt es dann noch die Verwirrung mit invertierten und nicht invertierten S-Bus Signalen. Eigentlich sollten sie invertiert sein, da der F4 das aber mit eigener Hardware nicht verarbeiten kann, braucht man entweder einen Inverter oder einen Receiver, der entegegen der Spezifikation nicht-invertierte S-Bus Signale schickt...



#383 WiSi-Testpilot

WiSi-Testpilot
  • 925 Beiträge
  • Ortwestliches Münsterland
  • Kopter mit N3 & A3,
    Videoübertragung: LB2 mit CrystalSky & Connex.
    Kameras: Gopro H3+, Sony RX0,
    Sony A 6000 (NIR, Vis & UV),
    Flir Vue Pro 336 (LWIR),
    Connex ProSight (NIR)

Geschrieben 06. Dezember 2018 - 19:52

Gerade habe ich das im DJI Forum gelesen (Pro Systems / Flight Controller). Scheint so, das der X8R S-Bus Unfug macht.
Graupner S-Bus und N3 habe ich den ganzen Sommer ohne Probleme geflogen.

I have an N3 connected via SBUS with an FrSky X8R receiver for a Taranis x9D plus radio. I am experiencing exactly the same phenomenon as David is seeing on the Dragonlink (SBUS is lost, switch to LB2, switch back to SBUS and its fine, switch off everything, switch on again and SBUS is lost again). Would really like to know how to solve it. Cheers.

Ich habe einen N3 über SBUS mit einem FrSky X8R-Empfänger für ein Taranis X9D Plus-Radio verbunden. Ich erlebe genau das gleiche Phänomen, das David auf dem Dragonlink sieht (SBUS ist verloren, wechselt zu LB2, wechselt wieder zu SBUS und dessen Feinabstimmung, schaltet alles aus, schaltet wieder ein und SBUS geht verloren). Würde wirklich gerne wissen, wie man es löst. Prost.


Viele Grüße,
Wilhelm
 



#384 Woga65

Woga65
  • 444 Beiträge

Geschrieben 06. Dezember 2018 - 22:27

Ich denke, dass Arducopter in absehbarer Zeit F.Port unterstützen wird, womit das Thema zumidest für User von dazu kompatiblen FC dann vom Tisch sein dürfte.

#385 el Kopto

el Kopto
  • 2.624 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 06. Dezember 2018 - 23:04

Gerade habe ich das im DJI Forum gelesen (Pro Systems / Flight Controller). Scheint so, das der X8R S-Bus Unfug macht.
Graupner S-Bus und N3 habe ich den ganzen Sommer ohne Probleme geflogen.

 

Ich sehe die Probleme nicht beim X8R, sondern darin, dass die S-Bus Spezifikation gewisse Freiräume lässt. Das Interesse von DJI, einen FC zu bauen, der alles, was sich innerhalb dieser Freiräume bewegt, zu unterstüzten, ist hingegen vergleichsweise gering. Die ziehen sich nur zu gerne darauf zurück, dass es ja mit der LB2 funktioniert...

 

Beim Pixhawk 4 kommen - jedenfalls bislang - auf FC Seite auch Konstellationen aus unglücklichem Hardware-Design und einer darauf unzureichend abgestimmten ArduCopter zusammen, die ebenso wenig auf den X8R geschoben werden können. Der Fix adressiert jetzt zumindest die Symptome, hoffentlich heilen sie auch bald die Ursache...







Auch mit einem oder mehreren dieser Stichwörter versehen: eigenbau, modellbau, multicopter

Besucher die dieses Thema lesen: 0

Mitglieder: 0, Gäste: 0, unsichtbare Mitglieder: 0