Endlich GPS für Multiwii
- Themenstarter RC FAN
- Beginndatum
Die GPS-unterstützung für ATM328 ist nur über I2C möglich.
Ist integriert in der Version 1.8 p1 sowie 1.9.
Problematisch ist hier die Tatsache das sehr viele Hersteller die UART-mimic in die I2C Kommunikation übernehmen was den Einsatz von Fast Serial erfordert und hier zu neuen Problemen mit 328p führt.
Mit I2C an einem Mega begegnet man übrigens dem selben Problem .
Die Kollegen von Ardukopter sind hier scheinbar bereits fertig.
Die Logik für Position hold ist in 1.9 noch nicht drin. RTH ist leer.
Der Übergabepunkt GPS "GPS_newFrame" ist scharf und übergibt an GPS.pde und wird geschalten über GPSModeHold.Hier ist die Funktion nicht hinterlegt.
Dei Logik von 1.8P1_Sk kann hier hinein nach kleineren Anpassungen übertragen werden .
Entstammt den Kollegen vor Ardupirates.
Leider fehlen in der MWiiconf1.9 die Anzeigen zu Lat und Lon.
Dies hab ich bereits durch vermischen von 1.9 und 1.8p1 hinbekommen.
Ebenso habe ich die Routine für GPS Hold übernommen,
Sowie einige anpassungen an den übergabepunkten durchgeführt.
Meinerseits : ich bin immer noch am entwicklen und testen.
Ich bin mit den Ergebnissen noch nicht zu Frieden.
Ich bin die Beschaffung der GPS Daten nun schon über vielerlei Wege angegangen. Prinzipiell funktioniert das schon , leider mit sehr schwankenden Ergebnissen.
Wer hier ein Mega-Board hat tut sich natürlich leicht.GPS über seriell anstöpseln und gut.trotzdem muss de Code zum Position Hold eine
Glättungs und PID-Funktion mit einem Failsafe bekommen.
Wenn Quatschkoordinaten ankommen wird es sonst sehr spaßig ....
Hie rmuss also eine logik rein welche Positionsabwweichungen in Bezug zu einer realen Geschwindigkeit bringt und anhand des ACC vergleicht um die plausibilität zu bewerten.
Dann wird es richtig ruhig !
Ich hab jedenfalls noch nen Haufen Arbeit vor mir.
Kan hier auch keinerlei Versprechungen machen - so firm bin ich in C++ (noch) nicht..
Leider gibt es scheinbar noch keine I2C GPS Chips welche mit Registern arbeiten was einen vernünftigen und ressourchenschonenden Einsatz doch sehr eingrenzt.
Ist integriert in der Version 1.8 p1 sowie 1.9.
Problematisch ist hier die Tatsache das sehr viele Hersteller die UART-mimic in die I2C Kommunikation übernehmen was den Einsatz von Fast Serial erfordert und hier zu neuen Problemen mit 328p führt.
Mit I2C an einem Mega begegnet man übrigens dem selben Problem .
Die Kollegen von Ardukopter sind hier scheinbar bereits fertig.
Die Logik für Position hold ist in 1.9 noch nicht drin. RTH ist leer.
Der Übergabepunkt GPS "GPS_newFrame" ist scharf und übergibt an GPS.pde und wird geschalten über GPSModeHold.Hier ist die Funktion nicht hinterlegt.
Dei Logik von 1.8P1_Sk kann hier hinein nach kleineren Anpassungen übertragen werden .
Entstammt den Kollegen vor Ardupirates.
Leider fehlen in der MWiiconf1.9 die Anzeigen zu Lat und Lon.
Dies hab ich bereits durch vermischen von 1.9 und 1.8p1 hinbekommen.
Ebenso habe ich die Routine für GPS Hold übernommen,
Sowie einige anpassungen an den übergabepunkten durchgeführt.
Meinerseits : ich bin immer noch am entwicklen und testen.
Ich bin mit den Ergebnissen noch nicht zu Frieden.
Ich bin die Beschaffung der GPS Daten nun schon über vielerlei Wege angegangen. Prinzipiell funktioniert das schon , leider mit sehr schwankenden Ergebnissen.
Wer hier ein Mega-Board hat tut sich natürlich leicht.GPS über seriell anstöpseln und gut.trotzdem muss de Code zum Position Hold eine
Glättungs und PID-Funktion mit einem Failsafe bekommen.
Wenn Quatschkoordinaten ankommen wird es sonst sehr spaßig ....
Hie rmuss also eine logik rein welche Positionsabwweichungen in Bezug zu einer realen Geschwindigkeit bringt und anhand des ACC vergleicht um die plausibilität zu bewerten.
Dann wird es richtig ruhig !
Ich hab jedenfalls noch nen Haufen Arbeit vor mir.
Kan hier auch keinerlei Versprechungen machen - so firm bin ich in C++ (noch) nicht..
Leider gibt es scheinbar noch keine I2C GPS Chips welche mit Registern arbeiten was einen vernünftigen und ressourchenschonenden Einsatz doch sehr eingrenzt.
Hi,
ich bin sehr neugierig geworden. hab aber leider kaum zeit mitzuentwickeln
zum 328 board:
was spräche denn gegen eine auswertung im atmel der die seriel auf i2c umsetzung macht? also z.b. nicht nur die position übergibt sondern auch einen wert wie warscheinlich das ergebnis ist?
kein 3d fix, sattelitenzahl auswerten oder einfacher "300seemeilen vom startpunkt" führt zur alarm oder sonstiges, notlandung, alle motoren aus! naja irgendwas, aber kein abflug.
damit das ganze ruig auf der stelle bleibt aber auch bei größerer strecke schnell ankommt würde ich etwas einfaches machen wie:
gps position "springt" in abstand von 300m umher -> auf warscheinlichere signale warten
gps ziel mehr als 20km entfernt und fix ok -> schleichgang oder hold.. 20km ist zu viel für nen quadro. wegpunkt oder home position fehler.
gps ziel innerhalb 1km : marschgeschwindigkeit
gps ziel innerhlab von 100m mittlere geschwindigkeit
gps ziel innerhalb von 10m : schleichgang
und wenn die warscheinlichkeit gering ist einen gang runterschalten ins nächst niedrigere.
leicht anzupassende werte in den code einbauen das jeder das aus seinem copter holen kann mit dem er glücklich ist
für stärkeren wind müsste man sich dann noch was überlegen.. aber das kommt noch.
auch datensätze in denen auf einmal ein paar hundert meter innerhalb von 2 sekunden zurückgelegt werden könnte man rauswerfen.
ich glaub ich muss wohl doch mir ein gps bestellen und etwas programmieren.. jetzt hat mich die neugier gepackt..
ich bin sehr neugierig geworden. hab aber leider kaum zeit mitzuentwickeln
zum 328 board:
was spräche denn gegen eine auswertung im atmel der die seriel auf i2c umsetzung macht? also z.b. nicht nur die position übergibt sondern auch einen wert wie warscheinlich das ergebnis ist?
kein 3d fix, sattelitenzahl auswerten oder einfacher "300seemeilen vom startpunkt" führt zur alarm oder sonstiges, notlandung, alle motoren aus!
naja irgendwas, aber kein abflug.damit das ganze ruig auf der stelle bleibt aber auch bei größerer strecke schnell ankommt würde ich etwas einfaches machen wie:
gps position "springt" in abstand von 300m umher -> auf warscheinlichere signale warten
gps ziel mehr als 20km entfernt und fix ok -> schleichgang oder hold.. 20km ist zu viel für nen quadro. wegpunkt oder home position fehler.
gps ziel innerhalb 1km : marschgeschwindigkeit
gps ziel innerhlab von 100m mittlere geschwindigkeit
gps ziel innerhalb von 10m : schleichgang
und wenn die warscheinlichkeit gering ist einen gang runterschalten ins nächst niedrigere.
leicht anzupassende werte in den code einbauen das jeder das aus seinem copter holen kann mit dem er glücklich ist
für stärkeren wind müsste man sich dann noch was überlegen.. aber das kommt noch.
auch datensätze in denen auf einmal ein paar hundert meter innerhalb von 2 sekunden zurückgelegt werden könnte man rauswerfen.
ich glaub ich muss wohl doch mir ein gps bestellen und etwas programmieren.. jetzt hat mich die neugier gepackt..
Position hold ist über Mergen von1.9 und 1.8p1 von Michael_sk möglich.
Die kontrollschleife für RTH ist noch nicht existent aber an sich einfach - das wäre die selbe schleife nur mit dem Ziel des HOME-Punktes + Höhe welcher (HomePosLatlonELE) am Flugstart ermittelt wird und gehört dann somit in den Setup oder Mainloop.
Ich denke hier muss aber noch etwas rein wie: Aktuelle position +50 Meter.RTH.Wenn (Poslatlon == HomePosLatLon), targetpos= HomePosLatLonEle + 3meter)..
Wo HomePosLatLon =
GPS_latitude
+GPS_longitude
+Baro_ALT
so in etwa.
Die kontrollschleife für RTH ist noch nicht existent aber an sich einfach - das wäre die selbe schleife nur mit dem Ziel des HOME-Punktes + Höhe welcher (HomePosLatlonELE) am Flugstart ermittelt wird und gehört dann somit in den Setup oder Mainloop.
Ich denke hier muss aber noch etwas rein wie: Aktuelle position +50 Meter.RTH.Wenn (Poslatlon == HomePosLatLon), targetpos= HomePosLatLonEle + 3meter)..
Wo HomePosLatLon =
GPS_latitude
+GPS_longitude
+Baro_ALT
so in etwa.
Moin,
alsoooooo....leider hat sich lipoly.de nicht mehr gemeldet aber parallel dazu habe ich mich bei Paul (Flyduino) auch in verbindung gesetzt. Er wird so wie es aussieht das FMP04 mit in seinem Shop anbieten. Ob es so nun kommen wird werden wir ja sehen. Zumindest ist Paul mit seinen Aussagen immer korekt und angeschrieben hat er den Lieferranten auch schon.Lassen wir uns überraschen.
Bis denn
Ertan
alsoooooo....leider hat sich lipoly.de nicht mehr gemeldet aber parallel dazu habe ich mich bei Paul (Flyduino) auch in verbindung gesetzt. Er wird so wie es aussieht das FMP04 mit in seinem Shop anbieten. Ob es so nun kommen wird werden wir ja sehen. Zumindest ist Paul mit seinen Aussagen immer korekt und angeschrieben hat er den Lieferranten auch schon.Lassen wir uns überraschen.
Bis denn
Ertan
Alsoooo!
Kurzer Zwischenstand der Entwicklung:
Ich habe es nun geschafft den SerGPS-> I2C-GPS Code anzupassen und das Hex zum Flashen duch eine eigene Engine auf Arduinobasis zum laufen zu bekommen.Es wird somit jedem möglich sein einen weiteren unterstützten Atmel als Parserboard zu verwenden und auch selbst über Arduino zu flashen.Das jetzige build hat eine Größe von 3420b und stellt
vollständige Informationen bereit - also auch Distance to Home,"Statring point" und Direction to Home was das Hauptboard auch weiter entlasten könnte.Hiermit muss ich mich noch an dei multiwii-community wenden um zu sehn ob hierzu ein branch entstehen kann oder das in den Trunk mit rein darf.
Es stehen noch Bereinigungen und Erprobungen an.
Kleine Wehrmutstropfen:
-Das "GPS Position Hold" Problem mit der Ausrichtung des Copters in Richtung Norden ist noch nicht gelöst.Ich weis wo dies geschieht verstehe aber noch nicht so ganz wie ich das ändern kann.
Dieses Thema liegt auch bei Verwendung von GPS_Ser mit Mega vor.
Ein Grund weswegen in der Version 1.9 die Funktion noch nicht implementiert ist - auch wenn alle Bedingungen hierzu bereits erfüllt sind.
-Die Cycletime ist duch die Verwendung des GPS beeinträchtigt.
Unter vollausgestatteten Bedingungen und Quad sprechen wir von einer ca. 8000er-12000er Cycletime.Ich sehe hier noch Verbesserungspotential.
Auf einem Mega leigt die Cycletime mit i2c bei ca 6900, mit Seriell bei 6200.
Ohne WMP und Pullups kann man pauschal überall knapp 1500abziehen.
Da ich sehr viele Debugs fahre ist auch hier eine Ursache dazu zu sehen .
-Es gibt nach wie vor Rupfer und Reißer wenn längere zeit kein Frame mit einem guten Fix daher kommt.Die Ursache hierzu ist mir noch nicht ganz klar. Ich habe da allerdings schon Vermututungen .
-Die Funktion RTH wird die Cycletime vermutlich weiter beeinträchtigen.
Hier ist die Umsetzung duch das Multiwii Team relevant.
-Auf 328p ist ein Refresh mit lokaler Errechnung über 4 hz nicht zu empfehlen.Die Cycletime fällt dann ins Bodenlose.
Einziger Ausweg ist die Berechnung auf dem GPS-Parserboard.Hierzu sind allerdings gravierendere Eingriffe in den Multiwiicode notwendig und ein Aufblasen des Codes auf dem parserboard auch ca 8900b notwendig (Was wieder einen größeren Chip als einen 88/8 voraussetzt -ARRRGGHH!!!)
Die Konsequenz der externen Berechnung wäre eine Integration durch das Multiwii-Projekt oder eine Abspaltung des Projekts -und das überschreitet dann meine Mittel.
Aktuell reingesteckte Arbeitszeit 113 Stunden.
Ich Schulde euch nach wie vor Videos zu dem Thema - allerdings kostet so ein Dreh dann mal schnell 2-3 Stunden die ich momentan einfach nicht habe(und auch keinen Mehrwert verspricht).Ich möchte mich lieber auf das Primäre Ziel konzentrieren das es zuverlässig läuft und die Source hierzu meinerseits freigegeben werden können.Ich werde die Source HIER ZUERST POSTEN!
Warum mache ich das ganze überhaupt?
Es missfällt mir auf ein Hex-File angewiesen zu sein das nicht offen gelegt wird.
Es missfällt mir das die Anwender nicht über Arduino flashen und modifizieren können.
Es missfällt mir das Anwender keine möglichkeit haben zu verstehen was wie und warum so funktioniert.
Das verhindert weitere diversifizierung des Codes um neue Entwicklungen zu ermöglich.
Zur frage mit den Fuse Bits bei der AVR-Flasherei:
Steht alles
HIER drin:
Kurzer Zwischenstand der Entwicklung:
Ich habe es nun geschafft den SerGPS-> I2C-GPS Code anzupassen und das Hex zum Flashen duch eine eigene Engine auf Arduinobasis zum laufen zu bekommen.Es wird somit jedem möglich sein einen weiteren unterstützten Atmel als Parserboard zu verwenden und auch selbst über Arduino zu flashen.Das jetzige build hat eine Größe von 3420b und stellt
vollständige Informationen bereit - also auch Distance to Home,"Statring point" und Direction to Home was das Hauptboard auch weiter entlasten könnte.Hiermit muss ich mich noch an dei multiwii-community wenden um zu sehn ob hierzu ein branch entstehen kann oder das in den Trunk mit rein darf.
Es stehen noch Bereinigungen und Erprobungen an.
Kleine Wehrmutstropfen:
-Das "GPS Position Hold" Problem mit der Ausrichtung des Copters in Richtung Norden ist noch nicht gelöst.Ich weis wo dies geschieht verstehe aber noch nicht so ganz wie ich das ändern kann.
Dieses Thema liegt auch bei Verwendung von GPS_Ser mit Mega vor.
Ein Grund weswegen in der Version 1.9 die Funktion noch nicht implementiert ist - auch wenn alle Bedingungen hierzu bereits erfüllt sind.
-Die Cycletime ist duch die Verwendung des GPS beeinträchtigt.
Unter vollausgestatteten Bedingungen und Quad sprechen wir von einer ca. 8000er-12000er Cycletime.Ich sehe hier noch Verbesserungspotential.
Auf einem Mega leigt die Cycletime mit i2c bei ca 6900, mit Seriell bei 6200.
Ohne WMP und Pullups kann man pauschal überall knapp 1500abziehen.
Da ich sehr viele Debugs fahre ist auch hier eine Ursache dazu zu sehen .
-Es gibt nach wie vor Rupfer und Reißer wenn längere zeit kein Frame mit einem guten Fix daher kommt.Die Ursache hierzu ist mir noch nicht ganz klar. Ich habe da allerdings schon Vermututungen .
-Die Funktion RTH wird die Cycletime vermutlich weiter beeinträchtigen.
Hier ist die Umsetzung duch das Multiwii Team relevant.
-Auf 328p ist ein Refresh mit lokaler Errechnung über 4 hz nicht zu empfehlen.Die Cycletime fällt dann ins Bodenlose.
Einziger Ausweg ist die Berechnung auf dem GPS-Parserboard.Hierzu sind allerdings gravierendere Eingriffe in den Multiwiicode notwendig und ein Aufblasen des Codes auf dem parserboard auch ca 8900b notwendig (Was wieder einen größeren Chip als einen 88/8 voraussetzt -ARRRGGHH!!!)
Die Konsequenz der externen Berechnung wäre eine Integration durch das Multiwii-Projekt oder eine Abspaltung des Projekts -und das überschreitet dann meine Mittel.
Aktuell reingesteckte Arbeitszeit 113 Stunden.
Ich Schulde euch nach wie vor Videos zu dem Thema - allerdings kostet so ein Dreh dann mal schnell 2-3 Stunden die ich momentan einfach nicht habe(und auch keinen Mehrwert verspricht).Ich möchte mich lieber auf das Primäre Ziel konzentrieren das es zuverlässig läuft und die Source hierzu meinerseits freigegeben werden können.Ich werde die Source HIER ZUERST POSTEN!
Warum mache ich das ganze überhaupt?
Es missfällt mir auf ein Hex-File angewiesen zu sein das nicht offen gelegt wird.
Es missfällt mir das die Anwender nicht über Arduino flashen und modifizieren können.
Es missfällt mir das Anwender keine möglichkeit haben zu verstehen was wie und warum so funktioniert.
Das verhindert weitere diversifizierung des Codes um neue Entwicklungen zu ermöglich.
Zur frage mit den Fuse Bits bei der AVR-Flasherei:
Steht alles
HIER drin:
Hallo Ben,
hey das ist ja wirklich ganz große Klasse. Ich hatte auch schon MichalM_sk angeschrieben, ob er seinen Code veröffentlicht, da ich hier ein 4800baud-GPS-Modul rumliegen habe. Aber bisher keine Antwort. Umso mehr und erwartungsvoll freue ich mich über Deine Bemühungen zum GPS-I2C-Umsetzer, die ich bestimmt nicht so hinbekommen hätte. Alle Achtung !
Also vielen Dank schon mal im voraus!
Viele Grüße
Matthias
hey das ist ja wirklich ganz große Klasse. Ich hatte auch schon MichalM_sk angeschrieben, ob er seinen Code veröffentlicht, da ich hier ein 4800baud-GPS-Modul rumliegen habe. Aber bisher keine Antwort. Umso mehr und erwartungsvoll freue ich mich über Deine Bemühungen zum GPS-I2C-Umsetzer, die ich bestimmt nicht so hinbekommen hätte. Alle Achtung !
Also vielen Dank schon mal im voraus!
Viele Grüße
Matthias
Der antwortet schon seit Wochen nicht mehr .(Hoffentlich ist dem nix passiert.. )Er hat seit dem keine Nachrichten mehr abgeholt.Er verbitet jedenfalls die kommerzielle Verwendung seiner Hex - auch ein Grund weswegen ich da tätig geworden bin...sowas käst mich nämlich an.An sich ist es kein Problem das umzusetzen (nachdem man alles dazu gesucht, verstanden und gelernt hat....).
Versuch,Fehlschlag,Test, Analyse und neu Konzipieren kostet halt leider irre viel Zeit...
Versuch,Fehlschlag,Test, Analyse und neu Konzipieren kostet halt leider irre viel Zeit...
Hallo,
einfach genial von Paul....nun hat er das GPS Modul (FMP04) auch in seinem Angebot. Find ich richtig gut das er auf Kundenwünsche reagiert! Super weiter so !!!!! Habe eben bestellt.... und freue mich wenn es ankommt ....mein Mega freut sich ebenfalls
Hier der Link:
http://flyduino.net/FMP04-GPS-Modul
einfach genial von Paul....nun hat er das GPS Modul (FMP04) auch in seinem Angebot. Find ich richtig gut das er auf Kundenwünsche reagiert! Super weiter so !!!!! Habe eben bestellt.... und freue mich wenn es ankommt ....mein Mega freut sich ebenfalls
Hier der Link:
http://flyduino.net/FMP04-GPS-Modul
