Autopilot - Ardupilot
- Themenstarter Rangarid
- Beginndatum
Hi,
ganz so einfach ist es nicht.
Die IMU gibt ja die Lagereferenzwinkel aus der Sicht des eigenen Bezuggsystems aus.
Dafür wird mit 3D Vektoren gerechnet.
Ein Kompass hat als Bezugssystem das Erdmagnetfeld. Hier muss man die Deklination und die Inklination berücksichtigen. Diese Werte sind an verschiedenen Orten unterschiedlich und ändern sich zudem fortlaufend.
Ein kleiner Rechenfehler (Rundungsfehler) oder eine lokale Störung im Magnetfeld und Du kannst das Modell vergessen.
Die IMU arbeitet dagegen mit Gyros und Beschleunigungssensoren.
Die Gyros braucht man um Vibrationen die von den Accelerometern gemessen werden auszugleichen und die Accelerometer braucht man um die Gyro Drift zu kompensieren.
Die IMU wertet diese Sensoren aus und berechnet die Lage im Raum. Gleichzeitig liest sie das GPS aus und packt diese Informationen in ein Statustelegramm welches im binärformat an den AP gesendet wird.
Mit Magnetometer kann man in der Version V1_7 der IMU Software die Gyrodrift ausgleichen (per define ein- oder ausschaltbar).
Ich habe dann noch eine Modifikatrion im code der IMU vorgenommen:
Wenn die GPS-speed kleiner ist als 2 m/s dann verwende ich das Heading des Magnetometers anstelle des GPS Wertes.
Ich hatte das Magnetometer dazu genommen, damit ich auch bei Gegenwind (groundspeed nahe 0) keine Störungen befürchten muss.
Die neue Software der IMU habe ich übrigens nicht fehlerfrei übersetzen können. Die FastSerial library macht mir noch Schwierigkeiten.
Viele Grüße
Achim
ganz so einfach ist es nicht.
Die IMU gibt ja die Lagereferenzwinkel aus der Sicht des eigenen Bezuggsystems aus.
Dafür wird mit 3D Vektoren gerechnet.
Ein Kompass hat als Bezugssystem das Erdmagnetfeld. Hier muss man die Deklination und die Inklination berücksichtigen. Diese Werte sind an verschiedenen Orten unterschiedlich und ändern sich zudem fortlaufend.
Ein kleiner Rechenfehler (Rundungsfehler) oder eine lokale Störung im Magnetfeld und Du kannst das Modell vergessen.
Die IMU arbeitet dagegen mit Gyros und Beschleunigungssensoren.
Die Gyros braucht man um Vibrationen die von den Accelerometern gemessen werden auszugleichen und die Accelerometer braucht man um die Gyro Drift zu kompensieren.
Die IMU wertet diese Sensoren aus und berechnet die Lage im Raum. Gleichzeitig liest sie das GPS aus und packt diese Informationen in ein Statustelegramm welches im binärformat an den AP gesendet wird.
Mit Magnetometer kann man in der Version V1_7 der IMU Software die Gyrodrift ausgleichen (per define ein- oder ausschaltbar).
Ich habe dann noch eine Modifikatrion im code der IMU vorgenommen:
Wenn die GPS-speed kleiner ist als 2 m/s dann verwende ich das Heading des Magnetometers anstelle des GPS Wertes.
Ich hatte das Magnetometer dazu genommen, damit ich auch bei Gegenwind (groundspeed nahe 0) keine Störungen befürchten muss.
Die neue Software der IMU habe ich übrigens nicht fehlerfrei übersetzen können. Die FastSerial library macht mir noch Schwierigkeiten.
Viele Grüße
Achim
Hi Rainer,
Nein, nur die Drift des yaw Gyros wird kompensiert. Also lediglich die Nordrichtung in der Kartenebene.
Falls das Magnetometer nicht verwendet wird, so wird stattdessen das heading aus dem GPS dafür verwendet.
In der IMU Software kann die Deklination eingegeben werden. Bei der neuen Software im arduimu.pde wenn ich mich nicht irre. Bei der älteren V1_7 Software im Modul compass.pde
Es gibt eine US-.gov Seite bei der man die Geo-Koordinaten eingeben kann und die dann weltweit die Deklination ermittelt:
http://www.ngdc.noaa.gov/geomagmodels/Declination.jsp
Ja, und zwar verwende ich die NMEA messages, nicht das binary Protokoll da ich dann das ET-OSD mit anschließen kann.
Das ET-OSD will NMEA mit 38400 baud.
Das weiß ich nicht. So tief hab' ich in die SW nicht reingeschaut.
Ich vermute aber, dass das Heading aus dem GPS Datensatz verwendet wird. Man spart dadurch schließlich Rechenzeit.
Das sehe ich genau so.
Die bessere Plattform ist sowieso der ArduPilot Mega.
Viele Grüße
Achim
Nein, nur die Drift des yaw Gyros wird kompensiert. Also lediglich die Nordrichtung in der Kartenebene.
Falls das Magnetometer nicht verwendet wird, so wird stattdessen das heading aus dem GPS dafür verwendet.
In der IMU Software kann die Deklination eingegeben werden. Bei der neuen Software im arduimu.pde wenn ich mich nicht irre. Bei der älteren V1_7 Software im Modul compass.pde
Es gibt eine US-.gov Seite bei der man die Geo-Koordinaten eingeben kann und die dann weltweit die Deklination ermittelt:
http://www.ngdc.noaa.gov/geomagmodels/Declination.jsp
Ja, und zwar verwende ich die NMEA messages, nicht das binary Protokoll da ich dann das ET-OSD mit anschließen kann.
Das ET-OSD will NMEA mit 38400 baud.
Das weiß ich nicht. So tief hab' ich in die SW nicht reingeschaut.
Ich vermute aber, dass das Heading aus dem GPS Datensatz verwendet wird. Man spart dadurch schließlich Rechenzeit.
Das sehe ich genau so.
Die bessere Plattform ist sowieso der ArduPilot Mega.
Viele Grüße
Achim
Hallo Rainer,
Jetzt verstehe ich, was Du gemeint hast
Die Kompensation des yaw Gyrodrifts erfolgt nach der Umrechnung der Sensorwerte (Bezugsystem Flieger) über die Matrix in das Bezugsystem Erde. Der Magnetometer kompensiert daher genaugenommen, den absoluten Nord-Richtungsfehler, der durch die Drift aller drei Gyros entsteht - da die roll und nickgyros ja bei nicht waagrechtem Flug darauf auch einen Einfluss haben.
Ich habe die Telemetriewerte der IMU über ACSII Telegramme auf der seriellen ausgeben lassen und sie mir mit der Visualisierungssoftware angesehen.
Roll- und Nick- und Yawwinkel driften leider etwas, wenn man die IMU heftig bewegt. Ich vermute, da kommen die Accelerometer an ihre Grenzen.
Auf Magnete vom Whiteboard wird bereits im Abstand von 10cm reagiert. Auf Magnete von www.supermagnete.de schon in einem Meter Abstand.
Die Richtung ändert sich auch, wenn ich mit der IMU auf der Schreibtischplatte näher an das Stahl- Vierkantrohr herangehe.
Zum Thema Heading aus dem GPS oder aus den Koordinaten selbst berechnen:
Ich habe mir mal einen GPS-Datenlogger gebaut um damit meine Kartfahrten aufzeichnen und auswerten zu können.
Bremspunkte, Beschleunigungsdiagramme, Geschwindigkeiten usw.
Als ich die Auswertesoftware begonnen habe, wollte ich die gefahrene Strecke berechnen und habe einfach die Strecke zwischen den letzten beiden Koordinaten aufsummiert.
Das Ergebnis war wegen der hohen Ungenauigkeit der Koordinaten total daneben. Auf eine Strecke von 65 km hatte ich einen Fehler von 15 km !!!
Ich rechnete dann mit der GPS Geschwindigkeit und der Samplerate die Strecken zwischen zwei Messpunkten aus und summierte diese auf.
Das Ergebnis passte bis auf wenige Meter.
Ich weiß nicht, wie der Algorithmus im Chipsatz des GPS aussieht, mit dem das heading (course) berechnet wird, aber ich nehme an, das wird nicht einfach nur mit sin und cos gerechnet.
Der course, der aus der RMC message kommt, ist m.E. mindestens gleich gut, wie eine eigene Berechnung.
Mit der V1_8_x Software habe ich auch noch keine Fortschritte gemacht.
Ich denke, es wäre das einfachste auf die Funktionen der FastSerial library zu verzichten und für boolean einen eigenen Datentyp zu definieren.
Ob es danach noch weitere Fehlermeldungen hat, weiß ich noch nicht.
Man könnte aber auch mal im Projekt Wiki der IMU eine entsprechende Frage posten.
Viele Grüße
Achim
Jetzt verstehe ich, was Du gemeint hast
Die Kompensation des yaw Gyrodrifts erfolgt nach der Umrechnung der Sensorwerte (Bezugsystem Flieger) über die Matrix in das Bezugsystem Erde. Der Magnetometer kompensiert daher genaugenommen, den absoluten Nord-Richtungsfehler, der durch die Drift aller drei Gyros entsteht - da die roll und nickgyros ja bei nicht waagrechtem Flug darauf auch einen Einfluss haben.
Ich habe die Telemetriewerte der IMU über ACSII Telegramme auf der seriellen ausgeben lassen und sie mir mit der Visualisierungssoftware angesehen.
Roll- und Nick- und Yawwinkel driften leider etwas, wenn man die IMU heftig bewegt. Ich vermute, da kommen die Accelerometer an ihre Grenzen.
Auf Magnete vom Whiteboard wird bereits im Abstand von 10cm reagiert. Auf Magnete von www.supermagnete.de schon in einem Meter Abstand.
Die Richtung ändert sich auch, wenn ich mit der IMU auf der Schreibtischplatte näher an das Stahl- Vierkantrohr herangehe.
Zum Thema Heading aus dem GPS oder aus den Koordinaten selbst berechnen:
Ich habe mir mal einen GPS-Datenlogger gebaut um damit meine Kartfahrten aufzeichnen und auswerten zu können.
Bremspunkte, Beschleunigungsdiagramme, Geschwindigkeiten usw.
Als ich die Auswertesoftware begonnen habe, wollte ich die gefahrene Strecke berechnen und habe einfach die Strecke zwischen den letzten beiden Koordinaten aufsummiert.
Das Ergebnis war wegen der hohen Ungenauigkeit der Koordinaten total daneben. Auf eine Strecke von 65 km hatte ich einen Fehler von 15 km !!!
Ich rechnete dann mit der GPS Geschwindigkeit und der Samplerate die Strecken zwischen zwei Messpunkten aus und summierte diese auf.
Das Ergebnis passte bis auf wenige Meter.
Ich weiß nicht, wie der Algorithmus im Chipsatz des GPS aussieht, mit dem das heading (course) berechnet wird, aber ich nehme an, das wird nicht einfach nur mit sin und cos gerechnet.
Der course, der aus der RMC message kommt, ist m.E. mindestens gleich gut, wie eine eigene Berechnung.
Mit der V1_8_x Software habe ich auch noch keine Fortschritte gemacht.
Ich denke, es wäre das einfachste auf die Funktionen der FastSerial library zu verzichten und für boolean einen eigenen Datentyp zu definieren.
Ob es danach noch weitere Fehlermeldungen hat, weiß ich noch nicht.
Man könnte aber auch mal im Projekt Wiki der IMU eine entsprechende Frage posten.
Viele Grüße
Achim
Hi Rainer,
So einen genauen Versuchsaufbau hatte ich nicht. Habe die IMU immer von Hand bewegt. Kann darüber also keine Aussage machen.
Ich hatte ein FV-M8 GPS Modul mit echten 5 Hz updaterate. Ich fuhr sowohl Landstraße als auch Autobahn.
Hier ist die Strecke:
Und hier ist die erzeugte kml Datei: http://www.schwabenkart.de/Tagebuch/PFK/outlog.kml
Bei einer Durchschnittsgeschwindigkeit von ca. 65 km/h waren die Koordinaten durchschnittlich 3,65m voneinander entfernt.
Natürlich ist's von der Geschwindigkeit abhängig. Wenn man den Kurswinkel selbst berechnet ist's die Problematik aber die selbe.
Es gibt GPS Module, die geben bei Geschwindigkeiten unter einem bestimmten Schwellwert keine neu empfangenen Koordinaten (und Kurswinkel) aus. Diese sind bei Navi Herstellern ganz beliebt. Für kleine Geschwindigkeiten jedoch total ungeeignet (Quadrokopter z.B.)
Es gibt andere Module, die geben immer die aktuell ermittelte Position aus. Das gibt eine Punktwolke wenn man ein kml-file draus macht und eine kreiselnde Kompassnadel.
Deshalb verwende ich ja bei Geschwindigkeiten unter 2m/s ausschließlich die magnetische Richtung.
Die Geschwindigkeitsbestimmung des GPS basiert auf einer Dopplermessung. Sie ist sehr genau. Für eine Navigation für Fahrzeuge oder Multikopter bei geringen Geschwindigkeiten wäre eine relative Positionsbestimmung a la Koppelnavigation aus der Geschwindigkeitsangabe des GPS, der Zyklusdauer für den Positionsupdate und der magnetischen Richtung wohl das genaueste.
Diese Diskussion hatte ich neulich auch mit einem Freund. Der möchte ein Modellauto eine bestimmte Strecke auf seinem Grundstück fahren lassen. Die GPS Ungenauigkeit macht ihm da aber einen Strich durch die Rechnung.
.....ich schweife ab.....
GPS ist ein großes und nicht einfaches Thema. Da könnte man noch viel mehr darüber schreiben.
Viele Grüße
Achim
So einen genauen Versuchsaufbau hatte ich nicht. Habe die IMU immer von Hand bewegt. Kann darüber also keine Aussage machen.
Ich hatte ein FV-M8 GPS Modul mit echten 5 Hz updaterate. Ich fuhr sowohl Landstraße als auch Autobahn.
Hier ist die Strecke:
Und hier ist die erzeugte kml Datei: http://www.schwabenkart.de/Tagebuch/PFK/outlog.kml
Bei einer Durchschnittsgeschwindigkeit von ca. 65 km/h waren die Koordinaten durchschnittlich 3,65m voneinander entfernt.
Natürlich ist's von der Geschwindigkeit abhängig. Wenn man den Kurswinkel selbst berechnet ist's die Problematik aber die selbe.
Es gibt GPS Module, die geben bei Geschwindigkeiten unter einem bestimmten Schwellwert keine neu empfangenen Koordinaten (und Kurswinkel) aus. Diese sind bei Navi Herstellern ganz beliebt. Für kleine Geschwindigkeiten jedoch total ungeeignet (Quadrokopter z.B.)
Es gibt andere Module, die geben immer die aktuell ermittelte Position aus. Das gibt eine Punktwolke wenn man ein kml-file draus macht und eine kreiselnde Kompassnadel.
Deshalb verwende ich ja bei Geschwindigkeiten unter 2m/s ausschließlich die magnetische Richtung.
Die Geschwindigkeitsbestimmung des GPS basiert auf einer Dopplermessung. Sie ist sehr genau. Für eine Navigation für Fahrzeuge oder Multikopter bei geringen Geschwindigkeiten wäre eine relative Positionsbestimmung a la Koppelnavigation aus der Geschwindigkeitsangabe des GPS, der Zyklusdauer für den Positionsupdate und der magnetischen Richtung wohl das genaueste.
Diese Diskussion hatte ich neulich auch mit einem Freund. Der möchte ein Modellauto eine bestimmte Strecke auf seinem Grundstück fahren lassen. Die GPS Ungenauigkeit macht ihm da aber einen Strich durch die Rechnung.
.....ich schweife ab.....
GPS ist ein großes und nicht einfaches Thema. Da könnte man noch viel mehr darüber schreiben.
Viele Grüße
Achim
Hi Rainer,
danke für den Tipp.
Ich hatte seither die 018er Version von Arduino installiert.
Nach den Problemen beim compilieren hatte ich die neueste Version 022 installiert.
Nun habe ich die 021er Version auch installiert - damit geht's bei mir anstandslos.
Dateiattribute musste ich keine ändern.
Die Fangfunktion auf Straßen und Wege bei Navis habe ich auch schon oft beobachtet.
Ich werde dann diese Version auch mal installieren und heute im Lauf des Tages testen.
Also nicht so lange wie gestern am Computer rumhängen.... meine Tilt Mechanik ist nun auch gekommen - Die Groundstation will auch fertig gebaut und die Winkel eingelernt werden.
Viele Grüße
Achim
danke für den Tipp.
Ich hatte seither die 018er Version von Arduino installiert.
Nach den Problemen beim compilieren hatte ich die neueste Version 022 installiert.
Nun habe ich die 021er Version auch installiert - damit geht's bei mir anstandslos.
Dateiattribute musste ich keine ändern.
Die Fangfunktion auf Straßen und Wege bei Navis habe ich auch schon oft beobachtet.
Ich werde dann diese Version auch mal installieren und heute im Lauf des Tages testen.
Also nicht so lange wie gestern am Computer rumhängen.... meine Tilt Mechanik ist nun auch gekommen - Die Groundstation will auch fertig gebaut und die Winkel eingelernt werden.
Viele Grüße
Achim
@Schwabenflieger...ich habe gerade nochmal deine Bilder im Wiki angeschaut. Der Airspeed bei diesem Test wird nicht zuverlässig funktionieren, da du ihn direkt hinterm Propeller misst. Er wird also viel mehr Airspeed angezeigt bekommen, als er letztendlich hat.
Vielleicht solltest du in deiner Testumgebung die Sonden an den Flügel machen, wo du vom Propeller nichtmehr viel abbekommst. Würd ich bei Flugzeugen mit Prop vorne auch machen, da dort am wenigsten beeinflusst wird.
Am besten wären die Sonden natürlich ganz vorn in der Spitze, da dort noch keine aerodynamischen Anpassungen der Luft an das Flugzeug sind und somit die Luft noch unberührt und rein
ist. Dort sollte man also die besten Ergebnisse bekommen.
Vielleicht solltest du in deiner Testumgebung die Sonden an den Flügel machen, wo du vom Propeller nichtmehr viel abbekommst. Würd ich bei Flugzeugen mit Prop vorne auch machen, da dort am wenigsten beeinflusst wird.
Am besten wären die Sonden natürlich ganz vorn in der Spitze, da dort noch keine aerodynamischen Anpassungen der Luft an das Flugzeug sind und somit die Luft noch unberührt und rein
ist. Dort sollte man also die besten Ergebnisse bekommen.@Rangarid:
Du hast Recht. Das ist mir bewusst.
Ich hatte das absichtlich so gemacht, um Airspeed nicht mittels eines zusätzlichen Ventilators simulieren zu müssen.
Wenn der Propellerstrahl den Sensor übersteuert, werde ich noch einen Trichter darüber bauen (dünnes Ende vorn, dickes Ende an den Pitot Röhrchen).
Wenn's dann echt nicht anders geht, kommen die Röhrchen an die Flügelspitze.
Das Problem bei mir ist, ich bin noch gar nicht dazu gekommen, das Teil vernünftig zu testen.
War in der letzten Zeit recht eingespannt und in der Freizeit habe ich mich neben dem Scorpion und ersten FPV Versuchen mit dem Aufbau meiner Bodenstation beschäftigt.
Ich hoffe, ich komme in den nächsten Tagen voran. Am 03.01. ist der Urlaub auch schon wieder zu Ende. Im Geschäft ist was dringendes und wichtiges dazwischen gekommen.
Viele Grüße
Achim
Du hast Recht. Das ist mir bewusst.
Ich hatte das absichtlich so gemacht, um Airspeed nicht mittels eines zusätzlichen Ventilators simulieren zu müssen.
Wenn der Propellerstrahl den Sensor übersteuert, werde ich noch einen Trichter darüber bauen (dünnes Ende vorn, dickes Ende an den Pitot Röhrchen).
Wenn's dann echt nicht anders geht, kommen die Röhrchen an die Flügelspitze.
Das Problem bei mir ist, ich bin noch gar nicht dazu gekommen, das Teil vernünftig zu testen.
War in der letzten Zeit recht eingespannt und in der Freizeit habe ich mich neben dem Scorpion und ersten FPV Versuchen mit dem Aufbau meiner Bodenstation beschäftigt.
Ich hoffe, ich komme in den nächsten Tagen voran. Am 03.01. ist der Urlaub auch schon wieder zu Ende. Im Geschäft ist was dringendes und wichtiges dazwischen gekommen.
Viele Grüße
Achim
