Korrekte Berechnung des Winkels über einen Drehratensensor

' schrieb:Oh.

Ich gehe mal davon aus, dass der Gyros-DingsDa (spricht: was das ist - keine Ahnung)

Gyroskop. Das ist im Prinzip ein in allen drei Bewegungsachsen frei hängender Kreisel der zur Navigation benützt wird. Durch die Massenträgheit des Kreisels versucht dieser sich immer in der gleichen Position zu halten, sodass man durch messen des Winkels dieses Kreisels in allen drei Achsen die relative Lage und durch die Messung der dynamischen Veränderung aber auch Beschleunigung erhalten kann.

Hier is noch ein sehr nettes Bild, das die Funktion des Gyroskopes sehr anschaulich verdeutlicht. Das Foto des Flugzeuggyroskopen in der deutschen Wikipedia ist dafür eher ungeeignet

Anzeige

' schrieb:Das ist im Prinzip ein in allen drei Bewegungsachsen frei hängender Kreisel der zur Navigation benützt wird.

Ich habs doch gleich gewusst, dass das was mit meinem Gyros zu tun hat. Das Gyros heißt ja auch Gyros, weil sich der Fleichspieß dreht, nicht weil Lamm, Schwein und/oder Pute drinn ist.

Zitat:Hier is noch ein sehr nettes Bild,

Das hab ich als Spielzeug zu Hause. Nur dreht sich da das Innere (leider Kugel statt Fläche). Der äußere Ring ist fixiert.

' schrieb:Du musst bestimmte Festlegungen treffen: Der µC samplet alle 1ms einen Wert und schickt den zu deiner Applikation. Die weis jetzt, dass die Y-Werte ein dt von 1ms haben. Nun kannst du die Intergartion auch von Hand machen: Einfach Summe = dt*Y. (Ich würde hierzu ein paralleles SubVI machen, das nur die Y-Werte liest und dann z.B. als 100er-Pakete per Queue weitergibt - und das so schnell wie möglich.) Eine zeitunkritische Hauptschleife würde dann die Intergartion mit diesen 100er-Paketen machen.

Das ist eine gute Idee! Ich habe aber noch ein Problem: die Anfrage, die Daten zu senden kommt ebenfalls von LabVIEW, d.h. auch per USB. Es ist nicht so, als wenn man den uC nur einmal ein Startzeichen gibt und er dann selbsttaetig Daten schickt (so wie ich das bis jetzt in der VI erkenne)...
Entsprechend treten dann diese "Fehler" schon beim Anfordern auf und deswegen waeren dann die Werte immer noch falsch... Oder?
Muesste am besten die uC Software anpassen, aber wenn ich das mache, dann muesste ich vermutlich das gesamte VI umbauen. Das ist aber nicht das Ziel dieses Unternehmens. Die Idee mit der Integration der Signale sollte nur als Einstieg in LabVIEW dienen, nicht das gesamte Projekt umzukrempeln. Wenn es ein allzu grosser Aufwand werden sollte, lasse ich es lieber.

Muss eher dafuer sorgen, Bluetooth zu implementieren und nen Akku draufpflanzen um die Daten absolut drahtlos zu uebertragen =)...

' schrieb:Ich habe aber noch ein Problem: die Anfrage, die Daten zu senden kommt ebenfalls von LabVIEW, d.h. auch per USB. Es ist nicht so, als wenn man den uC nur einmal ein Startzeichen gibt und er dann selbsttaetig Daten schickt (so wie ich das bis jetzt in der VI erkenne)...

Und das mit einem Gyroskop?!

Zitat:Entsprechend treten dann diese "Fehler" schon beim Anfordern auf und deswegen waeren dann die Werte immer noch falsch... Oder?

Mit einem solchen Verfahren kann man Einzelwerte abfragen, aber keine auswertbaren Messreihen. Hier gibt es keinerlei Zeitbezug! Eine Integration ist also völlig sinnlos.

Zitat:Muesste am besten die uC Software anpassen, aber wenn ich das mache, dann muesste ich vermutlich das gesamte VI umbauen.

Naja. Das Anpassen des VIs sollte sich darauf beschränken, den Request zu streichen und lediglich die Daten, die jetzt im festen Raster kommen, einzulesen.

Zitat:Die Idee mit der Integration der Signale sollte nur als Einstieg in LabVIEW dienen,

Kein Problem.
Die die Integration geht hat du bereits programmiert. Als Fazit schreibst du: geht leider nicht genauer, weil ....

' schrieb:Und das mit einem Gyroskop?!
Mit einem solchen Verfahren kann man Einzelwerte abfragen, aber keine auswertbaren Messreihen. Hier gibt es keinerlei Zeitbezug! Eine Integration ist also völlig sinnlos.

Naja, was ich vielleicht noch erwaehnen sollte: Die LabVIEW Software ist eigentlich nur zum "Prollen" da =). Sie dient dafuer, Kunden die Moeglichkeiten des Sensors in einer moeglichst augenfreundlichen Weise darzustellen. Geht ja auch ziemlich einfach mit LV... Und erfuellt seinen Zweck allemal. Korrekte Messwerte fuer Testreihen und Verifikation bekommen wir ueber einen CAN Bus, der ebenfalls auf dem Board drauf ist. Damt bekommen wir die Daten in Echtzeit und ohne Umwege von USB.

' schrieb:Naja. Das Anpassen des VIs sollte sich darauf beschränken, den Request zu streichen und lediglich die Daten, die jetzt im festen Raster kommen, einzulesen.

Jo, also muss ich ueberall, wo eine Anfrage ist das Programm umbauen. Und das ist an ziemlich vielen Stellen. Man koennte auch versuchen die VI, die fuers Anfordern der Daten zustaendig ist so umzubauen, dass sie nichts macht ausser auf die Daten zu warten...

' schrieb:Kein Problem.
Die die Integration geht hat du bereits programmiert. Als Fazit schreibst du: geht leider nicht genauer, weil ....

Naja das mit der Integration hat mir keiner aufgetragen, sondern ich selbst habe mir gedacht dass das doch ziemlich gut aussehen wuerde (vor allem fuer einen Kunden) und somit als Uebung sehr gut geeignet ist. Man stelle sich nur vor, wenn man dann ein 3D Modell des Boards im Rechner hat, dessen Ansicht sich entsprechend der echten Bewegung des Boards, welches man in den Haenden bewegt, aendert...