Nabend Ich habe ein Beschleunigungssensor (MPU6050) an einem Pendel hängen. Mit diesem Skript: https://github.com/bekspace/lolin_d1_mini-mpu6050/blob/master/d1_mini_mpu.ino kann ich mit die beiden Winkel ausgeben lassen, in denen das Pendel schwingt. Theoretisch schwingt es ja nur in einer Richtung, aber eben nur theoretisch. Außerdem hängt es an einem Seil und dreht sich immer etwas um die eigene Achse. Wie kann ich die beiden Winkel so kombinieren, dass ich immer die Auslenkung aus der Senkrechten, egal in welche Richtung, berechnen kann? Danke und Gruß Kolja
Kolja L. schrieb: > Theoretisch schwingt es ja nur in einer Richtung, aber eben nur > theoretisch. Auch theoretisch spricht nichts gegen z. B. eine kreisende Bewegung. Kolja L. schrieb: > Wie kann ich die beiden Winkel so kombinieren, dass ich immer die > Auslenkung aus der Senkrechten, egal in welche Richtung, berechnen kann? Über den Winkel und Pendellänge kommst du auf die horizontale Auslenkung in die jeweilige Richtung, diese kannst du mit dem Satz des Pythagoras in eine Gesamtauslenkung umrechnen und dann wieder in einen Winkel. Du brauchst dazu erstmal die Länge des Pendels, kürzt sich aber raus. Es geht sicher auch direkter, dazu fehlt mir aber ohne Stift und Papier die Vorstellungskraft.
Ein Pendel befindet sich tangential im freien Fall und hat theoretisch somit nur eine Achse belastet. Die Auslenkung kannst Du nicht messen, nur, wo Du dich relativ zum gesamtausschlag befindest. (Obere Auslenkung bei 0, Maximum unten, > 1g.
Kolja L. schrieb: > dreht sich immer etwas um die eigene Achse. Mit der Erddrehung. https://de.wikipedia.org/wiki/Foucaultsches_Pendel Kolja L. schrieb: > Wie kann ich die beiden Winkel so kombinieren, Vektorrechnung. Das ist ein Dreieck. sqrt(a * a + b * b)
Kolja L. schrieb: > Theoretisch schwingt es ja nur in einer Richtung, aber eben nur > theoretisch. Dann ist deine Theorie falsch. Es kommt auf die Aufhängung und deine Anregung an, wie es schwingt. Wenn zwischen den beiden Schwingungen in den Achsenebenen eine Phasenverschiebung besteht, kann es eine Ellipse oder gar einen Kreis beschreiben.
Ein Pendel ist eine am oberen Ende befestigte Schnur mit einem Gewicht am unteren Ende. Es ist überhaubt kein Problem, dieses Gewicht statt auf einer zweidimensionalen Bahn, auf einer elliptischen, oder gar kreisförmigen Bahn schwingen zu lassen. Außerdem kamm man dem Gewicht noch einen Drall verpassen, die Schnur steuert noch ihren "Senf" bei... Rate mal, warum man sich eine möglichst "ideale Schnur" (ohne Drall, längenstabil auch bei Temperaturänderungen und mit vernachlässigbarer Masse) bei Demo-Pendeln bedient. Dann brennt man einen Faden durch, um das Pendel zu starten, weil das Taumeln des Gewichts unterbunden wird, wenn der Faden genau auf dem Punkt der Oberfläche befestigt ist, der zentral zur Pendelbahn liegt. Kann man alles beiseite schieben! Aber wenn die Schnur ein (hoffentlich drallfreies, längenstabiles) USB-Kabel ist, braucht man schon ein SEHR großes Gewicht, damit sie vernachlässigbare Masse hat. Nur dann gelten die Pendelgesetze. Die Physik gilt immer, ist aber mit z.B. 13 Parametern nicht so leicht zu berechnen, wie mit den 2 Parametern des Ideal-Pendels: Länge und Fallbeschleunigung.
Du willst den Winkel deines Pendels in 3d bestimmen, der MPU liefert Dir 3 Koordinaten für die Erdbeschleunigung: x,y,und z. Der MPU hängt irgendwie am Pendel, dann stellst Du erstmal fest, wo unten ist: Pendel hängt schlapp, Du liest x,y,z aus und nennst die xschlapp, yschlapp und zschlapp. Dann pendelt das Pendel irgendwie, du liest wieder die x,y,z aus. Den Winkel zwischen x,y,z und xschlapp,yschlapp ,zschlapp liefert das https://de.wikipedia.org/wiki/Skalarprodukt Umgeformt: winkel = acos((x*xschlapp+y*yschlapp+z*zschlapp)/( sqrt(xschlapp*xschlapp+yschlapp*yschlapp+zschlapp*zschlapp)* sqrt(x *x +y *y +z *z ))) Linear Algebra rulez! Cheers Detlef
:
Bearbeitet durch User
Detlef _. schrieb: > Den > Winkel zwischen x,y,z und xschlapp,yschlapp ,zschlapp liefert eben nicht. Nur wenn man das Pendel festhält. Nicht wenn es frei fällt (in 2 von 3 Achsen.
A. S. schrieb: > Detlef _. schrieb: >> Den >> Winkel zwischen x,y,z und xschlapp,yschlapp ,zschlapp liefert > > eben nicht. Nur wenn man das Pendel festhält. Nicht wenn es frei fällt > (in 2 von 3 Achsen. Doch.
Detlef _. schrieb: > Doch. Nein, denn durch das Scheingen wirkt eine zusätzliche Radial unt Tangentialkraft auf den MPU6050. Mann kann aber mit ein bisschen Filtertechnik diese mit den stark driftenden Werten der integrierten Winkelgeschwindigkeit so kombinieren, dass das Ergebnis wieder sehr gut stimmt.
von Detlef _. (detlef_a) 16.01.2020 23:05 >Du willst den Winkel deines Pendels in 3d bestimmen, der MPU liefert Dir >3 Koordinaten für die Erdbeschleunigung: x,y,und z. Beim ruhenden Pendel ja, beim bewegten Pendel nein: dort ändert sich die Beschleunigung ständig. Stell Dir eine Schiffschaukel vor und Mädchen mit langen Haaren. An den oberen Umkehrpunkten fliegen die Haare in die Luft.
Hier gibt es ganz unten ein Diagramm, bei dem die verschiedenen Variablen über die Zeit angezeigt werden können: https://www.leifiphysik.de/mechanik/mechanische-schwingungen/grundwissen/fadenpendel
Die animierte Graphik aus der Wikipedia ist auch sehr anschaulich: https://de.wikipedia.org/wiki/Mathematisches_Pendel#/media/Datei:Oscillating_pendulum.gif
Kolja L. schrieb: > Ich habe ein Beschleunigungssensor (MPU6050) an einem Pendel hängen. Das macht die Sache ziemlich schwierig. Nehmen wir einmal ideale Bedingungen an: - Pendelmasse ist punktförmig - Sensor befindet in diesem Massepunkt - kein Luftwiderstand Nehmen wir weiterhin an, der Sensor sei so ausgerichtet, dass seine Z-Achse immer in Richtung der Pendelaufhängung zeigt. Dann sind die in X- und Y-Richtung gemessenen Beschleunigungen beide null, da sich dort die die jeweiligen Komponenten der Beschleunigung der Pendelmasse und der Erdbeschleunigung gegenseitig aufheben. Die gemessene Beschleunigung in Z-Richtung setzt sich zusammen aus der Komponente der Erdbeschleunigung in radialer Richtung und der Zentripetalbeschleunigung:
wobei φ die aktuelle Pendelauslenkung, v die aktuelle Geschwindigkeit der Pendelmasse und r die Pendellänge ist. Die Geschwindigkeit könntest du mit dem im Sensorchip ebenfalls enthaltenen Drehratensensor bestimmen:
ω_x und ω_y sind dabei die gemessenen Winkelgeschwindigkeiten in X- und Y-Richtung. Beide Gleichungen zusammengefasst ergeben
Im Bereich um φ=0 wird das Ergebnis aber wegen
numerisch ungenau. Einfacher und genauer wird die Sache, wenn du den Sensor nicht in der Pendelmasse, sondern im Drehpunkt des Pendels so anbringst, dass er mit der Pendelschwingung mitrotiert, sich aber nicht von der Stelle bewegt. Dann ist
Damit muss die Winkelgeschwindigkeit nicht gemessen werden, und auch die numerischen Probleme fallen mit der arctan2-Funktion weg. Des Weiteren ist das Ergebnis unabhängig von g.
:
Bearbeitet durch Moderator
Moin Danke für eure ganzen Antworten. Ein Umbau der Mechanik ist leider nicht möglich, daher muss der Sensor im Pendel bleiben. Ich versuche mal zu erklären, was das Ganze machen soll. Vielleicht habe ich in der ersten Frage zu sehr um die Ecke gedacht. Ein Pendel hängt an einem Faden (ja, noch ist es ein USB Kabel). Es kann somit frei im Raum schwingen ind sich verdrehen. Im Pendel ist besagter Sensor und eine RGB LED. Was ich jetzt möchte ist, das die LED bei einer richtungsunabhängigen Auslenkung von 45° Rot ist, bei 30° blau und bei 0° grün. Gruß Kolja
>Die Geschwindigkeit könntest >du mit dem im Sensorchip ebenfalls enthaltenen Drehratensensor >bestimmen: Ich hätte eher gesagt, v ist das Integral über wz.
Kolja L. schrieb: > Was ich jetzt möchte ist, das die LED bei einer richtungsunabhängigen > Auslenkung von 45° Rot ist, bei 30° blau und bei 0° grün. Und das geht nur, wenn Du das Pendel festhälst, oder eine ganze Schwingung beobachtest und dann interpolierst. Eine Beschleunigung ist immer nur messbar, wenn man etwa festhält (=Wenn eine Kraft wirkt). Im Freien Fall sind alle Achsen=0g, egal ob Du es einfach fallen lässt, oder ob einen Sensorball mit Schwung in die Luft wirfst. Sobald du es loslässt, sind es 0g, während des ganzen Flugs. Ein Faden kann nur Kraft in eine Richtung aufbringen. In diese Richtung misst Du 1g in Ruhe, bzw. etwas Sinusförmiges z.B. zwischen 0.5g und 1.5g, je nach Auslenkung Also, wenn es Pendelt, dann in einer (halben) Schwingung das Maximum (gmax) bestimmen: 1) Nur die Achse in Richtung Faden auswerten 2) Das Maximum gmax bestimmen 3) Danach in erster Näherung Winkel=ArcCos(Messwert/gmax). Keine Ahnung, ob das schon perfekt ist.
A. S. schrieb: > Und das geht nur, wenn Du das Pendel festhälst, Ich habe ja schon durch das o.g. Skript die Winkel in X und Y Richtung. Das gibt geplottet und in eine Richtung geschwungen einen schönen sinus.
Kolja L. schrieb: > Ich habe ja schon durch das o.g. Skript die Winkel in X und Y Richtung. > Das gibt geplottet und in eine Richtung geschwungen einen schönen sinus. Dann häng die Plots doch mal an. Am Besten mit Skalierung. wenn die beiden Waagerechten Achsen (welche ist Z bei Dir) etwas zeigen, dann ist das natürlich in erster Näherung ein Sinus. Aber der entsteht nur durch Abweichungen vom Schwerpunkt bzw. vom Idealen Pendel und sagt nur was über Deinen konkreten Aufbau.
A. S. schrieb: > und sagt > nur was über Deinen konkreten Aufbau. und dass ich zu jedem Zeitpunkt einen Winkel berechnet bekomme. Den ich js hier verwenden möchte: A. S. schrieb: > Kolja L. schrieb: >> Was ich jetzt möchte ist, das die LED bei einer richtungsunabhängigen >> Auslenkung von 45° Rot ist, bei 30° blau und bei 0° grün. > > Und das geht nur, wenn Du das Pendel festhälst, oder eine ganze > Schwingung beobachtest und dann interpolierst.
Kolja L. schrieb: > und dass ich zu jedem Zeitpunkt einen Winkel berechnet bekomme. Hattest Du schon Daten dazu gepostet?
Kann ich gerne später machen, aber noch verstehe ich den Sinn dahinter nicht.
Kolja L. schrieb: > Kann ich gerne später machen, aber noch verstehe ich den Sinn dahinter > nicht. Wenn Du in den beiden waagerechten Achsen etwas misst, dann nur, weil das Pendel nicht ideal ist, vermutlich der Sensor oberhalb oder unterhalb des Schwerpunkts liegt. Wie hoch die Werte sind, hängt vom Abstand ab. Es geht darum, die ungefähre Größenordnung zu sehen.
A. S. schrieb: > Wenn Du in den beiden waagerechten Achsen etwas misst, ... Was bezeichnest du bei einem pendelnden Sensor als "waagerechte Achse"? Die Fadenspannung ändert sich mit der Bahngeschwindigkeit der Pendelmasse. Ein Sensor der an dieser Position hängt, misst die daraus resultierende Beschleunigung. Wie sich die in die Sensorachsen abbildet, hängt von der Orientierung des Sensor in Bezug auf den Faden ab.
Wolfgang schrieb: > Was bezeichnest du bei einem pendelnden Sensor als "waagerechte Achse"? normalerweise würde man den Sensor so ausrichten, dass im ruhenden Pendel eine Achse (z.B. Z) 1g misst. Die beiden anderen (X, Y) bezeichne ich hier als Waagerecht. Wenn man das Pendel 90° anhebt, hat z.B. X 1g (oder -1g). Oder Y, bzw, immer die Resultierende =SQRT(X²+Y²). Wenn das Pendel aber schwingt, (also nicht von Hand bewegt wird), messen X und Y immer 0, sind also im Prinzip "Waagerecht".
A. S. schrieb: > Wenn das Pendel aber schwingt, (also nicht von Hand bewegt wird), messen > X und Y immer 0, sind also im Prinzip "Waagerecht". Als waagerecht bezeichnet man gewöhnlich etwas statisches - aber nagut ... Damit X und Y immer 0 sind, muss der Sensor sauber im Massenschwerpunkt sitzt und es darf kein Übersprechen/Orientierungsfehler der Sensorachsen geben. Damit man den beiden Achsen eine Richtung zuordnen kann, muss das Pendel torsionsfrei schwingen.
Kolja L. schrieb: > Mit diesem Skript: ... > kann ich mit die beiden Winkel ausgeben lassen, in denen das Pendel > schwingt. > Wie kann ich die beiden Winkel so kombinieren, dass ich immer die > Auslenkung aus der Senkrechten, > egal in welche Richtung, berechnen kann? Vorausgesetzt, das verwendete Skript macht das, was es verspricht, ist die Aufgabe sehr einfach. Für beide Winkel (bezogen auf die Senkrechte) berechnest du den Sinus und quadrierst ihn jeweils. Die quadrierten Werte addierst du und ziehst die Wurzel daraus. Mit der arcussinus Funktion bekommst du aus diesem Wert den gewünschten Winkel. Dieser Rechenweg entspricht dem Umrechnen in zwei horizontal Auslenkungen (x und y). Die sind nicht Massstabs gerecht, weil die Fadenlänge nicht berücksichtigt wird. Die ist aber egal, da es nur um die Winkel geht. Aus den horizontalauslenkungen (x und y) wird mittel Pythagoras die Gesamtauslenkung errechnet und anschliessend wieder in einen Winkel umgerechnet, der dein gewünschtes Ergebnis ist. Eventuelle Bedenken wegen fehlender Beschleunigung im freien Fall sind irrelevant, da sie von einer mathematischen Idealisierung des Pendels ausgehen, die ganz sicher nicht zutrifft. Dein reales Pendel wird kräftig in zwei Ebenen periodisch drehbeschleunigt. Dein Sensor kann das messen und das Skript sollte daraus in zwei Ebenen Winkel aus geben. Viel Erfolg wünscht der Pendler :)
Der Originalcode verwendet neben den Beschleunigungswerten auch die über die Zeit integrierten Winkelgeschwindigkeit von den Drehratensensoren. Ohne diese würde das Verfahren als Winkel einfach 0.0±Rauschen ausgeben (sofern der Sensor im Schwerpunkt der Pendelmasse liegt). Würden nur die integrierte Winkelgeschwindigkeit verwendet, würde das Ergebnis über die Zeit wegdriften und damit beliebig falsch werden. Das Zusammenmischen der beiden Signalquellen begrenzt das Wegdriften zwar, aber verbleibende Fehler dürfte immer noch recht groß sein. Wenn ich das richtig sehe, wird sich das ausgegebene sinusähnliche Signal sowohl bzgl. der Amplitude als auch der Phase deutlich vom tatsächlichen Winkelverlauf unterscheiden. Der Fehler steigt mit der Periodendauer des Pendels an. Immer wenn das Pendel angehalten wird (egal in welcher Winkellage) wird aus den Beschleunigungswerten ein korrekter Winkel berechnet und ausgegeben, der aber mit dem erneuten Anschwingen des Pendels sofort wieder an Genauigkeit verliert.
A. S. schrieb: > Ah. Das hatte ich beim TO wohl überlesen. Hat die Forenssoftware sogar verlinkt ;-) Kolja L. schrieb: > ... (MPU6050) ...
Pendler schrieb: > Für beide Winkel (bezogen auf die Senkrechte) berechnest du den Sinus > und quadrierst ihn jeweils. Die quadrierten Werte addierst du und ziehst > die Wurzel daraus. Mit der arcussinus Funktion bekommst du aus diesem > Wert den gewünschten Winkel. Danke, das funktioniert:
1 | sin_winkel_X = pow(sin(winkel_X * deg_to_rad), 2); |
2 | sin_winkel_Y = pow(sin(winkel_Y * deg_to_rad), 2); |
3 | winkel = asin((sqrt(sin_winkel_X + sin_winkel_Y)) * rad_to_deg ); |
Aber das: Yalu X. schrieb: > Wenn > ich das richtig sehe, wird sich das ausgegebene sinusähnliche Signal > sowohl bzgl. der Amplitude als auch der Phase deutlich vom tatsächlichen > Winkelverlauf unterscheiden. Der Fehler steigt mit der Periodendauer des > Pendels an. macht das Skript leider unbrauchbar. Die Farbe aka der gemessene Winkel hängt sichtbar dem Pendelausschlag hinterher. Sobald ich die Winkelerkennung schneller mache (vorher 0.98 und 0.02) wird das Ergebnis sehr verrauscht und die LEDs flackern unruig bunt.
1 | Total_angle[0] = 0.9 * (Total_angle[0] + Gyro_angle[0] * elapsedTime) + 0.1 * Acceleration_angle[0]; // responds faster to changes, no shift over time observed... |
Ich suche ertsmal eine andere Funktion. Diese Sensoren werden ja auch in Drohnen eingesetzt, also sollte die ja schnell und gnau genug sein. Danke schonmal für eure Hilfen!
Kolja L. schrieb: > Die Farbe aka der gemessene Winkel hängt sichtbar dem Pendelausschlag > hinterher. Wenn der Fehler wirklich nur in der Verzögerung liegen sollte, wäre er rechnerisch zu einem Grossteil korrigierbar. Dass aber andere Komponenten im Fehler enthalten sind, kann wohl nicht ausgeschlossen werden.
Kolja L. schrieb: > acht das Skript leider unbrauchbar. > Die Farbe aka der gemessene Winkel hängt sichtbar dem Pendelausschlag > hinterher. > > Sobald ich die Winkelerkennung schneller mache (vorher 0.98 und 0.02) > wird das Ergebnis sehr verrauscht und die LEDs flackern unruig bunt. Kolja, jetzt konnte ich auch das Script lesen, ich hatte mich vorher auf den Text hier verlassen. Wenn Du einen Drehratensensor (Gyro) hast, dann darfst Du für ein Pendel nur den Auswerten. Der gibt Dir den Winkel direkt und sofort. Das Skript dagegen sieht mir so aus, als wenn es z.B. für eine Drohne gemacht ist. Wie Xalu schon schrieb, ein Gyro läuft Dir weg, darum die "Kalibrierung" oder "Mittelung" mit X und Y. Du kannst den Gyro aber bei jeder halben Schwingung Nullen. Immer wenn der Z-Wert maximal wird (und auch die Drehrate), ist 0°. Also z.B. Winkel und Z-Wert in einer Tabelle speichern und dann im Nachhinein das Maximum Filtern. Noch einfacher: Die Winkelwerte aufnehmen, bis Du (für eine Achse) 2 Extremwerte hast, z.B. -10° ... -30° --> Dann ist der Mittelwert -20°. Und das ist dann auch Dein Offset. Also von jedem neuen Wert -20° abziehen. (Ganz wichtig: In der nächsten Periode, wennn Du z.B. dann 12 und -10 bekommst, Deinen Offset nur ändern um 1°. Am Besten jedoch nur immer Durch einen Filterfaktor geteilt zur Mittelung). Wichtig ist aber (auch wenn ich mich wiederhole) das Verständnis dafür, dass X und Y 0 sind (bzw. nur rauschen) und nicht in die Messung eines frei schwingenden Pendels eingehen dürfen. Nur die Drehraten (UND ggf. die Z-Achse in Fadenrichtung). Also den bisherigen Filter wegschmeißen.
Danke, aber morgen. Dieses ewige kompilieren und hochladen ist echt nervig. Da wünsche ich mir doch eine Skriptsprache (µP]
A. S. schrieb: > ichtig ist aber (auch wenn ich mich wiederhole) das Verständnis dafür, > dass X und Y 0 sind (bzw. nur rauschen) und nicht in die Messung eines > frei schwingenden Pendels eingehen dürfen. Wobei die beiden Achsen für etwas anderes wichtig sind: In Ruhe oder schwingend ist dort 0. Wenn jedoch jemand das Pendel anstößt oder verändert, sind dort Werte ungleich 0 zu messen. In dieser Zeit ist es schwierig, etwas sinnvolles anzunehmen. Am Besten also Lichter aus. Und erst nach einer Pendelzeit mit erneuter Absolutkalibrierung (ohne Filter) wieder was anzeigen. Den Faktor Mensch zu berücksichtigen erfordert viel, viel Erfahrung, mit dem Pendel und mit den Menschen.
Kolja L. schrieb: > Theoretisch schwingt es ja nur in einer Richtung, aber eben nur > theoretisch. > Außerdem hängt es an einem Seil und dreht sich immer etwas um die eigene > Achse. Soll das überhaupt so sein? In deinem anderen Thread zum Thema Pendel warst du damit wohl nicht wirklich glücklich. Kann das Kabel in ein schickes Messingrohr? Die Idee für ein sehr einfaches Lager kam mir letztens aus einer Beobachtung: das Vorhängeschloss an einem Spind (horizontale Bohrung durch Blech, alternativ sollte ein Nagel auch gehen) pendelte mehrere Minuten lang recht brav und die Pendelebene war dabei "selbstjustierend".
Guten Abend Ja, die Idee hat sich weiter entwickelt :-) Ich würde das Pendel jetzt gerne in beide Achsen schwingen lassen. Für den Antrieb möchte ich je einen Motor mit Schwungrad pro Achse nehmen. Dann könnte das Pendel auch kreisen :-) Bzw sich selbst auf einer Achse halten. Quasi so wie dieser Stab: https://www.youtube.com/watch?v=woCdjbsjbPg Nur andersherrum und mit definierter Bewegung anstatt Stillstand. Aber da ich schon so viele Probleme mit dem MPU6050 hatte: entweder ist das Signal zu verrauscht, die Sketche nur unter alten ESP Versionen lauffähig (irgendwas mit dem Interrupt geht wohl nicht mehr), oder sie schmieren ab, sobald sie mehr machen sollen als nur die Winkel berechnen. Lasse ich das Projekt wohl erstmal ruhen. Gruß Kolja
Könntest Du einen Graph der Messdaten zeigen? Es würde mich mal interessieren, wie stark die rauschen.
chris schrieb: > Könntest Du einen Graph der Messdaten zeigen vor allem der Messdaten beim freien Schwingen, und nicht dass verschmierte Ergebnis des Skripts.
Nagut, dann eben alles nochmal ausgepackt. Dieser Sketch: https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/examples/MPU6050_raw/MPU6050_raw.ino Zusammen mit dem Steckbrett über einem 1,5kg schweren Waffeleisen (fürs Lagerfeuer) an einem 130cm langen USB Kabel frei an der Zimmerdecke schwingend, gibt doch ganz ordentliche Werte. Anbei auch die Rohdaten in der .xls. Den Aufbau lasse ich mal stehen, falls noch Pendelwünsche kommen. Gruß Kolja
:
Bearbeitet durch User
Sehr gut, danke :-) Die Messdaten sehen weniger verrauscht aus, als ich gedacht hätte.
Ja, keine Ahnung bei welchen Sketch ich so komische Daten hatte. Damit lohnt es sich ja schon wieder weiter zu machen :-) Danke für die Motivationshilfe.
Kolja L. schrieb: > Anbei auch die Rohdaten in der .xls. Ja, die Werte sind relativ gut: 1) az ist nicht 0, weil das ganze ein wenig schief steht. Ist natürlich einfacher, wenn das genau ausgerichtet ist. 2) weil der Sensor nicht im Schwerpunkt ist (und wegen 1), schwingen ax und ay ein wenig mit, doch die sind ja unrelevant. 3) gy spielt ja für Deine Messung auch keine Rolle Da Du ja die Drehraten hast (und nicht die Winkel), wird es eigentlich noch einfacher, weil Du nur gx und gz auswerten brauchst, jeweils einzeln, mit gx als Beispiel: Bei gx=0 ist das Pendel oben (ay=minimum), bei gx=Maximum oder Minimum ist das Pendel unten (ay=maximum). Wenn Du jetzt einfach z.B. die letzten 20 Werte speicherst, und das Maximum bzw. Minimum erkennst, dann kannst Du ab da die Werte einfach aufsummieren und skalieren, und erhälst den Winkel in Grad. Wenn alles gut läuft, und Du vorzeichenrichtig summierst, hast Du bei nächsten Nulldurchgang wieder Dein Maximum. Durch den Zero-Drift, stimmt das nicht mal annähernd. Hab das mal für 131°pro LSB für die 3 Achsen aufgetragen. Aber Du kannst ja bei jedem Maximum neu auf 0 justieren (und die Abweichung als Zero-Offset mit einrechnen), dann bist Du relativ genau.
> A. S. (achs)
Die meisten Professoren beschweren sich, wenn in Diagrammen keine
aussagekräftige Achsenbeschriftung und Diagrammtitel vorhanden ist.
Schön, dass Du Dir die Mühe gemacht hast, aber es wäre schon hilfreich,
wenn die Achsen beschriftet sind.
Kolja L. schrieb: > keine Ahnung bei welchen Sketch ich so komische Daten hatte Cooler Prototyp, spannendes Projekt :D Der Teufel ist detailverliebt: Vielleicht war zu diesem Zeitpunkt (auch) das USBkabel noch nicht richtig "eingelaufen" und zeigte deshalb gemeinerweise eine belastungsabhängige Längenänderung. Wenn sich nun nach einiger Zeit unter der Zugbelastung die Drähte innerhalb des Kunststoffes "gesetzt" haben schwindet dessen Längenelastizität, und das Pendel wird berechenbarer. TODO: Vibrationsfrei vorgedehnte sauerstofffreie Lautsprecherkabel ("VFVGD3000SSFLSK") für den Home-Hifi-High-End-Bereich verkaufen. Keine Klangverfälschung durch Längenänderung. Ich werde reich werden! SCNR Hoffentlich hebt bei der Vorführung kein Spielkind das Teil in die Höhe, und lässt es dann heruntersausen.
Spasseshalber habe ich den Pendel auch mal aufgebaut, weil ich noch eine Platine mit ESP8266 und einem Mpu6050 Sensor rumliegen hatte. Die Idee dabei war, die Daten nicht über Kabel sonder mittels eines TCP-Servers mit Micropython zu übertragen.
Kleiner Fehler in der Achsenbeschriftung: Die Zeit ist in Millisekunden.
chris schrieb: > Die Idee dabei war, die Daten nicht über Kabel sonder mittels eines > TCP-Servers mit Micropython zu übertragen. An µPython würde ich mich auch gerne mal wagen, um dieses ständige kompilieren loszuwerden. Aber ist natürloch deutich langsamer in der Verarbeitung: µP: 50 Werte pro Sekunde C++: 350 Werte pro Sekunde Für diese Anwendung (und für alle meine anderen auch) egal ;-)
rµ schrieb: > Man kann den Versuch auch mit einem Mobiltelefon und > https://phyphox.org/ machen. Aber damit kann man keine LEDs blinken lassen...
>An µPython würde ich mich auch gerne mal wagen, um dieses ständige >kompilieren loszuwerden. Nur zu: Beitrag "ESP32 Micropython"
Hallo Pendler, ich möchte nach Recherche nochmal bekräftigen, dass der Beschleunigungssensor auf dem Ende eines Fadenpendels die Kraft bzw. Beschleunigung in Richtung des Fadens mißt. Damit läßt sich der Winkel der Auslenkung direkt damit bestimmen, wie ich das weiter oben schonmal gezeigt hatte. Das Ende eines Fadenpendels ist kein Inertialsystem, weil es durch die Schwerkraft und den Faden beschleunigt wird. In diesem Nicht-Inertialsystem treten 'Scheinkräfte' auf, das sind in diesem Fall die 'Trägheitskraft' und die 'Zentrifugalkraft'. Eine andere prominente Scheinkraft ist die Corioliskraft. 'Trägheitskraft': angenommen das Fadenpendel hat den Maximalwert seiner Auslenkung erreicht und der beträgt gerade 90°, die Geschwindigkeit des Pendels ist 0. Der Beschlenigungssensor ist schwerelos, er mißt die Beschleunigung 0. Die Erdbeschleunigung wird durch die 'Trägheitskraft' genau kompensiert. 'Zentrifugalkraft': beim Duchgang des Pendels durch seine Ruhelage ist die Geschwindigkeit maximal, der Sensor mißt Gravitation plus 'Fliehkraft'. Diese 'handwaving' Erklärung ist für mich leider nur einleuchtend, ich würde die Berechnung der Kräfte in beschleunigten Bezugssystemen für das Beispiel gern nach https://de.wikipedia.org/wiki/Beschleunigtes_Bezugssystem durchführen, wozu ich aber leider mathematisch nicht in der Lage bin ;(( math rulez, though! Cheers Detlef
A. S. schrieb: > Yalu X. schrieb: >> Drehratensensoren > > Ah. Das hatte ich beim TO wohl überlesen. Er hat geschrieben "Beschleunigungssensor MPU6050". Nun ist es aber so daß der MPU6050 ein recht häufig anzutreffendes 6-Achs-Gyro-Accelerometer Kombigerät ist, also 3-Achs Gyro und 3-Achs Accelerometer in einem Gehäuse. OP hat sich also unklar ausgedrückt als er salopp "Beschleunigungssensor" schrieb.
Hi, ich gebe auch mal meinen Senf dazu. Nimm einfach den „richtigen“ Sensor für deine Anforderung. Klassischer weise ein Magnetometer. Der misst die relative Lage zum Erdmagnetfeld. Nord, Süd und bei Schräglage die Änderung des Feldes. Wenn der alleine nicht flott genug für deine Anwendung ist, kommt ein Drehratensensor hinzu und gut is. Wenn ich mich nicht irre, gibt es das als All in One Keks Smartphone Sensor, für hinterhergeworfen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.