GPS Code Änderungen

Also, wenn Dein Flashen mit der GPS FW AXN1.51_2722_3329_384.1151100.5.bin geklappt hat, brauchst Du die config.h der test03 nicht zu ändern. Die ist schon passend konfiguriert. In Deiner GUI bekommst Du sofort Deine Koordinaten angezeigt, sobald ein Sat FIX vorliegt (egal, was bei MINSAT steht). Mittlerweile habe ich ein mögliches Problem in der test03 gefunden und korrigiert. Das war wieder ein Gruss der bescheidenen Dokumentation. Nach dem Originaldokument (CustomizeFunctionSpecificationv16.doc) gibt es nur 3 Fixtypes im Binärmodus (0x01 GPS no fix 0x02 GPS 2D fix 0x03 GPS 3D fix). Deswegen frage ich auch nur diese 3 ab. Nach Infos der APM Leute gibt es aber mehr: FIX_NONE = 1, FIX_2D = 2, FIX_3D = 3, FIX_3D_SBAS = 7. So langsam geht mir diese Stückwerkinformation auf den S...enkel. Ich habe der FW zwar keine höhere Nummer als 3 entlocken können, aber könnte sein, wer kann das schon mit Bestimmtheit sagen. Deswegen habe ich die Abfrage geändert: Ein 3dfix liegt vor, wenn der Rückgabewert grösser als 2 ist. Dann kann die FW noch ein paar unbekannte Nummern senden, das ist dann egal.
Die Codeänderung sieht dann so aus:
Zeile 1121
Original:
Änderung:
Ich habe das ganze mal als test03b angehängt, damit man nicht herumfummeln muss.
Mittlerweile habe ich hier noch andere GPS FW im Test, die scheinen mir aber auch nicht mehr zu bringen, ausser, dass sie erst mal inkompatibel sind....

LG
Rob

Hi!
Jetzt kommt ein kleines Info Update:

Die APM Leute haben mir zwar kein Tshirt geschickt, aber mehrere (neue) FW für den MTK3329. Die mir heute zugemailt wurde, hat es in sich! Die Genauigkeit ist um eine Stelle erhöht (!), DGPS Fix erfolgt eigentlich schon automatisch, das Nav Speed threshold ist leider per default auf 1 meter, das habe ich direkt auf 0 m gesetzt, damit möglichst jede Bewegung erkannt wird und der Spikefilter auch Arbeit bekommt . Mit 8-9 Satelitten habe ich bislang die beste Genauigkeit überhaupt IM STAND bekommen. Über 16 Minuten (Beobachtungszeitraum) wurde mir quasi genau die Stelle angezeigt, an der der Copter stand. Abartig. Der Treiber ist inkompatibel zu dem bestehenden Binärprotokoll, da natürlich die erhöhte Genauigkeit ausgelesen werden muss und ein anderes Syncwort verwendet wird (Kennung für Autodetect). Meine selbstgestrickter Parser des Binärprotokolls ist aber ruck zuck angepasst, hat schon etwas für sich... Am Montag soll die FW offiziell von APM Seite released werden, wenn die Testläufe positiv verlaufen. Sie wird den schmucklosen Namen 1.9 tragen. Da mich die FW überzeugt hat, und ich davon ausgehe, dass die APM Tester zu dem gleichen Ergebnis kommen werden, wollte ich schon die passende I2C Version liefern, damit es am Montag direkt los gehen kann. Es handelt sich um die test03b von oben, diese Version hier ist allerdings NICHT mehr kompatibel zu der Bandi FW (AXN1.51_2722_3329_384.1151100.5.bin) sondern nur noch zu der kommenden 1.9. Posten darf ich die FW leider nicht.
Auf die Gefahr hin, dass es die FW nicht schaffen sollte, gibt es hier schon mal EXKLUSIV das passende I2C Programm!!! APM user werden die kommende FW erst mit der neuen arducoptersoft verwenden können.
Damit dürften wir hier die ersten auf der Multiwii sein, die in den Genuss einer höheren Genauigkeit auf MTK 3329 Modulen kommen!

LG
Rob

In das Thema GPS kommt ja richtig Schwung rein, super. Ich bin heute leider nicht mehr zum testen gekommen. Hat sich eigentlich das Blinkmuster vom GPS durch die Firmware geändert?

Gruss Ralf

@RalfB:
Irgendwie (http://diydrones.com/forum/topics/mysterious-waas-on-sequence-in-current-ap-gps-mtk-common-h) habe ich in Kalifornien ein paar Leute dazu gebracht, sich den MTK noch mal genauer anzuschauen. Schliesslich steckt der fest verlötet auf den meisten APM 2.0.
Der LED code ist unverändert. Vielleicht blinkt er durch die MINSAT 7 Definition unter 7 sats etwas anders? Auf das Blinken habe ich noch nicht so geachtet...
Die Sache mit den verschiedenen Sat Anzahlen für verschiedene Funktionen habe ich erst mal nicht mehr implementiert.
LG
Rob

Servus miteinander,
ich verfolge das ja auch schon die ganze Zeit, aber vor lauter Fachbegriffen und FW Versionen, Binärprodokollen, usw. habe ich im Kopf meinen "SatFix" verloren.
Ich habe den FMP 04 (seriell), welcher einen MTK3329 Chip (ist doch ein Chip?) hat. Zumindest habe ich die FW (auf der Flyduinoseite verlinkt) mal geflasht, damit ich 10 Hz einstellen konnte.
Wenn ich jetzt zum Testen (wenns Wetter wieder besser wird) mit einsteigen will, was muss ich zusammengefasst alles ändern?
Geht das überhaupt mit dem FMP04? Und Was muss dem im Arduino Sketch alles gemacht werden?
Ich habe z.Z. Die "NewBaroPID_Vario04_Final" drauf und würde sie auch gerne weiterfliegen. Müssen jetzt mehrere Dateien mit in den Sketch?
Wäre Super, wenn mal einer ne kleine Zusammenfassung machen könnte.
Gruß Jens

Moin Jens, soweit ich das weiß hat Roberto sich erstmal auf den I2C Code Konzentriert und es noch nicht für die Serielle nutzung eingebunden. Macht find ich bis jetzt auch noch nicht soviel sinn. Mal schauen was die nächste Zeit bringt, bis jetzt ist es immer noch ne Baustelle und daher besser wenn man erstmal die neuen Codes extern auslagert

Gruß Micha

Hi!!

@Bigbretl: Die NewBaroPID_Vario04_Final fliege ich auch !

Wenn Du ein MTK 3329 Modul direkt am Mega betreibst, kannst Du die Änderungen noch nicht testen. Das Umsetzen auf ein Megaboard wird mir, mangels Hardware auch nicht leicht fallen. Aber weisseruebe ist da schon dran!
Da in den offiziellen mwii codes (auch DEV) das mtk Binärprotokoll überhaupt nicht unterstützt wird (hab ich zumindest nicht gefunden), musst Du erst mal auf NMEA (5/10Hz) weiter brennen.

DerJunior: Da hast Du schon Recht, so ein externes Modul hat schon ein paar Vorzüge.

Die neue FW findet hier auch schon Erwähnung: http://code.google.com/p/ardupilot-...f09d722a75795656a98da3d6b&name=ArduCopter-2.9

Ich denke, es wird eine Verbesserung bringen. Erst mit dieser FW hat man einen Genauigkeitsvorteil.

Hier habe ich noch ein grobes Schema der "Baustellen" angehängt... vielleicht klärt sich dann manches von selbst.


LG

Rob

Naja....ganz so konkret ist es noch nicht. Ehrlich gesagt warte ich momentan erstmal ab, bis das ganze ein wenig weiter gekommen ist. Bei den aktuellen Schneemengen und dem Wetter und der zeitlichen Auslastung werden die Fortschritte auch nicht besonders schnell gehen. Kann also gut sein, dass jemand anders schneller die Sachen eingepflegt hat, der sich bereits besser mit dem Code auskennt, für mich ist das halt auch Neuland.
Ich möchte halt keine zu hohen Erwartungen schüren...
Aber wenn ich es zeitlich mal hinbekomme, werde ich mich damit befassen.
Ich kann momentan den Aufwand nur schwer einschätzen, weil ich noch nicht geschaut habe, wie groß der Unterschied zwischen dem Code in der seriellen Version und in der Eosbandi-Version ist, wie viel eigene Entwicklung und wie viel aufwändiges Testen also dazu kommt.
"Gefühlt" müsste sich ja eigentlich alles übernehmen lassen - Parsing, Filter usw. Aber aus der alltäglichen Erfahrung mit Softwareentwicklung "stimmt da was mit meinen Gefühl nicht" ;-)
Jedenfalls finde ich die Ergebnisse, die das ganze scheinbar bringt, sehr spannend und würde ja gerne mal einen Flug mit der aktuellen Version sehen.

Wie ist das eigentlich bei APM? Der MultiWii-GPS Code stammt doch direkt aus den APM-Quellen. Bedeutet das, dass die Qualität von RTH und PH genauso ist bei beiden?

Rob, dann wird die nächste Version von arducopter das ebenfalls beinhalten und damit genauer werden?
Wirkt sich aber beim ublox nicht aus, oder?

@weisseruebe: Ich denke, eigentlich sind es nur der Binärparser und der Spikefilter, das bekomme ich schon in die Dev geflanscht, nur testen muss es wohl oder übel jemand anderes. Die Eos Bandi GPS routinen sind älter als die aktuellen der APM (schätzungsweise 2.7.1?).
@helste: Richtig! Das kommt in der nächsten APM Version. Du wirst allerdings das MTK Modul mit der 1.9 flashen müssen, damit sich die Genauigkeit erhöht. Ublox ist nicht betroffen, das läuft schon.

Dann betrifft mich das nicht. Das apm1 steckt im fpv raptor. Da kommt es auf ein paar m nicht drauf an. Beim apm2 habe ich gestern das interne GPS deaktiviert und das ublox angeschlossen. Bei allen weitern, die noch kommen, kommt sowieso gleich das ublox dran.

Klar, kann man auch neu kaufen, vielleicht ist es aber auch keine schlechte Idee, bestehende Hardware auszureizen. Und darum geht es eigentlich in dieser Code-Ecke.....

LG
Rob

Hi Rob,

gibt´s da auch was für die MTK3339 Fraktion?

VG
Frank

Aus aktuellem ("PN"-)Anlass, muss ich nochmal etwas schreiben!

Die Versionen hier sind nur für I2C-GPS Platinen geeignet! NICHT AUF EINE APM FLASHEN! MACHT NICHTS KAPUTT, FUNKTIONIERT NUR ÜBERHAUPT NICHT.

LG
Rob

@Franko: Die Befehle von 3329 und 3339 sind in den wichtigen Teilen gleich. Du musst "nur" die passende Firmware auftreiben, die alle Stellen überträgt und sich an das 3drobotics Binärprotokoll hält. Vielleicht stellt der Hersteller Dir eine zur Verfügung?
Die bisherigen Binär FW haben die letzte Stelle geschluckt, dass war mir bislang auch nicht bewusst gewesen.

LG
Rob

Mein Problem ist, dass ich dem apm2 im Rumpf vom bixler eingebaut habe und ich da kaum brauchbare sat Daten bekomme. Zumimdest dauert es ewig bis ein fix kommt.
Hat schon am y6 mit freier Sicht nach oben gedauert, und jetzt, im Rumpf mit einigen kabeln direkt drüber, hatte ich da bedenken. Deshalb habe ich mich für das externe GPS entschieden.

@Helste: Du brauchst Dich doch nicht zu rechtfertigen!! Wahrscheinlich ist ein ublox besser als ein mtk, aber das mtk musste m.E bislang auch unter seinen Möglichkeiten spielen. Aktuell bin ich nur dabei die Datenaquisition und Aufbereitung zu verbessern. Die reine Regeltechnik ist nicht wirklich verändert (Schwellenwert Minsat ist nur ein minimaler Eingriff), sollte aber mit besseren Daten auch besser funktionieren.
Ich habe mal 2 Bilder angehängt.
Auf dem ersten Bild sieht man den Kaltstart des GPS 3329 mit der 1.9 FW. Der Spikefilter ist an. Nach mehreren Minuten (ca 7?) hat er 8 Sats gefunden. Im Schlagschatten siehst Du überall die Häuser. Es gibt keine freie Sicht nach Süden (für SBAS/DGPS Fix wichtig). Schlechte Bedingungen.
Auf dem zweiten Bild habe ich den "gelben Wanderstreifen" nach 8 Sats resettet und 16 Minuten gewartet. Er wandert quasi nicht mehr. In dieser Zeit hatte er noch einen Sat gefunden (9). Der Spikefilter war an, die Bewegungsgrenze bei der das GPS neue LAT/LON Werte sendet war auf 0.0 m gesetzt ("Navthreshold" sonst 1.0 m). Der Copter wurde die ganze Zeit nicht bewegt.
Ich denke, die Bilder sprechen für sich und sind bislang das beste Ergebnis, das ich mit dem MTK3329 bekommen habe. Die angezeigte Position entspricht eigentlich genau dem tatsächlichen Standplatz.

LG
Rob

Wenn ich die neuen APM2.5 bekomme, dann könnte ich ja eines davon in den Bixler geben und das APM2 auf einen Kopter packen. Dann könnte ich das interne GPS wieder reaktivieren.
Was mich halt immer so stört ist die lange Wartezeit. Seit ich das ublox kenne und da innerhalb von wenigen Sekunden fix habe, ist halt das Warten beim MTK schon blöd.
Die Bilder schauen gut aus. Vorallem ist das ein sehr schönes Anwesen. Wenn das Deines ist, dann gratuliere ich dazu.

Tja, mit dem Anwesen habe ich nichts zu tun..... Das GPS war nur mal beim Hochfahren drüben....

Schade eigentlich;-)

Ich habe vorhin Nachricht von Wolfgang bekommen, dass mein LZ Midi repariert ist. Er schickt es mir nun zurück. Da kann ich dann damit wieder experimentieren. Software kommt natürlich Deine BaroPID drauf. Das LZ GPS habe ich auch dabei. Was soll ich denn nun mit dem GPS machen? Welche FW drauf?
Ich bin auch noch am grübeln auf welchen Frame ich das dann montiere.
Hätte wahlweise einen Tri, einen H-Quad, einen Y6 oder einen flachen Hexa.
Wobei der Y6 und der flache Hexa eigentlich eins sind. Den Y6 werde ich nämlich demnächst wieder in einen flachen Hexa verwandeln. Irgendwie gefällt mir das mit dem Y6 doch nicht so gut.

Was meinst Du, welchen frame soll ich mit dem LZ Midi beglücken?