Vorübergehender Abfall der Schwerkraftanzeige des Beschleunigungsmessers während der Bewegung

Ich verwende den Beschleunigungsmesser von Pololu AltIMU-10 v4, um die Beschleunigung meines Systems zu überwachen. Ich verstehe, dass der Sensor, wenn er aufrecht auf den Tisch gestellt wird, 1 g in der + ve z-Achse messen sollte. Wenn ich es jedoch auf den Tisch lege und in x- und y-Richtung auf dem Tisch schiebe, sehe ich, dass dieses gemessene 1 g in der z-Achse während der Bewegung abfällt und nach dem Ende der Bewegung auf 1 g zurückgeht. Diese Änderung der Z-Achsen-Messwerte hat immer die Form eines Abfalls, unabhängig davon, ob die tatsächliche Bewegung in +ve oder -ve x- oder y-Richtung erfolgt.

In der folgenden Grafik habe ich den folgenden Bewegungsablauf ausgeführt:

  1. Gleitbewegung in -ve x-Achse auf dem Tisch.
  2. Gleitbewegung in +ve y-Achse auf dem Tisch.
  3. Handgeführte Aufwärtsbewegung in +ve z-Achse in der Luft.
  4. Handgeführte Abwärtsbewegung in -ve z-Achse in der Luft.
  5. Gleitbewegung in -ve y-Achse auf dem Tisch.
  6. Gleitbewegung in +ve x-Achse auf dem Tisch.
  7. Zufällige Drehungen des Sensors, um die Änderung der gemessenen Schwerkraft zu sehen.

Messwerte des Beschleunigungsmessers und die berechnete Größe (Norm)

Es ist ersichtlich, dass zwar die erwartete Beschleunigung in der Bewegungsachse gemessen wird, die gemessene Schwerkraft jedoch während der Bewegung abfällt. Ist dies das erwartete Verhalten für einen Beschleunigungsmesser?

Wenn ja, wie kann ich diesen vorübergehenden Abfall aus meinen Messwerten entfernen? Ich verstehe, dass die Schwerkraftkomponente entfernt werden kann, indem der globale [0 0 1]-Vektor auf den Sensorrahmen bezogen und von der Sensormessung subtrahiert wird. Aber das hilft nicht bei diesem vorübergehenden Abfall.

Sie haben einen guten Test durchgeführt, es scheint, dass der Sensor nicht sehr gut funktioniert. Ich bin sicher, dass kleine MEMS-Beschleunigungsmesser alle möglichen nichtlinearen Probleme mit npn-orthogonalen Achsen haben, die in der Software behoben werden. Gibt es vielleicht eine aktualisierte Bibliothek für das Gerät?
Probieren Sie denselben Test mit Ihrem Telefon und einer Beschleunigungsmesser-Monitor-App wie Physics Toolbox aus. Ich sehe den von Ihnen beschriebenen Effekt nicht, aber ich kann ihn simulieren, indem ich das Telefon in Bewegungsrichtung kippe . Ist es möglich, dass Sie das Gerät beim Verschieben nicht flach auf dem Tisch halten?
@tomnexus Was die Sensorablesungen betrifft, habe ich keine Bibliotheken verwendet, sondern die Register direkt gemäß dem Sensordatenblatt geschrieben / gelesen (mit BeagleBone Black). Aber ich denke, Pololu bietet eine Sensorbibliothek für Arduino-Benutzer. Ich werde versuchen, zu sehen, ob zusätzliche Optimierungen dort drüben vorgenommen werden.
@tomnexus Was das Neigen des Sensors betrifft. Es ist durchaus möglich, dass ich den Sensor während der Bewegung etwas verkantet habe, da ich es von Hand gemacht habe. Aber ich denke, der Winkel wäre sehr klein gewesen (1 oder 2 Grad vielleicht?). Es ist auch ungewöhnlich, dass für alle Bewegungen in x und y die Änderung der z-Achsenmessung in die gleiche Richtung (-ve) und mit einer ähnlichen Größe (~ 0,4-0,5 g, was ziemlich groß ist) erfolgt. Ich werde versuchen, dies mit einem Roboterarm zu bestätigen, um den Sensor während der Bewegung so flach wie möglich zu halten.
Was ist der Gyro-Chip auf dem verwendeten Gerät?
@Andyaka, der Gyro-Chip auf Pololu AltIMU-10 v4 ist L3GD20H, und der Beschleunigungsmesser + Magnetometer-Chip ist LSM303D.
Es kann sein, dass während der Herstellung der interne Sensormechanismus leicht geneigt platziert wurde. Daher ist die Z-Achse, die Sie basierend auf dem Außengehäuse in Betracht gezogen haben, möglicherweise nicht die Z-Achse des internen Sensors. Um also nur Z-Achsen-Messwerte zu erhalten, müssen die Koordinaten für die Z-Achsen-Bewegung (ohne X, Y) gedreht werden, um die interne Z-Achse mit der externen Z-Achse auszurichten ... Nicht-Null-Komponenten in der X-, Y-Achse für die Z-Achse Bewegung könnte sein, 1g sin (\theta) und 1g cos (theta)
Ich schlage vor, dass Sie diese Ergebnisse Leuten unter forum.pololu.com oder support@pololu.com zeigen.
Haben Sie überprüft, ob Ihre Versorgung stabil ist? Es sieht so aus, als würde die Z-Achse sinken, wenn die anderen beiden Achsen geändert werden, egal in welche Richtung. Wenn Ihre Stromschiene dies tut (aufgrund unzureichender Leistung, Überlastung der Antriebsschiene des Chips oder aus anderen Gründen), ändert sich wahrscheinlich die Z-Achse.
Ich unterstütze die Überwachung der Versorgungsspannung und eventueller zusätzlicher Glättungskapazität. Ein weiterer Test wäre auch zu sehen, ob der Fehler ein Einbruch oder eine Spitze ist, wenn der Sensor vor dem Test in der Z-Richtung invertiert wird. Wird die Spike-Polarität auch umschalten, wenn ja, würde dies die Theorie von =stiebrs stützen. Wenn die Spitzenrichtung gleich bleibt, würde dies die Theorie von =Cristobol P stützen.

Antworten (1)

Es könnte an der verwendeten Sensortechnologie liegen. Wenn sie eine federbelastete Masse zum Erfassen verwenden, können Sie erwarten, dass der Kraftvektor während der seitlichen Bewegung in gewissem Maße versetzt wird. Wenn Sie davon ausgehen, dass die Gesamtlänge der Feder begrenzt ist, wird sie auf der Z-Achse auf die für die Bewegung zulässige Restlänge gekürzt.

ZB ist die Summe der Kräfte E konstant 1 (oder etwas darüber). Wenn nur die Schwerkraft daran arbeitet, "verbraucht" es das meiste davon. Wenn Sie eine seitliche Bewegung auf der +X-Achse mit einer Größe > 1 einführen, fällt Z auf 0, da es "überwältigt" ist. Wenn Sie eine Bewegung auf der +X-Achse mit einer Größe von weniger als 1 (z. B. 0,5) einführen, erhalten Sie einen viel geringeren Einbruch in Z, aber er ist immer noch vorhanden. Was der Fall zu sein scheint.

Verdammt, es ist schwer zu erklären, aber ich habe es irgendwo in meinem Kopfraum :) Dieses Bild sollte es etwas veranschaulichen: Geben Sie hier die Bildbeschreibung einaußer hier sind Federn ideal, während sie in Wirklichkeit Steifheits- und Elastizitätskoeffizienten haben, die die "Decke" begrenzen

Ich habe diesen speziellen STM-Sensor nicht verwendet, aber andere von ihnen (LIS2/3) scheinen solche Eigenschaften nicht aufzuweisen.

Gut erklärte mögliche Nichtlinearität des Federungssystems außerhalb der Ruheposition. Ich würde hoffen, dass diese Effekte gering sind, aber es ist eine potenzielle Fehlerquelle.
Ich hatte von solchen Nichtlinearitäten eine sehr geringe Fehlergröße erwartet, daher war es für mich sicherlich eine Überraschung, ein solches Maß an Verzerrungen zu sehen. Jedenfalls habe ich es durch Erkennung und Zurückweisung der Verzerrungen in meinem Softwareprogramm umgangen (die Erkennungs- / Zurückweisungsroutine ist sehr spezifisch für meine Anwendung). Entschuldigung, dass ich etwas länger gebraucht habe, um zu antworten!