Endlich GPS für Multiwii

[JUERGEN_]

Das ist imho Unsinn, da der 168 nichts anderes machen würde, als daa serielle GPS Signal in I2C zu konvertieren.

in diese machart, hättest du natürlich recht.
ABER,
noch nichts von parallelverarbeitung gehört ?

der ATMEGA1280 ist eigentlich noch langsammer als der ATMEGA644P im MK.
und da ist es seit jahren nie gelungen ein funktionierendes GPS in der FC zu implementieren,
weil einfach die rechenzeit nicht vorhanden war.
trotz des schon einfacher zu verarbeitenden GPS-µ-blox-binärcodes.

es musste beim MK ein Navigationscontroller her.

für GPS sehe ich die sichere variante nur den OpenPilot.
oder für den der löten kann, gibt es ja den ARM-o-Kopter. :
.

 

[heckmic]

...Oder den Arducopter...

 

[JUERGEN_]

...Oder den Arducopter...

der liegt bei mir auch in der ecke.

kein vergleich zum ARM-o-Kopter.

entweder spassfliegen, oder GPS fliegen, und da braucht es wohl mindestanforderung an rechenleistung.

 

[Ben_der]

So!
Ich hab GPs nun nativ per I2C OHNE einen Seriell-parser wie ATM168 seit wenigen Minuten auf einem Duemillanove 328 am Laufen.

Kompletter Code mit allen Sensoren 19.343Byte.
Code mitsamt Waypointfunktion über SD-Karte 29.344Byte

Feinschliff steht noch aus.
Kann noch was weglassen.

Test nur GPS Hold ohne Waypoint diesen Sonntag.

Ich berichte den weiteren Fortschritt.
Stable und Final voraussichtlich mitte Oktober.(Mache da ja volontär und muss ja noch Semmeln holen..)

Über das GPS-Modul darf ich noch nichts sagen.

Ich bitte hier von Fragen abzusehen.

Zum thema Rechenleistung: Solange man nur die Daten abholt und dann erst verarbeiten muss macht das langsam, klar.Aktuelle GPS-chips können aber weitaus mehr als nur NMEA auszugeben, die können auch die Navigation übernehmen.Leider sind dei Dokus dazu recht gruselig - Befehlsreferenzen 500 Seiten aufwärts..

 

[GF-Downloads]

Cooool, da freuen wir uns drauf!
Hoffentlich klappt alles!!

 

[der-Frickler]

Fein, das klingt gut!
Wird das ganze in die sourcen des Multiwii einfließen?

 

[Ben_der]

Ja und nein.

Es basiert größtenteils auf den Sourcen von Multiwii mit GPS
Der GPS-Chip bekommt eine eigene Section mit Übergabepunkten an das Script von Michael_sk.

Der Code ist der selbe.
Es ist lediglich ein weiterer Boardtyp und ein weiterer Sensor mit Funktionsscript sowie entsprechenden "mutatoren" für die GPS Engine.Also nur i2c Implementierung, I2c mitsamt Eigenberechnungsbefehlssatz und anpassung der engine um dem rechnung zu tragen

Das ganze sol dann entweder über die Boardauswahl oder die Sensorauwahl schaltbar werden.Integration in MWiiconf mitsamt PID für GPS muss noch.

koordinaten, DST und Fix werden bereits angezeigt.

Es kann dann so in MWii einfliessen, ja.

 

[der-Frickler]

Super! Freu mich drauf!

 

[Treeda]

Ich nehm an das wird dann auch mit jeglicher hardware funktionieren, also mit jedem board? z.b. dem Flyduino Mega?

 

[Ben_der]

Ja.

Die Funktionen GPS_Serial,GPS_i2c und GPS_i2cLZ sowie GPS_i2cLZ_autocalc sind auf alle Boardtypen übertragbar.

Hier ist der gemeinsame Standard ja i2c.
Der Zwang zu einem Mega zwecks der seriellen ports entfällt.Auch die Thematik mit Speicher über MegaIMu entfällt.Die SD Karte hängt auch an i2c.

Die SD-Karte befreit auch von der Notwendigkeit weiter unnützen Code auf das EEPROM aufzubraten.

Ich will weg von dem Seriellen gedöns.

Wenn jemand auf die Schnelle eine Funktion aus dem Hut zaubert die anhand der Lat /Lon selbsttätig den magnetischen Inklinationswinkel errechnet wäre ich dem sehr verbunden.
Manuell dem über die confg oder die GUI hinterher zu laufen halte ich für sinnfrei - kann nur eine sin/cos/ funktion sein ... das ist noch die andere Baustelle für das init und der selbstkalibrierung.

Die Dipolfeldberechnung stimmt zu 90% zu und wäre also im allgemeine brauchbar.

 

[Zwangsneurose]

Wenn jemand auf die Schnelle eine Funktion aus dem Hut zaubert die anhand der Lat /Lon selbsttätig den magnetischen Inklinationswinkel errechnet wäre ich dem sehr verbunden.

Du meinst.. anhand der Lat/Lon herausbekommen in welchem Winkel das Ziel ist (bezogen auf Nord)?

sina = sin(latstart)
sinb = sin(latziel)
cosa = cos(latstart)
cosb = cos(latziel)
cosba = cos(lonziel - lonstart)
x = acos(sina * sinb + cosa * cosb * cosba)
w = acos((sinb - sina * cos(x)) / (cosa * sin (x)))

und w sollte dann den Winkel ergeben.

Hatte das ganze mal als php-skript.. latitute und longitude müssen als Nachkommazahl ausgeschrieben sein. In Php sind dann auch noch einige deg2rad und umgekehrt dabei.

 

[Ben_der]

Ne, meine sowas wie hier:

http://www.magnetic-declination.com/

Den kann man auch bestimmt anhand der position Lat / lon ausrechnen

 

[Zwangsneurose]

"declination values are constantly changing". Also wird man um Karten nicht herumkommen bzw eine Berechnung mit dieser Technik nicht möglich sein.

 

[JUERGEN_]

in unseren breiten,
ist die Magnetic declination überhaupt zu berücksichtigen ?

der kompass ist doch eh schon mal schlechter.
wessen kompass ist im Kopter schon besser als 3Grad ?

 

[JUERGEN_]

nun für den KK-Kopter scheint es schon zu funktionieren.

da arbeitet eine Naviplatine.

- > http://www.rcgroups.com/forums/showpost.php?p=19245349&postcount=11012

und das obligatorische WARTHOX-Video - > http://vimeo.com/28842078

 

[Ben_der]

Was mit nem Mega Chipsatz wie abgebildet auch wirklich kein Problem ist.

 

[luhu]

Naaaaja, der Position Hold ist ja kein richtiger Position Hold

 

[Treeda]

kannst du "kein richtiger position hold" definieren? Was ist denn ein unrichtiger Position hold

 

[luhu]

Naja, Position Hold ist, wenn er genau (~1-2m) die Position hält.
Im Video fliegt er ja rund 30m weg

 

[Felias]

Ein Test ohne Wind wäre mal interessant, so ist das wenig aussagekräftig... wie so oft bei Warthox's Testvideos