Trägheitsnavigation - Versionsgeschichte

SebastianG: /* TODO */

2013-03-03T17:31:07Z

TODO

← Nächstältere Version		Version vom 3. März 2013, 17:31 Uhr
Zeile 82:		Zeile 82:

	* Die Sensoren "richtig" betreiben, für ein regelmäßig mit einer bestimmten Abtastrate abgetastetes Zeitsignal. Vielleicht ist dafür der FIFO-Modus da. Im Moment mach ich mir sorgen um Aliasing und dass etwas verloren geht.		* Die Sensoren "richtig" betreiben, für ein regelmäßig mit einer bestimmten Abtastrate abgetastetes Zeitsignal. Vielleicht ist dafür der FIFO-Modus da. Im Moment mach ich mir sorgen um Aliasing und dass etwas verloren geht.
			* Self-Test Funktionen ausnutzen, um zu testen, ob die Sensoren in Ordnung sind
	* Mal so ein Rauschsignal der versch. Sensoren "richtig" angucken (Leistungsdichtespektrum). Die Leistungsdichte um 0 Hz wird dann auch Aufschluss darüber geben, wie genau man überhaupt noch nach einer Stunde Integration sein kann, wenn alles korrekt kalibriert wurde.		* Mal so ein Rauschsignal der versch. Sensoren "richtig" angucken (Leistungsdichtespektrum). Die Leistungsdichte um 0 Hz wird dann auch Aufschluss darüber geben, wie genau man überhaupt noch nach einer Stunde Integration sein kann, wenn alles korrekt kalibriert wurde.
	* Temperaturabhängigkeit nochmal checken über einem größeren Bereich mit mehreren Wiederholungen.		* Temperaturabhängigkeit nochmal checken über einem größeren Bereich mit mehreren Wiederholungen.

SebastianG: /* Ideen/Strategien */

2013-02-23T14:11:56Z

Ideen/Strategien

← Nächstältere Version		Version vom 23. Februar 2013, 14:11 Uhr
Zeile 71:		Zeile 71:
	* Der Orientierungsdrift über die Zeit kann teilwelse über die Beschleunigungsdaten kompensiert werden, so dass oben/unten immer noch oben/unten bleibt, beispielsweise per Complementary Filter. Das klappt soweit ganz gut. Man müsste noch prüfen, ob man das nicht noch verbessern kann, wenn man die Beschleunigungsdaten integrieren will. Die Orientierung sollte da schon stimmen, wenn man die Komponente der Erdanziehung rausrechnen will.		* Der Orientierungsdrift über die Zeit kann teilwelse über die Beschleunigungsdaten kompensiert werden, so dass oben/unten immer noch oben/unten bleibt, beispielsweise per Complementary Filter. Das klappt soweit ganz gut. Man müsste noch prüfen, ob man das nicht noch verbessern kann, wenn man die Beschleunigungsdaten integrieren will. Die Orientierung sollte da schon stimmen, wenn man die Komponente der Erdanziehung rausrechnen will.
	* Um den Orientierungsdrift auch in der horizontalen Ebene zu korrigieren, werden noch andere Daten benötigt. Beispielsweise ein Kompass oder Vorwissen über das "Terrains". Das Treppensteigen sollte sich erkennen lassen. Es sollte auch klar sein, dass man nicht durch Wände gehen kann.		* Um den Orientierungsdrift auch in der horizontalen Ebene zu korrigieren, werden noch andere Daten benötigt. Beispielsweise ein Kompass oder Vorwissen über das "Terrains". Das Treppensteigen sollte sich erkennen lassen. Es sollte auch klar sein, dass man nicht durch Wände gehen kann.
	* Für Zu-Fuß-Navigation bietet sich an, die Sensoren an einem der Schuhe anzubringen. Das ermöglicht ZUPT (zero velocity update). Das Problem, welches dadurch gelöst wird, ist der Geschwindigkeitsdrift über die Zeit, den man sonst bekommen würde, weil die Beschleunigungsdaten verrauscht sind. Bei ZUPT nutzt man aus, dass es immer wieder Momente gibt, wo man genau weiß, dass die Geschwindigkeit Null ist bzw sein müsste. Beim Gehen könnte man versuchen über die Sensordaten die verschiedenen Phasen zu erkennen und dementsprechend die bis dahin berechnete, aktuelle Geschwindigkeit		* Für Zu-Fuß-Navigation bietet sich an, die Sensoren an einem der Schuhe anzubringen. Das ermöglicht ZUPT (zero velocity update). Das Problem, welches dadurch gelöst wird, ist der Geschwindigkeitsdrift über die Zeit, den man sonst bekommen würde, weil die Beschleunigungsdaten verrauscht sind. Bei ZUPT nutzt man aus, dass es immer wieder Momente gibt, wo man genau weiß, dass die Geschwindigkeit Null ist bzw sein müsste. Beim Gehen könnte man versuchen über die Sensordaten die verschiedenen Phasen zu erkennen und dementsprechend die bis dahin berechnete, aktuelle Geschwindigkeit. In [https://www.youtube.com/watch?v=6ijArKE8vKU diesem Video] kann man das schön sehen.
	* Idee für Gyro-Gain Kalibrierung: Über die Beschleunigungssensoren wissen wir, wo im Objektkoordinatensystem oben ist. Dreht man das Objekt um einen bestimmten Winkel, wird der Beschleunigungsvektor auch entsprechend in eine andere Richtung zeigen. Bei kalibrierten Beschleunigungssensoren lässt sich dann dieser Winkel bestimmen und mit dem Winkel vergleichen, den man mit Hilfe der Gyros allein ausrechnen kann. Mit dem Verhältnis dieser Winkel könnte man den Gyro-Gain korrigieren. Ich denke aber, dass man zwecks Genauigkeit größere Drehungen nutzen sollte, siehe nächster Punkt		* Idee für Gyro-Gain Kalibrierung: Über die Beschleunigungssensoren wissen wir, wo im Objektkoordinatensystem oben ist. Dreht man das Objekt um einen bestimmten Winkel, wird der Beschleunigungsvektor auch entsprechend in eine andere Richtung zeigen. Bei kalibrierten Beschleunigungssensoren lässt sich dann dieser Winkel bestimmen und mit dem Winkel vergleichen, den man mit Hilfe der Gyros allein ausrechnen kann. Mit dem Verhältnis dieser Winkel könnte man den Gyro-Gain korrigieren. Ich denke aber, dass man zwecks Genauigkeit größere Drehungen nutzen sollte, siehe nächster Punkt

SebastianG: /* Sensoren */

2013-02-23T07:35:00Z

Sensoren

← Nächstältere Version		Version vom 23. Februar 2013, 07:35 Uhr
Zeile 4:		Zeile 4:

	== Sensoren ==		== Sensoren ==

			Google Tech Talk zum Thema: https://www.youtube.com/watch?v=C7JQ7Rpwn2k

	=== Gyroskop ===		=== Gyroskop ===

SebastianG am 23. Februar 2013 um 06:29 Uhr

2013-02-23T06:29:09Z

← Nächstältere Version		Version vom 23. Februar 2013, 06:29 Uhr
Zeile 1:		Zeile 1:
	Bei der Trägheitsnavigation kommen Inertialsensoren zum Einsatz, die auf Basis der Massenträgheit drei zueinander orthogonale translatorische und drei rotatorische Anteile einer Objektbewegung messen, um auf die Bewegung zurückzuschließen. Wie gut das mit günstigen Sensoren funktioniert, wie sie in modernen Handys verbaut sind oder zum Beispiel auf dem [http://hackaday.com/2012/09/12/stm32-f3-discovery-dev-board-includes-some-extras/ STM32 F3 Discovery Dev-Board] zu finden sind, gilt heraus zu finden.		Bei der Trägheitsnavigation kommen Inertialsensoren zum Einsatz, die auf Basis der Massenträgheit drei zueinander orthogonale translatorische und drei rotatorische Anteile einer Objektbewegung messen, um auf die Bewegung zurückzuschließen. Wie gut das mit günstigen Sensoren funktioniert, wie sie in modernen Handys verbaut sind oder zum Beispiel auf dem [http://hackaday.com/2012/09/12/stm32-f3-discovery-dev-board-includes-some-extras/ STM32 F3 Discovery Dev-Board] zu finden sind, gilt heraus zu finden.

			[https://www.youtube.com/watch?v=0mxQ0c1AvMI Video vom 23.02.2013]

	== Sensoren ==		== Sensoren ==

SebastianG: /* Erledigt */

2013-02-23T06:25:06Z

Erledigt

← Nächstältere Version		Version vom 23. Februar 2013, 06:25 Uhr
Zeile 91:		Zeile 91:

	* (2013-02-12) Eine Kalibrierung wurde in das Programm integriert, die man über Tasten steuert. Der Gyro-Bias, Accelerometer-Gain und Accelerometer-Bias werden bestimmt, wenn man die 3 Objekt-Achsen jeweils nach oben und nach unten zeigen lässt und das Objekt dabei fixiert, dass es sich nicht bewegt. Durch Drücken der P-Taste wird eine Punkt-Messung gestartet, die alle Sensorwerte solange mittelt, bis man die P-Taste wieder loslässt. Das wiederholt man jetzt 6 Mal für alle Achsen und Oben/Unten-Kombinationen. Jedes Mal beim Loslassen der P-Taste werden die intern gespeicherten Kalibrierparameter korrigiert. Eine bestimmte Reihenfolge muss man nicht einhalten. Eine Gyro-Gain Kalibrierung ist auch vorhanden, aber der traue ich noch nicht ganz. Die Integration der Beschleunigungsdaten wurde auch implementiert und funktioniert nicht nicht ganz zufriedenstellend (das Objekt läuft aufgrund von Fehlern weg, obwohl es still steht).		* (2013-02-12) Eine Kalibrierung wurde in das Programm integriert, die man über Tasten steuert. Der Gyro-Bias, Accelerometer-Gain und Accelerometer-Bias werden bestimmt, wenn man die 3 Objekt-Achsen jeweils nach oben und nach unten zeigen lässt und das Objekt dabei fixiert, dass es sich nicht bewegt. Durch Drücken der P-Taste wird eine Punkt-Messung gestartet, die alle Sensorwerte solange mittelt, bis man die P-Taste wieder loslässt. Das wiederholt man jetzt 6 Mal für alle Achsen und Oben/Unten-Kombinationen. Jedes Mal beim Loslassen der P-Taste werden die intern gespeicherten Kalibrierparameter korrigiert. Eine bestimmte Reihenfolge muss man nicht einhalten. Eine Gyro-Gain Kalibrierung ist auch vorhanden, aber der traue ich noch nicht ganz. Die Integration der Beschleunigungsdaten wurde auch implementiert und funktioniert nicht nicht ganz zufriedenstellend (das Objekt läuft aufgrund von Fehlern weg, obwohl es still steht).

			* (2013-02-23) Gyro-Gain Kalibrierung ist flexibler und genauer

	=== Bisher Gelerntes ===		=== Bisher Gelerntes ===

SebastianG: /* TODO */

2013-02-23T06:23:37Z

TODO

← Nächstältere Version		Version vom 23. Februar 2013, 06:23 Uhr
Zeile 79:		Zeile 79:
	* Mal so ein Rauschsignal der versch. Sensoren "richtig" angucken (Leistungsdichtespektrum). Die Leistungsdichte um 0 Hz wird dann auch Aufschluss darüber geben, wie genau man überhaupt noch nach einer Stunde Integration sein kann, wenn alles korrekt kalibriert wurde.		* Mal so ein Rauschsignal der versch. Sensoren "richtig" angucken (Leistungsdichtespektrum). Die Leistungsdichte um 0 Hz wird dann auch Aufschluss darüber geben, wie genau man überhaupt noch nach einer Stunde Integration sein kann, wenn alles korrekt kalibriert wurde.
	* Temperaturabhängigkeit nochmal checken über einem größeren Bereich mit mehreren Wiederholungen.		* Temperaturabhängigkeit nochmal checken über einem größeren Bereich mit mehreren Wiederholungen.
	* überlegen, wie man den Gain der Gyros kalibriert.
	* Mit fertig kalibrierten Sensoren verschiedene Testmessungen mal durchführen, bei denen alles aufgezeichnet wird, beispielsweise eine Ruhemessung oder mit den Sensoren am Schuh befestigt ein bisschen rumlaufen.		* Mit fertig kalibrierten Sensoren verschiedene Testmessungen mal durchführen, bei denen alles aufgezeichnet wird, beispielsweise eine Ruhemessung oder mit den Sensoren am Schuh befestigt ein bisschen rumlaufen.
	* Sich vielleicht um eine Funkverbindung kümmern. Sensoren am Schuh mit Bluetooth oder so?		* Sich vielleicht um eine Funkverbindung kümmern. Sensoren am Schuh mit Bluetooth oder so?

SebastianG: /* Ideen/Strategien */

2013-02-23T05:58:55Z

Ideen/Strategien

← Nächstältere Version		Version vom 23. Februar 2013, 05:58 Uhr
Zeile 68:		Zeile 68:
	* Für Zu-Fuß-Navigation bietet sich an, die Sensoren an einem der Schuhe anzubringen. Das ermöglicht ZUPT (zero velocity update). Das Problem, welches dadurch gelöst wird, ist der Geschwindigkeitsdrift über die Zeit, den man sonst bekommen würde, weil die Beschleunigungsdaten verrauscht sind. Bei ZUPT nutzt man aus, dass es immer wieder Momente gibt, wo man genau weiß, dass die Geschwindigkeit Null ist bzw sein müsste. Beim Gehen könnte man versuchen über die Sensordaten die verschiedenen Phasen zu erkennen und dementsprechend die bis dahin berechnete, aktuelle Geschwindigkeit		* Für Zu-Fuß-Navigation bietet sich an, die Sensoren an einem der Schuhe anzubringen. Das ermöglicht ZUPT (zero velocity update). Das Problem, welches dadurch gelöst wird, ist der Geschwindigkeitsdrift über die Zeit, den man sonst bekommen würde, weil die Beschleunigungsdaten verrauscht sind. Bei ZUPT nutzt man aus, dass es immer wieder Momente gibt, wo man genau weiß, dass die Geschwindigkeit Null ist bzw sein müsste. Beim Gehen könnte man versuchen über die Sensordaten die verschiedenen Phasen zu erkennen und dementsprechend die bis dahin berechnete, aktuelle Geschwindigkeit
	* Idee für Gyro-Gain Kalibrierung: Über die Beschleunigungssensoren wissen wir, wo im Objektkoordinatensystem oben ist. Dreht man das Objekt um einen bestimmten Winkel, wird der Beschleunigungsvektor auch entsprechend in eine andere Richtung zeigen. Bei kalibrierten Beschleunigungssensoren lässt sich dann dieser Winkel bestimmen und mit dem Winkel vergleichen, den man mit Hilfe der Gyros allein ausrechnen kann. Mit dem Verhältnis dieser Winkel könnte man den Gyro-Gain korrigieren. Ich denke aber, dass man zwecks Genauigkeit größere Drehungen nutzen sollte, siehe nächster Punkt		* Idee für Gyro-Gain Kalibrierung: Über die Beschleunigungssensoren wissen wir, wo im Objektkoordinatensystem oben ist. Dreht man das Objekt um einen bestimmten Winkel, wird der Beschleunigungsvektor auch entsprechend in eine andere Richtung zeigen. Bei kalibrierten Beschleunigungssensoren lässt sich dann dieser Winkel bestimmen und mit dem Winkel vergleichen, den man mit Hilfe der Gyros allein ausrechnen kann. Mit dem Verhältnis dieser Winkel könnte man den Gyro-Gain korrigieren. Ich denke aber, dass man zwecks Genauigkeit größere Drehungen nutzen sollte, siehe nächster Punkt
	* Andere Idee für Gyro-Gain Kalibrierung: Das Objekt auf einen Drehteller stellen und einer kontrollierten Drehung (beispielsweise exakt 5 Umdrehungen) um jeweils eine der drei Objekt-Achsen unterziehen. Das dann iwie mit den Gyro-Daten vergleichen und den Gain bestimmen
	* Idee3: Freie Drehungen möglichst ohne Bewegung der Beschleunigungssensoren. Über die Oben/Unten-Korrektur der Orientierung über die Beschleunigungssensoren lassen sich vielleicht auch die Gyro-Gains korrigieren, vielleicht sogar online die ganze Zeit, nachdem die Beschleunigungssensoren komplett kalibriert worden sind.

	=== Was noch so nützllich sein könnte ===		=== Was noch so nützllich sein könnte ===

SebastianG: /* Gyroskop */

2013-02-21T16:55:58Z

Gyroskop

← Nächstältere Version		Version vom 21. Februar 2013, 16:55 Uhr
Zeile 4:		Zeile 4:
	=== Gyroskop ===		=== Gyroskop ===

	liefert ~~Orientierung(?) oder~~ Drehgeschwindigkeit je ~~nach Sensortyp(?)~~. Die ~~kleinen MEMS Gyroskope geben uns die Drehgeschwindigkeit~~.		Ein 3-Achsen [http://de.wikipedia.org/wiki/Mikrosystem_%28Technik%29 MEMS] Gyroskop liefert einem eine Drehgeschwindigkeit je Achse, typischerweise in einem rechtsorientierten Koordinatensystem. Die Achsen drehen sich dabei mit, weswegen man dabei auch von einem [http://en.wikipedia.org/wiki/Inertial_navigation_system#Strapdown_systems "Strapdown System"] spricht.

	Interessante Links dazu:		Interessante Links dazu:

SebastianG: Projekt-Kategorie hinzugefügt

2013-02-21T16:42:13Z

Projekt-Kategorie hinzugefügt

← Nächstältere Version		Version vom 21. Februar 2013, 16:42 Uhr
Zeile 152:		Zeile 152:

	ergeben. Allerdings ist das Rauschen bekannterweise nicht weiß sondern bei den tiefen Frequenzen stärker, was bedeutet, dass der tatsächliche RW-Wert höher sein wird. Ich schätze mal, dass wir eher bei 1 bis 2 °/sqrt(hr) liegen werden, also, dass nach Integrieren über eine Stunde der rausch-induzierte Fehler der Orientierung eine Streuung von etwa 1 bis 2 Grad und der Fehler der Geschwindigkeit eine Streuung von etwa 0.5 m/s haben wird.		ergeben. Allerdings ist das Rauschen bekannterweise nicht weiß sondern bei den tiefen Frequenzen stärker, was bedeutet, dass der tatsächliche RW-Wert höher sein wird. Ich schätze mal, dass wir eher bei 1 bis 2 °/sqrt(hr) liegen werden, also, dass nach Integrieren über eine Stunde der rausch-induzierte Fehler der Orientierung eine Streuung von etwa 1 bis 2 Grad und der Fehler der Geschwindigkeit eine Streuung von etwa 0.5 m/s haben wird.


			[[Category:Projekte]]

SebastianG am 14. Februar 2013 um 17:36 Uhr

2013-02-14T17:36:05Z

← Nächstältere Version		Version vom 14. Februar 2013, 17:36 Uhr
Zeile 1:		Zeile 1:
	Bei der Trägheitsnavigation kommen Inertialsensoren zum Einsatz, die auf Basis der Massenträgheit drei zueinander orthogonale translatorische und drei rotatorische Anteile einer Objektbewegung messen, um auf die Bewegung zurückzuschließen. Wie gut das mit günstigen Sensoren funktioniert, wie sie in modernen Handys verbaut sind oder zum Beispiel auf dem [http://hackaday.com/2012/09/12/stm32-f3-discovery-dev-board-includes-some-extras/ STM32 F3 Discovery Dev-Board] zu finden sind, gilt heraus zu finden.		Bei der Trägheitsnavigation kommen Inertialsensoren zum Einsatz, die auf Basis der Massenträgheit drei zueinander orthogonale translatorische und drei rotatorische Anteile einer Objektbewegung messen, um auf die Bewegung zurückzuschließen. Wie gut das mit günstigen Sensoren funktioniert, wie sie in modernen Handys verbaut sind oder zum Beispiel auf dem [http://hackaday.com/2012/09/12/stm32-f3-discovery-dev-board-includes-some-extras/ STM32 F3 Discovery Dev-Board] zu finden sind, gilt heraus zu finden.

	== Gyroskop ==		== Sensoren ==
			=== Gyroskop ===

	liefert Orientierung(?) oder Drehgeschwindigkeit je nach Sensortyp(?). Die kleinen MEMS Gyroskope geben uns die Drehgeschwindigkeit.		liefert Orientierung(?) oder Drehgeschwindigkeit je nach Sensortyp(?). Die kleinen MEMS Gyroskope geben uns die Drehgeschwindigkeit.
Zeile 8:		Zeile 9:
	* [http://www2.tku.edu.tw/~tkjse/15-3/04-AE10102.pdf Noise Characteristics of MEMS Gyro’s Null Drift and Temperature Compensation]		* [http://www2.tku.edu.tw/~tkjse/15-3/04-AE10102.pdf Noise Characteristics of MEMS Gyro’s Null Drift and Temperature Compensation]

	== Beschleunigungssensoren ==		=== Beschleunigungssensoren ===

	liefern Beschleunigungen. Aufgrund der Erdanziehung ist typischerweise zu erwarten, dass der gemessene Beschleunigungsvector die Summe aus tatsächlicher Beschleunigung und 1g nach oben ist. Dazu kommen dann natürlich noch Messfehler und systematische Fehler.		liefern Beschleunigungen. Aufgrund der Erdanziehung ist typischerweise zu erwarten, dass der gemessene Beschleunigungsvector die Summe aus tatsächlicher Beschleunigung und 1g nach oben ist. Dazu kommen dann natürlich noch Messfehler und systematische Fehler.