Bei guten Modulen bringt das bestimmt was - http://de.wikipedia.org/wiki/Differential_Global_Positioning_System
Endlich GPS für Multiwii
- Themenstarter RC FAN
- Beginndatum
Die Aussage hat mich mal zu Nachforschungen gebracht. Der EOS Bandi / Mwii GPS Code basiert auf dem Arducopter code, deswegen habe ich die "Issues" Datenbank durchgeschaut und habe einen weiteren(!) 2KM (!) - Fehler entdeckt, der bei dem Arducopter bereits gefixed ist und auch bei der aktuellen eos bandi Version noch besteht.
Issue480: http://code.google.com/p/arducopter/issues/detail?id=480&sort=-id
Fix: http://code.google.com/p/ardupilot-...ken=baLmOM1P7K1Mh1FVHhl6JVVms34:1354032602067
Das entspricht bei der I2C_GPS_NAV-v2.1rc2 im Hauptprogramm (I2C_GPS_NAV.ino)
Zeile 570:
Original:
Änderung:
Dadurch werden die ursprünglichen 16Bit auf 32 Bit aufgebohrt, damit kein Überlauf stattfinden kann. Schaden kann die Änderung auf jeden Fall nicht.
Zumindest wäre das ein 2KM Fehler weniger.... vielleicht haut er dann auch nicht mehr so schnell ab
LG
Rob
Issue480: http://code.google.com/p/arducopter/issues/detail?id=480&sort=-id
Fix: http://code.google.com/p/ardupilot-...ken=baLmOM1P7K1Mh1FVHhl6JVVms34:1354032602067
Das entspricht bei der I2C_GPS_NAV-v2.1rc2 im Hauptprogramm (I2C_GPS_NAV.ino)
Zeile 570:
Original:
Code:
...
uint32_t GPS_coord_to_degrees(char* s)
{
char *p, *q;
uint8_t deg = 0, min = 0;
unsigned int frac_min = 0;
// scan for decimal point or end of field
...
Code:
...
uint32_t GPS_coord_to_degrees(char* s)
{
char *p, *q;
uint8_t deg = 0, min = 0;
uint32_t frac_min = 0;
// scan for decimal point or end of field
...Zumindest wäre das ein 2KM Fehler weniger.... vielleicht haut er dann auch nicht mehr so schnell ab
LG
Rob
Hi, Butcher!
Also eigentlich war der Fehler den Programmiern bekannt deswegen haben sie versucht ihn mit "unsigned int frac_min = 0;" zu umschiffen. Die Frage ist nur, ob der compiler dann auch wirklich 32 Bit verwendet. Mit "uint32_t frac_min = 0; " wird der compiler auf jeden Fall dazu gezwungen. Falsch ist das in keinem Fall. Es ist nur die Frage, ob es richtiger ist.
LG
Rob
Also eigentlich war der Fehler den Programmiern bekannt deswegen haben sie versucht ihn mit "unsigned int frac_min = 0;" zu umschiffen. Die Frage ist nur, ob der compiler dann auch wirklich 32 Bit verwendet. Mit "uint32_t frac_min = 0; " wird der compiler auf jeden Fall dazu gezwungen. Falsch ist das in keinem Fall. Es ist nur die Frage, ob es richtiger ist.
LG
Rob
Zuletzt bearbeitet:
Das betrifft nur NMEA! Wenn man z.B den MTK auf reine Binärcode, und nicht ASCII - NMEA Ausgabe, umflashen würde, wäre das wahrscheinlich die beste Lösung, da auch dieses besch** NMEA ASCII parsing wegfallen würde.
Ich weiss nur nicht, ob ich den Flash des MTK Moduls bei dem LZ GPS so einfach mit dem FTDI durchführen kann. - Habe Angst es zu "bricken"
Das wäre dann die "AXN1.51_2722_3329_384.1151100.5.bin" mit dem Flashutil hier: http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=
Wenn das klappt, muss man natürlich in der config.h (eos bandi) nicht mehr #define NMEA sondern #define MTK auswählen.
Ich weiss nur nicht, ob ich den Flash des MTK Moduls bei dem LZ GPS so einfach mit dem FTDI durchführen kann. - Habe Angst es zu "bricken"
Das wäre dann die "AXN1.51_2722_3329_384.1151100.5.bin" mit dem Flashutil hier: http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=
Wenn das klappt, muss man natürlich in der config.h (eos bandi) nicht mehr #define NMEA sondern #define MTK auswählen.
Zuletzt bearbeitet:
Hi!
Also, ich will hier nicht alle verrückt machen!
Nur als ich den Beitrag gelesen hatte, dass es gut funktioniert und plötzlich zu Ausreissern kommt, könnte es ein Überlauf einer Variablen sein, der bereits bekannt ist aber ggf. nicht ausgemerzt wurde. Wenn das Problem überhaupt auftritt, dann beim NMEA Parsen der Ascii codes. Wer die direkten Binärprotokolle von ublox oder mtk verwendet, hat zumindest dieses potentielle Problem nicht.
Also, ich will hier nicht alle verrückt machen!
Nur als ich den Beitrag gelesen hatte, dass es gut funktioniert und plötzlich zu Ausreissern kommt, könnte es ein Überlauf einer Variablen sein, der bereits bekannt ist aber ggf. nicht ausgemerzt wurde. Wenn das Problem überhaupt auftritt, dann beim NMEA Parsen der Ascii codes. Wer die direkten Binärprotokolle von ublox oder mtk verwendet, hat zumindest dieses potentielle Problem nicht.
Zuletzt bearbeitet:
@scott09876:
Danke für die Info, dann ist der NMEA Fehler tatsächlich durch die Version hier http://fpv-community.de/showthread....f%FCr-Multiwii&p=242750&viewfull=1#post242750 gefixt.
Ich war mir nämlich nicht sicher, wie der compiler das beim Arduino interpretiert, da ich immer die Bitbreite angebe. Auf 32 Bit Platformen wird ein int auch gerne mal als 32 Bit kompiliert. Auf jeden Fall ist es besser, das in der Definition klar zu machen, dann kommen keine Missverständnisse/Rechenfehler auf.
Wer ein I2C GPS hat und dieses auf NMEA konfiguriert hat (z.B LZ-GPS) und dessen Kopter nach einem guten PosHold plötzlich ausbüxt, sollte auf jeden Fall den geänderten Sketch aufspielen.
Wer ein serielles GPS im NMEA Modus direkt an einem Arduino mega Board (z.B Crius AIO) betreibt, sollte die korrekte Definition in der GPS.ino einfügen. (Z.B aktuelle Dev 1240 Zeile 840).
Mittlerweile habe ich mein Geschenk von Wollez, das LZ GPS auf MTK Binärcode umgeflasht, mal sehen, ob das einen Unterschied macht. Beim Umflashen des GPS Moduls muss man RX/TX am FTDI Anschluss tauschen und vorher ein Programm auf den "Umsetzer" Arduino spielen, dass die serielle Schnittstelle nicht verwendet (z.B "Blink" oder "eepromclear), sonst bekommt man keinen Connect zum GPS.
LG
Rob
Danke für die Info, dann ist der NMEA Fehler tatsächlich durch die Version hier http://fpv-community.de/showthread....f%FCr-Multiwii&p=242750&viewfull=1#post242750 gefixt.
Ich war mir nämlich nicht sicher, wie der compiler das beim Arduino interpretiert, da ich immer die Bitbreite angebe. Auf 32 Bit Platformen wird ein int auch gerne mal als 32 Bit kompiliert. Auf jeden Fall ist es besser, das in der Definition klar zu machen, dann kommen keine Missverständnisse/Rechenfehler auf.
Wer ein I2C GPS hat und dieses auf NMEA konfiguriert hat (z.B LZ-GPS) und dessen Kopter nach einem guten PosHold plötzlich ausbüxt, sollte auf jeden Fall den geänderten Sketch aufspielen.
Wer ein serielles GPS im NMEA Modus direkt an einem Arduino mega Board (z.B Crius AIO) betreibt, sollte die korrekte Definition in der GPS.ino einfügen. (Z.B aktuelle Dev 1240 Zeile 840).
Mittlerweile habe ich mein Geschenk von Wollez, das LZ GPS auf MTK Binärcode umgeflasht, mal sehen, ob das einen Unterschied macht. Beim Umflashen des GPS Moduls muss man RX/TX am FTDI Anschluss tauschen und vorher ein Programm auf den "Umsetzer" Arduino spielen, dass die serielle Schnittstelle nicht verwendet (z.B "Blink" oder "eepromclear), sonst bekommt man keinen Connect zum GPS.
LG
Rob
Zuletzt bearbeitet:
