Hallo und Herzlich Willkommen im RC-DROHNEN-FORUM.
Wir sind ein unabhängiges, rein privat geführtes Forum zum Thema Multicopter (Drohnen) speziell für Luftbild-Aufnahmen und Technik für den privaten- und gewerbliche Piloten.
Ein lockerer, freundlicher Umgang gepaart mit Know-How, Hilfsbereitschaft und ein respektvolles Miteinander erwarten Dich hier.
Melde Dich kostenlos an, um alle Funktionen nutzen zu können. Wir freuen uns auf Dich!
Viel Spaß wünscht Dir das RCDF-Team.

Offizieller Partner des BVCP - Bundesverband Copter Piloten

Ungewolltes Update?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • JPG Bilder sind perfekt. Ich habe mir bisher sowieso nur JPG EXIF daten angesehen. Die EXIF Komponente, die ich in meinen Programmen verwende, kann keine RAW-Daten lesen oder schreiben, nur bei JPG.

      Man kann auch selber hineinschauen, wenn man die Bilder mit einem vernünftigen Texteditor (wie z.B. Notepad++) öffnet. Interessant sind (zusätzlichen) XMP-Daten.
      EXIF+XMP.png
      Hier steht zum Beispiel Blödsinn drin, denn mir kann keiner erzählen, dass der Kopter 94m unter dem Meeresspiegel gestartet ist, Geoid hin oder her.

      Gruß HE

    • Hallo,
      hab einen Testflug absolviert. Hochgefahren mit Modus manuell. Keine Fehlermeldung.Zusammenhang kann ich nicht beurteilen. Sauberer Flug. Standardmissionshöhe waren 150ft. RTL auf 98 ft.
      StartbildStart.JPGversäumt ein Screenshot zu machen. Höhe zeigte 0,8ft.

      2.JPG zu Bild 2.JPG

      3.JPGzu Bild 3.JPG

      Hab auch noch die Telemetriedaten von der ST16 angefügt.
      Hoffe h-elsner kann was mit anfangen.

      LG BOS Man
      Dateien

      • zu Bild 2.JPG

        (93,31 kB, 6 mal heruntergeladen, zuletzt: )

      • zu Bild 3.JPG

        (93,63 kB, 8 mal heruntergeladen, zuletzt: )

      • Telemetrie1.zip

        (1,79 MB, 3 mal heruntergeladen, zuletzt: )

      • Telemetrie1.zip

        (1,79 MB, 3 mal heruntergeladen, zuletzt: )

    • So richtig kann ich die Daten nicht zusammenbringen. Die Zeitstempel sind überall auf unterschiedlicher Basis (EXIF, TLOG und UTM).
      Aus Telemetrie:
      Höhe bei Null: -2.1m
      Absolute Gipfelhöhe: 89.3m
      Relative Gipfelhöhe: 91.5m
      "altitude_system": "WGS84"

      WSG84 in NHN:
      NHN (~EGM2008) = GPSaltitude (WGS84) - 36.1670m (ich rechne mal mit ~36m)
      ===============================
      Aus den Bildern:

      Start.JPG
      EXIF: 2021-02-01 12:16:28
      Lat: 54.3628358
      Lon: 13.6454525
      GPSAltitude: 37,24
      GPSAltitudeRef: Above sea level

      XMP:
      drone-yuneec:GPSAltitude="37.00"
      drone-yuneec:AboveHomeAltitude="0.14"

      Wenn ich den Geoid Korrekturwert von 36m von GPSAltitude abziehe, kommt das mit 1m NHN ungefähr hin.
      -------------------------------
      2.JPG
      EXIF: 2021-02-01 12:23:24
      Lat: 54.3643193
      Lon: 13.6489061
      GPSAltitude: 128,74
      GPSAltitudeRef: Above sea level

      XMP:
      drone-yuneec:GPSAltitude="128.00"
      drone-yuneec:AboveHomeAltitude="91.47"
      -------------------------------
      3.JPG
      EXIF: 2021-02-01 12:22:54
      Lat: 54.3643192
      Lon: 13.6489052
      GPSAltitude: 101,26
      GPSAltitudeRef: Above sea level

      XMP:
      drone-yuneec:GPSAltitude="101.00"
      drone-yuneec:AboveHomeAltitude="63.99"

      Fazit:
      Die GPS Altitude in den EXIF Daten und in den XMP-Daten der Bilder sind gleich.
      Die Differenzen zwischen relativer und absoluter Höhe bei den drei Bildern passen auch.
      Die relative Höhe (AboveHomeAltitude) sieht plausibel aus.
      Die GPSAltitude nicht.

      Hier nun folgendes. In den TLOG-Daten gibt es eine ganze Reihe von Höhenangaben. Diese stammen aus den MAV Messages:
      24 GPS_raw_int

      33 Global_pos_int

      141 Altitude


      Ich habe die mal in einer Tabelle zusammengestellt. Und da fällt mir auf, dass altitude_ams mit 96.72m anfängt und sich dann (GPS lock?) auf -2.39m korrigiert. Die altitude_monotonic fängt auch bei 96.72m an und addiert danach nur noch auf, korrgiert sich also nicht mehr. Und genau daraus scheinen die EXIF-Daten für Höhe genommen zu sein. Die sind damit falsch und folgen einem mehr oder weinger zufälligem Wert vor/bei der Initialisierung.

      2021-02-01 12-33-05.zip



      Blöd gelaufen. Yuneec oder wer auch immer die Kamera-FW gemacht hat, hat den falschen Wert aus den MAV Messages extrahiert (falscher Index in Message 141). Oder man hätte eine andere MAV-Message nehmen sollen (24 oder 33).


      Eigentlich eine Kleinigkeit. Vielleicht korrigieren die das noch. altitude_monotonic sollte man jedenfalls nicht nehmen.


      Gruß HE

    • h-elsner schrieb:

      JPG Bilder sind perfekt. Ich habe mir bisher sowieso nur JPG EXIF daten angesehen. Die EXIF Komponente, die ich in meinen Programmen verwende, kann keine RAW-Daten lesen oder schreiben, nur bei JPG.

      Man kann auch selber hineinschauen, wenn man die Bilder mit einem vernünftigen Texteditor (wie z.B. Notepad++) öffnet. Interessant sind (zusätzlichen) XMP-Daten.
      EXIF+XMP.png
      Hier steht zum Beispiel Blödsinn drin, denn mir kann keiner erzählen, dass der Kopter 94m unter dem Meeresspiegel gestartet ist, Geoid hin oder her.

      Gruß HE
      Es erstaunt mich immer wieder was so heute in den EXIF Daten an Infos zu finden ist
      Es ist ein leichtes bei der Aufnahme eines Fotos in der Drohne dem Bild sogar Scripte hinzuzufügen
      Dann heißt es Unsere Drohne gibt keine Daten weiter ..Das stimmt sogar Aber was macht das Bild auf dem Computer ?

    • h-elsner schrieb:

      Ich habe die mal in einer Tabelle zusammengestellt. Und da fällt mir auf, dass altitude_ams mit 96.72m anfängt und sich dann (GPS lock?) auf -2.39m korrigiert. Die altitude_monotonic fängt auch bei 96.72m an und addiert danach nur noch auf, korrgiert sich also nicht mehr. Und genau daraus scheinen die EXIF-Daten für Höhe genommen zu sein. Die sind damit falsch und folgen einem mehr oder weinger zufälligem Wert vor/bei der Initialisierung.
      Brillante Analyse! :thumbup: :thumbup: :thumbup:
      Dieser "Aufaddieren-Effekt" mit quasi zufälligen Ergebnissen innerhalb der Kameras wird wohl der Grund sein. Statt der "üblichen" 75 m hatte ja meine E10T 1225 m (!) und meine E90 120 m in die EXIF-Daten geschrieben...

    • BOS-Man schrieb:

      Vielen Dank für Deine Mühe,
      vr-pilot wollte ja mal KK kontaktieren. Mal sehen was dabei rauskommt.
      Hallo BOS-Man,

      aus KK gab es noch keine Antwort.
      Am Mittwoch-Nachmittag läuft das Yuneec-Webinar "The latest software solution to process 3D and ortho GIS data" zur neuen Photogrammetry-Software "PhotoMesh UAV". Da passt diese Thema ja "leider" nicht so gut hinein, aber so geht es halt nicht. Seit 3 Jahren liefern die EXIF-Daten der H520-Kameras zuverlässige Höhen über Meeresspeiegel (AMSL). Das ist (war) wirklich klasse und viel besser als die EXIF-Daten meiner Kameras "der großen Konkurrenz", die immer die Höhe über dem Startpunkt speichern. dash


      Meine Vermutung ist, dass alles getan wird um den H520E mit all seinen Neuerungen wie z.B. OFDM-Übertragung und RTK-Modul zum Laufen zu bekommen, und dabei der H520 "angeschossen" wird. ?(
      Das würde z.B. auch den im vorherigen OTA-Update aufgetretenen Kompass/GPS-Drift erklären. "Auffällig" war ja auch der neue (?) Hinweis im darauffolgenden OTA-Update im UpdatePilot: "H520 (Not For H520E)".

      Noch eine Vermutung: Ich nehme an, dass der von h-elsner in Post #64 entdeckte Grund für die falschen GPS-EXIF-Höhen mit der Übertragung der RTK-Daten auf die H520E-Kameras (und somit in die EXIF-Daten der Bilder auf der Speicherkarte) zu tun hat.
      Falls am Ende tatsächlich eine wiederkehrende Vermischung von Software- und Firmware-Updates für H520/H520E-Komponenten vorliegt, wäre das natürlich ein "mittleres Desaster"; reparabel aber lästig... hmm

      Habe mal bei MAVLink message #141 nachgesehen (mavlink.io/en/messages/common.html): search
      altitude_monotonic
      This altitude measure is initialized on system boot and monotonic(it is never reset, but represents the local altitude change). Theonly guarantee on thi s field is that it will never be reset and isconsistent within a flight. The recommended value for thi s field isthe uncorrected barometric altitude at boot time. This altitude willalso drift and vary between flights.

      altitude_amsl
      This altitude measure is strictly above mean sea level and mightbe non-monotonic (it might reset on events like GPS lock or when anew QNH value is set). It should be the altitude to which globalaltitude waypoints are compared to. Note that it is *not* the GPSaltitude, however, most GPS modules already output MSL by default andnot the WGS84 altitude.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von vr-pilot ()

    • vr-pilot schrieb:

      Statt der "üblichen" 75 m hatte ja meine E10T 1225 m (!) und meine E90 120 m in die EXIF-Daten geschrieben...
      Da hätte ich gern die TLOG Daten dazu, um die Aussage zu verifizieren.

      Du kannst das auch selber überprüfen, weil ich gestern eine Auswertung dazu in q500log2kml integriert habe (gerade erst hochgeladen und nur auf der Homepage, noch nicht in GitHub).
      Es gibt einen "geheimen" Button "Special" hinter dem sich die Auswertung verbirgt. Welche spezielle Auswertung sich hinter dem Button verbirgt, hängt davon ab, welches Problem gerade aktuell ist. Die Ausgabe der verschiedenen Höhenangaben aus der TLOG ist da also nicht für immer.

      Anleitung: Einstellungen > Diverse Einstellungen > In weitere Einstellungen klicken und Strg+S drücken. Der Button sollte jetzt zu sehen sein. Button anklicken und TLOG-Datei auswählen. Eine CSV-Datei wie in der Anlage oben wird erzeugt und zwar in dem Verzeichnis, wo auch die TLOG steht. Die CSV-Datei kann man sich in LibreOffice Calc ansehen (oder auch Excel, aber wer nimmt das noch :thumbdown: ).

      Man kann dann schön sehen, wie sich altitude_monotonic [141] verhält:
      monotonic.png

      Wenn wirklich die altitude_monotonic genommen wird, dann ist das ein systematischer Fehler, denn die Werte sagen genau das, was in der Beschreibung steht: "This altitude measure is initialized on system boot and monotonic (it is never reset, but represents the local altitude change)....". Und bei System boot haben wir noch keinen GPS Lock und somit invalide Daten.
      Aber vielleicht ist es auch ein Fehler, wenn der Startwert für altitude_monotonic von altitude_amsl übernommen wird und nicht von altitude_local. Denn hier wieder die Beschreibung: "... The recommended value for thìs field is the uncorrected barometric altitude at boot time...".

      Also wie man es auch dreht, hier werden von den vielen Altitudes die falschen Werte verwendet.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von h-elsner ()

    • h-elsner schrieb:

      vr-pilot schrieb:

      Am Mittwoch-Nachmittag läuft das Yuneec-Webinar
      Yuneec Webinar? Kann man da teilnehmen oder ist das geheim. Bei Events seh ich nichts auf der Homepage.
      Gruß HE
      Hallo HE,

      nein, "geheim" ist es sicherlich nicht. Ich habe irgendwann mal einen Newsletter abonniert (weiß nicht mehr ob auf der DE, US oder UK-Seite) und seitdem bekomme ich Infos zu neuen Produkten. (Seit 14. August 2020 sehr regelmäßig, siehe Liste unten)
      Ich hatte das auch schon mal bei einem Besuch in KK angesprochen, dass ich das Gefühl habe, dass viele Anwender da draußen wenig bis nichts von den Neuigkieten mitbekommen, da vieles aus dem Newsletter-Abo nicht auf der Internet-News-Seite erscheint:

      New release: H520E hexacopter (14. Aug. 2020)
      New standard solution for integrated, European drone tracking. (2. Sept. 2020)
      In Stock Now | H520 + E30Z: Unlimited details for professional use (8. Sept. 2020)
      New from Yuneec: The H520E RTK (30. Sept. 2020)
      YCAP News | Yuneec enters into Precision Agriculture (6. Okt. 2020)
      YCAP News | New Tethered system for the H520 and H520E (13. Okt. 2020)
      YCAP | Atmon FL, a mobile air analyzer for the H520 and H520E (20. Okt. 2020)
      The H520E-OFDM IN STOCK NOW (10. Nov. 2020)
      H520/H520E Payload options in stock now (27. Nov. 2020)
      New software solution for accurate data visualization (5. Dez. 2020)
      New Yuneec Maintenance Program (12. Jan. 2021)
      The H520E-OFDM and its thermal cameras in stock now (22. Jan. 2021)

      Der Link zum Mapping-Software-Webinar ist bezeichnet mit "Your Unique Join Link". Ist also nicht zur Weitergabe gedacht. Ob eine Registrierung jetzt noch funktionieren würde weiß ich nicht.
      Hier
      yuneec.com/de_DE/unternehmen/events.html
      lässt sich aber der YUNEEC-News-Letter für "jedermann" abonnieren.

      VG, Claus

      EDIT: Ulrich_W hat eben geschrieben, dass eine Anmeldung über FB möglich sei...

    • Ich habe nur noch Probleme mit dem Copter!

      Erst der Pre Flight Check, das hat sich aber sogut wie erledigt, jetzt fängt er an und verliert dauerhaft die Verbindung. Dann fängt er an in einer bestimmten Entfernung Kreise zu drehen und nimmt keine Steuerbefehle mehr an. Im RTH kann ich ihn meist zurück holen. Meistens mit der E90 Kamera
      Wer immer tut was er schon kann, bleibt immer das was er schon ist.

    • Ibdkduuweat schrieb:

      Ich habe nur noch Probleme mit dem Copter!

      Erst der Pre Flight Check, das hat sich aber sogut wie erledigt, jetzt fängt er an und verliert dauerhaft die Verbindung. Dann fängt er an in einer bestimmten Entfernung Kreise zu drehen und nimmt keine Steuerbefehle mehr an. Im RTH kann ich ihn meist zurück holen. Meistens mit der E90 Kamera
      Hi,

      das hört sich nicht gut an. Über eine schlechtere Verbindung nach dem zweiten OTA-Update (ca. 28.01.21) bei meinem ersten Flug mit der E90 hatte ich mich auch schon gewundert, wie hier schon im Punkt 1 beschrieben (hier der Post zum zweiten OTA-Update vom 30.01.2021):
      rc-drohnen-forum.de/thread/110…e/?postID=83810#post83810

      Das mit dem unkontrollierten GPS-Flug hatte ich davor beim ersten/älteren OTA-Update von ca. Mitte Januar 2021. Da half nur noch im Manual Mode zu landen.
      Diese Probleme (z.B. Kompass-Shift/Drift nach Kaltstart des Copters) waren für mich mit dem zweiten OTA-Update aber erledigt (hier der Post zum ersten OTA-Update vom 16.01.2021):

      rc-drohnen-forum.de/thread/110…e/?postID=83413#post83413

      Hast Du schon das zweite OTA-Update (ca. 28.01.21) installiert? Da sollte das unkontrollierte Driften entfallen und dafür dann z.B. die EXIF-Daten BEI DER GPS-Höhe falsche Werte aufweisen.

    • h-elsner schrieb:

      Da hätte ich gern die TLOG Daten dazu, um die Aussage zu verifizieren.
      Hallo HE,

      vielen Dank für Deine Erläuterungen, Links und Tests! :thumbup:
      Gerade das Thema GPS-Höhe und der Unterschied zwischen Ellipsoid- und Geoid-Höhe ist ja recht komplex. In der Theorie wurde die WGS-84-Höhe ja als AMSL-Annäherung gedacht. In der Praxis sorgen die Erhebungen- und Absenkengung der lokalen Meerersspiegel durch Schwerkrafteffekte jedoch häufig zu Abweichungen vom "Ideal-Ellipsoid". Somit sind die WGS-84-Höhen-Daten und lokale N.N.-Höhen nur selten "identisch". Diese Abweichungen fallen natürlich gerade bei den Höhen-Daten beim Start auf.
      Meine Geoid-Höhe (AMSL) am Startplatz soll 34 m betragen. Meine EXIF-GPS-Höhen-Daten beim Start liegen zwischen 28 m und 37 m, also inneralb der Toleranz von +/-5 m, die für "Drohnen-GPS-Empfänger" angenommen wird. Deshalb dachte ich bereits, dass der H520-Kompass zu den GPS-Modulen gehören könnte, wie bei MAVLink unter ALTITUDE #141 altitude_amsl beschrieben wird:
      "Note that it is *not* the GPS altitude, however, most GPS modules already output MSL by default and not the WGS84 altitude."

      Weil Du an Deinem Standort jedoch Abweichungen von lokal-MSL zu WGS-84-Höhe bis 41 m hast, kann ich mich natürlich auch irren, weil bei mir zufällig Geoid und Ellipsoid genau aufeinanderliegen? (habe noch nicht nachgesehen)
      Hast Du einen H480/Q500? Vielleicht liefern diese GPS-Module ja auch "WGS84 altitude" und das vom H520 "MSL by default"? hmm



      h-elsner schrieb:

      Da hätte ich gern die TLOG Daten dazu, um die Aussage zu verifizieren.

      Du kannst das auch selber überprüfen, weil ich gestern eine Auswertung dazu in q500log2kml integriert habe (gerade erst hochgeladen und nur auf der Homepage, noch nicht in GitHub).
      Es gibt einen "geheimen" Button "Special" hinter dem sich die Auswertung verbirgt. Welche spezielle Auswertung sich hinter dem Button verbirgt, hängt davon ab, welches Problem gerade aktuell ist. Die Ausgabe der verschiedenen Höhenangaben aus der TLOG ist da also nicht für immer.

      Anleitung: Einstellungen > Diverse Einstellungen > In weitere Einstellungen klicken und Strg+S drücken. Der Button sollte jetzt zu sehen sein. Button anklicken und TLOG-Datei auswählen. Eine CSV-Datei wie in der Anlage oben wird erzeugt und zwar in dem Verzeichnis, wo auch die TLOG steht.

      Ich habe Version 4.7 von "q500log2kml". Da kommt unter Diverse Einstellungen der "Special-Button" wohl noch nicht. Ich lade mir später die neueste Version von Deiner Hompage herunter und schaue bei mir noch mal in die Daten rein.

      Von den drei Flügen am Samstag wurde nur ein TLOG-File geschrieben:

      2021-01-30 16-39-22.zip



      Vielen Dank!

      VG, Claus

    • BOS-Man schrieb:

      Vielen Dank für Deine Mühe,
      vr-pilot wollte ja mal KK kontaktieren. Mal sehen was dabei rauskommt.

      Schönen Abend
      Hallo BOS-Man,

      habe gestern diese Antwort aus KK bekommen:

      Sehr geehrter Herr Küpper,
      im folgenden Link finden Sie Beta-Firmware, welche das Problem lösen sollte. Diese Firmware wird dann auch in Kürze offiziell veröffentlicht.
      XXX
      Diese Firmware muss einfach auf eine leere Micro SD kopiert werden, in die Kamera eingelegt werden und dann die Drohne eingeschaltet werden. Die Kamera LED wird nach kurzer Zeit lila blinken, was bedeutet „ein Update wird aufgespielt“ … sobald die Kamera aufhört zu blinken, kann die Drohne rebootet werden. Die Kamera hat jetzt die 0.2.62_A installiert, bitte NICHT mit dem Update Pilot ein Downgrade durchführen, es kann sein dass dabei das Gimbal geleert wird, dann müssen wir die Kamera bei uns neu aufsetzen.

      Das habe ich vorerst einmal nicht gemacht, weil mir diese "Gimbal-Entleerung" schon mal im letzten Jahr vor Ort in KK erklärt wurde. Man darf bei diesen SD-Zwischen-Patches keine anderen Up-/"Down"-dates mehr (z.B. aus Versehen) durchführen. Es scheint ja eine Lösung zum EXIF-Daten-Höhen-Fehler auf dem Weg zu sein.
      Der o.g. Patch 0.2.62_A bezieht sich zudem auf die E10T (offiziell aktuell 0.2.59_A) und da sind mir die korrekten EXIF-Daten-Höhen viel weniger wichtig als bei der E90 (Photogrammetry).


      VG, Claus

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von vr-pilot ()

    • Ibdkduuweat schrieb:

      Ich habe nur noch Probleme mit dem Copter!

      Erst der Pre Flight Check, das hat sich aber sogut wie erledigt, jetzt fängt er an und verliert dauerhaft die Verbindung. Dann fängt er an in einer bestimmten Entfernung Kreise zu drehen und nimmt keine Steuerbefehle mehr an. Im RTH kann ich ihn meist zurück holen. Meistens mit der E90 Kamera

      Hast du dabei eine SD Karte in der E90 ? Wenn ja, mal ohne versuchen. Hört sich blöd an, aber ich hatte letztens einen Kunden der massive Probleme mir der Verbindung hatte und letztendlich lag es an einer defekten SD Karte oops

      Habe ich schon erwähnt das unsere H520 nach dem letzten Update absolut problemlos fliegen? :D

      Gruß
      Uli