Hallo,
Ich bin gerade dabei einen Fahhradbblinker zu bauen mit Bremslicht.
Konkret sind es 12 LEDs die Rot aufleuchten sollen wenn man "bremst".
Ich habe einen G-Sensor verbaut (LIS3DH) und lese die Z Achse aus.
Wenn Z Achse größer als (zb) -2 dann alle LEDs Rot.
habe aber jetzt das Problem das wenn man die Platine um die X Achse
dreht man die Z achse sozusagen in die Erdanziehugnskraft reindreht und
diese die LEDs dann rot werden lässt obwohl mman nicht bremst.
Hat da jemand vllt eine Idee wie ich das lösen kann?
Die Summe aus X,Y und Z ergibt ja die Erdanziehungskraft von 9,81m/s².
Das konnte ich durch messungen auch beweisen...
Habe dann das probiert:
Signed int beschleu = Abs(lis.x) + Abs(lis.y) + lis.z - 10000
-10000 ist dabei die ungefähre erdanziehung.
Dabei kam aber nur Sche***e raus...
Gruß
Patrick
Patrick schrieb:> Die Summe aus X,Y und Z ergibt ja die Erdanziehungskraft von 9,81m/s².> Das konnte ich durch messungen auch beweisen...> Habe dann das probiert:
Nein.
Die Wurzel der Quadrate ist 1g. Pythagoras, 2 Mal nacheinander.
>Konkret sind es 12 LEDs die Rot aufleuchten sollen wenn man "bremst".>Ich habe einen G-Sensor verbaut (LIS3DH) und lese die Z Achse aus.>Wenn Z Achse größer als (zb) -2 dann alle LEDs Rot.
Ist Z nicht eigentlich die Senkrechte? Aber egal, den Sensor kann man je
drehen, wiee man will.
>habe aber jetzt das Problem das wenn man die Platine um die X Achse>dreht man die Z achse sozusagen in die Erdanziehugnskraft reindreht und>diese die LEDs dann rot werden lässt obwohl mman nicht bremst.>Hat da jemand vllt eine Idee wie ich das lösen kann?
Pythagoras, oder machs wie üblich mit Schalter ...
>Die Summe aus X,Y und Z ergibt ja die Erdanziehungskraft von 9,81m/s².
Seit wann denn das?
>Das konnte ich durch messungen auch beweisen...
Glaub' ich nicht.
>Habe dann das probiert:>Signed int beschleu = Abs(lis.x) + Abs(lis.y) + lis.z - 10000>-10000 ist dabei die ungefähre erdanziehung.>Dabei kam aber nur Sche***e raus...
Tja, dann war wohl Dein Beweis Scheiße ...
Wenn nichts hilft, kannst du einen Chip nehmen der sowohl Gyroskop als
auch Beschleunigungssensor in einem ist: MPU-6050
Der Accelerometer gibt dann unabhängig von der Schwerkraft, Werte aus.
A. S. schrieb:> Alex G. schrieb:>> Der Accelerometer gibt dann unabhängig von der Schwerkraft, Werte aus.>> Wie das?
Da er ein Gyroskop integriert hat, welches die Schwerkraft bestimmt,
rechnet er diese automatisch heraus.
Danke für deine Antwort, ich habe ein MPU-6050 Board bestellt.
Habe zumglück I²C Messpunkte auf meiner Platine weshalb es einfach ist
diesen zu integrieren.
Also verstehe ich das richtig das wenn ich Accelaration Z auslese
bekomme ich automatisch den wert wo die Erdanziehugnskraft schon
rausgerechnet ist?
Ich kann diesen Wert direkt weiterverwenden und muss nix weiter
umrechnen?
Vielen dank für deine Hilfe.
Und an die anderen:
Die Harware existiert schon und die Aufgabenstellung war das ganze ohne
Kabel etc zu realisieren.
Gruß
Patrick
Patrick G. schrieb:> Danke für deine Antwort, ich habe ein MPU-6050 Board bestellt.> Habe zumglück I²C Messpunkte auf meiner Platine weshalb es einfach ist> diesen zu integrieren.>> Also verstehe ich das richtig das wenn ich Accelaration Z auslese> bekomme ich automatisch den wert wo die Erdanziehugnskraft schon> rausgerechnet ist?> Ich kann diesen Wert direkt weiterverwenden und muss nix weiter> umrechnen?
Nicht 100% sicher ob as im Chip passiert oder im Code den das anspricht.
Hab den nur mit der Adafruit lib bislang verwendet.
Falls nicht, musst du aber nur die Vektoren des Gyroskops von denen des
Accelerometers abziehen.
Dies befreit dich jedoch nicht davon zu berücksichtigen in welchem
Winkel zum Fahrrad du das Teil verbaust. Du wirst im Stillzustand, einen
Vektor um die 0,0,0 erhalten (sieht man hier schön:
https://www.youtube.com/watch?v=M9lZ5Qy5S2s ). Welcher Wert sich in
welche Richtung beim Abbremsen verändert íst weiterhin von der
Einbaurichtung abhängig. Wenn der nicht parallel zu einer Achse ist,
werden sich alle 3 Werte ändern.
EDIT: Im prinzip wäre eine automatische Kalibrierung schon denkbar.
Durch den Gyroskop weiss man ja in welchem Winkel zur Erde das ganze
steht. Solang dann garantiert ist, dass beim Kalibrieren, das Fahrrad
nicht bewegt wird, kann man die Eulerwinkel-Diferenz im Vergleich zur
Normalposition (also zum Vektor 0,0,9.81) errechnen und diese
Transformation später umgekehrt auf den Accelerometer-Vektor anwenden.
Dann wären X, Y und Z Achsen immer die realen achsen relativ zum Boden.
Erfordert aber etwas Mathematikkenntnisse und für deinen Anwendungsfall
ist das wohl eher nicht nötig solang du nicht ein Produkt bauen willst
das jeder Nutzer in einem anderen Winkel an seinem Fahrrad anbaut.
M.K. B. schrieb:> Wenn man das ganze mit einem Dynamo betreibt, dann kann man das anhand> der Eingangsfrequenz bestimmen.
Eine recht gute Idee!
Alex G. schrieb:> Da er ein Gyroskop integriert hat, welches die Schwerkraft bestimmt,> rechnet er diese automatisch heraus.
Oh, das geht? Ich dachte, ein Gyro misst Drehraten.
A. S. schrieb:> Alex G. schrieb:>> Da er ein Gyroskop integriert hat, welches die Schwerkraft bestimmt,>> rechnet er diese automatisch heraus.>> Oh, das geht? Ich dachte, ein Gyro misst Drehraten.
Hmm, guter Punkt, das stimmt.
In "MEMS" Form wird sowas verbaut:
https://en.wikipedia.org/wiki/Vibrating_structure_gyroscope
Wahrscheinlich wird die Schwerkraft dann doch über den
Beschleunigungssensor herausgerechnet, denn es ist nicht nötig dass der
Sensor dauerhaft unter Strom steht oder kalibriert wird, wie es bei
einem traditionellen Gyro nötig wäre.
Auf jeden Fall lassen sich Schwerkrafts-Vektor und Beschleunigungsvector
voneinander trennen, wie man auch in dem Video da als separate Werte
sieht.
Auf Smartphones gibt es übrigens etliche Apps die diese Vektoren
getrennt voneinander sogar in 3D zeigen da dort die slebe Sensor-Kombi
verbaut wird.
Genau so wie in Drohnen.
A. S. (achs) schrieb:
>Alex G. schrieb:>> Da er ein Gyroskop integriert hat, welches die Schwerkraft bestimmt,>> rechnet er diese automatisch heraus.>Oh, das geht? Ich dachte, ein Gyro misst Drehraten.
Und ich dachte, es reagiert auf Drehbeschleunigungen (nicht
Drehraten/-geschwindigkeiten), genau so, wie ein Accelerometer auf
lineare Beschleunigungen (nicht Geschwindigkeit) reagiert.
Patrick G. (patrick_g390) schrieb:
>Also verstehe ich das richtig das wenn ich Accelaration Z auslese>bekomme ich automatisch den wert wo die Erdanziehugnskraft schon>rausgerechnet ist?
Das glaube ich nicht. Z wird genau so behandelt wie X und Y. Man kann
also X, Y, Z für jede Koordinate benutzen, wenn man unbedingt will. Die
Erdanziehung muß man schon selbst rausrechnen.
Alex G. schrieb:> A. S. schrieb:>> Alex G. schrieb:>>> Der Accelerometer gibt dann unabhängig von der Schwerkraft, Werte aus.>>>> Wie das?> Da er ein Gyroskop integriert hat, welches die Schwerkraft bestimmt,> rechnet er diese automatisch heraus.
Damit würde das Ding gegen das Äquivalenzprinzip der Relativitätstheorie
verstoßen.
Es kann nicht unterschieden werden ob eine Messung auf Grund von
Gravitation oder von Beschleunigung herrührt.
Wenn du ein solches Gerät allerdings konstruiert hast: Wann nimmst du
deinen Nobelpreis entgegen?
Jens G. schrieb:> Und ich dachte, es reagiert auf Drehbeschleunigungen (nicht> Drehraten/-geschwindigkeiten), genau so, wie ein Accelerometer auf> lineare Beschleunigungen (nicht Geschwindigkeit) reagiert.
Das wäre übel, weil man noch einmal mehr integrieren müsste.
Auf der anderen Seite würden es dann auch 3 weitere G-sensoren tun und
man könnte die Kreiselmesser sparen.
Cyblord -. schrieb:> Damit würde das Ding gegen das Äquivalenzprinzip der Relativitätstheorie> verstoßen.> Es kann nicht unterschieden werden ob eine Messung auf Grund von> Gravitation oder von Beschleunigung herrührt.> Wenn du ein solches Gerät allerdings konstruiert hast: Wann nimmst du> deinen Nobelpreis entgegen?
Schau dir das Video in meinem obigen Beitrag an. Dort sind die beiden
Vektoren jedenfalls getrennt und die App Z-DeviceTest kann die auf einem
smartphone auch getrennt anzeigen. Der "Gyroscope" gibt die Orientierung
des phones aus und Linear-Acceleration gibt bei still haltendem Handy
immer 0,0,0 aus, unabhängig von der Orientierung.
Was du sagst klingt logisch, aber irgendwie funktioniert es trotzdem :D
A. S. (achs) schrieb:
>Jens G. schrieb:>> Und ich dachte, es reagiert auf Drehbeschleunigungen (nicht>> Drehraten/-geschwindigkeiten), genau so, wie ein Accelerometer auf>> lineare Beschleunigungen (nicht Geschwindigkeit) reagiert.>Das wäre übel, weil man noch einmal mehr integrieren müsste.
Ja, das mußt Du wohl machen.
Allerdings - der Gyro im erwähnte MPU6050 scheint wohl wirklich schon
die erste Integrationsstufe zu machen, gibt also tatsächlich eine
Drehrate aus.
Alex G. schrieb:> Was du sagst klingt logisch, aber irgendwie funktioniert es trotzdem :D
Es funktioniert in der Realität weil man verschiedene Sensorwerte
geschickt kombiniert. Außerdem kann man kurzfristige Beschleunigungen
immer recht gut gegenüber der statischen Erdbeschleunigung rausrechnen.
Aber das geht nicht ewig. Bei längeren Beschleunigungen hast du Probleme
mit Drift.
Ein Accelerometer gibt immer 1g in Richtung Erdboden (Z) aus wenn das
Ding ansonsten ruhig ist. Beschleunigst du es aber in z.B. X Richtung
ebenfalls mit 1g, weiß du nicht mehr wo oben und unten ist. Was
Gravitation und was Beschleunigung ist.
Und natürlich geben Gyros schon direkt die Drehrate aus. Sonst wären es
Accelerometer.
Jens G. schrieb:> Ja, das mußt Du wohl machen.
Warum? Gyros messen das doch zum Glück direkt.
> Allerdings - der Gyro im erwähnte MPU6050 scheint wohl wirklich schon> die erste Integrationsstufe zu machen, gibt also tatsächlich eine> Drehrate aus.
Ach.
Alex G. schrieb:> Was du sagst klingt logisch, aber irgendwie funktioniert es trotzdem :D
Ergänzend zum Cyblord: wenn Du einmal in Ruhe bist (keine Drehung, keine
Beschleunigung) dann weißt du, wo "Erde" ist. )Wenn du ein bisschen
wartest, weißt Du sogar, wo Norden ist, wegen der erddrehung).
Wenn Du Jetzt die Drehraten integriert, weißt Du immer noch, wo Erde
ist, selbst im freien Fall (alle Achsen 0 g) oder beliebigen Bewegungen.
Achterbahnfahrt z.b.
A. S. schrieb:> Alex G. schrieb:>> Was du sagst klingt logisch, aber irgendwie funktioniert es trotzdem :D>> Ergänzend zum Cyblord: wenn Du einmal in Ruhe bist (keine Drehung, keine> Beschleunigung) dann weißt du, wo "Erde" ist. )Wenn du ein bisschen> wartest, weißt Du sogar, wo Norden ist, wegen der erddrehung).>> Wenn Du Jetzt die Drehraten integriert, weißt Du immer noch, wo Erde> ist, selbst im freien Fall (alle Achsen 0 g) oder beliebigen Bewegungen.> Achterbahnfahrt z.b.
Logisch. Das würde allerdings bedeuten diese Sensoren kalibrieren sich
automatisch? Denn von Hand muss man das ja nie auslösen. Auch nach
Trennen vom Strom nicht.
Hmm, wo ich jetzt drüber nachdenke ist das wohl plausibel. Der Sensor
kann relativ gut einschätzen ob das Gerät grade ruig steht indem es nur
kalibriert wenn es keine Beschleunigungs-änderungen gibt und dann am
besten auch noch vergleicht ob der Gesamtvektor ungefär bei 9.8 liegt.
Alex G. schrieb:> ndem es nur kalibriert wenn es keine Beschleunigungs-änderungen gibt
Dann ist's am einfachsten. Ohne kontinuierliche Drehung kann er auch
einfach einen längeren Zeitraum betrachten und alle anderen
Beschleunigungen rausrechnen. Die halten nämlich nicht lange an. 1g
beschleunigt in 10s auf 360km/h. Wenn Du in 10s nur wild herumfuchtelst,
spielt das im Verhältnis keine Rolle.
Hallo,
danke für eure vielen Antworten.
Allerdings ist für mich erstmal relativ unwichtig wie die Physik
dahinter funktioniert.
Ich muss einfach nur wissen wie ich aus einem MPU6050 die Z Achsen
Beschleunigung ohne Erdanziehungskraft bekomme....
Eventuell könnte mir das ja kurz jemand erklären..
Trotzdem vielen dank das ihr euch alle soviele Gedanken darüber macht :)
Patrick G. schrieb:> Ich muss einfach nur wissen wie ich aus einem MPU6050 die Z Achsen> Beschleunigung ohne Erdanziehungskraft bekomme....> Eventuell könnte mir das ja kurz jemand erklären..
Mathematisch ist das ziemlich komplex, fuer einen Laien ist das nicht
machbar. Mit kurz erklaeren ist da nichts. Ein Stichwort ist
Kalman-Filter, der wird zur Sensordatenfusion (ebenfalls ein Sichwort)
verwendet. Vereinfacht gesagt wird die Position und Lage durch eine
Simulation der Bewegung unter Beruecksichtigung der Sensorwerte
durchgefuehrt.
Deine einzige Chance wird wohl sein, eine fertige Bibliothek zu finden,
zum Beispiel aus dem Quatrokopterbereich, der du die Sensordaten
lieferst und dir kinetische Beschleunigungen zurueckgibt, oder
Geschwindigkeiten, die du dann wieder ableiten kannst um auf die
Beschleunigung zu kommen.
Patrick G. schrieb:> Hallo,> danke für eure vielen Antworten.> Allerdings ist für mich erstmal relativ unwichtig wie die Physik> dahinter funktioniert.> Ich muss einfach nur wissen wie ich aus einem MPU6050 die Z Achsen> Beschleunigung ohne Erdanziehungskraft bekomme....> Eventuell könnte mir das ja kurz jemand erklären..> Trotzdem vielen dank das ihr euch alle soviele Gedanken darüber macht :)
Was für einen uC verwendest du eigentlich? Bist du bereit Arduino libs
zu verwenden?
Dann schau einfach in die Videobeschreibung hier (das selbe was ich
vorhin schon gepostet habe): https://www.youtube.com/watch?v=M9lZ5Qy5S2s
Da ist der Code verlinkt.
Patrick G. schrieb:> Hallo,> danke für eure vielen Antworten.> Allerdings ist für mich erstmal relativ unwichtig wie die Physik> dahinter funktioniert.> Ich muss einfach nur wissen wie ich aus einem MPU6050 die Z Achsen> Beschleunigung ohne Erdanziehungskraft bekomme....
Wenn die Theorie für dich wichtiger wäre, dann hättest du daran ableiten
können dass es nicht mal schnell in der Praxis geht so wie du dir das
vorstellst.
Du kannst aber programmtechnisch versuchen das Bremslicht nur zu
aktivieren wenn in einem relativ kurzen Zeitraum eine Verzögerung auf
der erwarteten Achse mit einem bestimmten Winimalwert auftritt.
Sozusagen einen Peak detektieren.
Der Ruhewert muss aber langsam nachgführt werden. Es dürfen nur relative
Peaks und keine Absolutwerte berücksichtigt werden.
Marek N. schrieb:> Und wenn du bergab fährst, dann leuchtet die Bremslampe dauernd.> Und wenn du bergauf bremst, dann nie.
Solange er nicht grade im 90 Grad Winkel hoch oder runter fährt, wird
die Geschwindigkeitsänderung entlang der Vorwärtsbewegung trotzdem
detektiert.
@Cyblord
Oder er nimmt einen Sensor mit library der das schon ausrechnet. Das
scheint dank smartphones und Drohnen so trivial zu sein dass man es
nicht mehr selbst machen muss.
Alex G. schrieb:> Solange er nicht grade im 90 Grad Winkel hoch oder runter fährt, wird> die Geschwindigkeitsänderung entlang der Vorwärtsbewegung trotzdem> detektiert.
Es gibt keinen qualitativen Unterschied zwischen 90° oder 80° oder 1°.
In allen Fällen wird eine Geschwindigkeitsänderung nicht erkannt,
sondern nur eine Änderung der Geschwindigkeitsänderung.
Bei 90° ist der Effekt allerdings viele stärker, da er additiv zur
Erdbeschleunigung hinzu kommt, im Gegensatz zu Pythagoras bei ebener
Fahrt. Wenn er z.B. mit 0,1g verzögert, ändert sich der g-Vektor nur um
1-Wurzel(1.01) = 0.5% (statt 10% bei 90° bergauf oder bergab)
Alex G. schrieb:> Oder er nimmt einen Sensor mit library der das schon ausrechnet. Das> scheint dank smartphones und Drohnen so trivial zu sein dass man es> nicht mehr selbst machen muss.
Es ist nicht trivial, aber eben schon oft in solchen libs gelöst.
Allein, diese libs muss man erstmal verwenden können. Das ist oft
schwerer als eine recht einfache Lösung selber zu stricken. Und man
lernt auch mehr dabei.
Er braucht ja nun kein komplettes 6DOF Copermodul, sondern er will nur
ein Bremslicht. Mit ein bisschen Gehirnschmalz und ein bisschen
probieren kann man so eine Peak-Erkennung selber machen.
Marek N. schrieb:> Und wenn du bergab fährst, dann leuchtet die Bremslampe dauernd.> Und wenn du bergauf bremst, dann nie.
Eine Idee des Schnapses aus der Schule der Hilfe…
A. S. schrieb:> Alex G. schrieb:>> Solange er nicht grade im 90 Grad Winkel hoch oder runter fährt, wird>> die Geschwindigkeitsänderung entlang der Vorwärtsbewegung trotzdem>> detektiert.>> Es gibt keinen qualitativen Unterschied zwischen 90° oder 80° oder 1°.> In allen Fällen wird eine Geschwindigkeitsänderung nicht erkannt,> sondern nur eine Änderung der Geschwindigkeitsänderung.>> Bei 90° ist der Effekt allerdings viele stärker, da er additiv zur> Erdbeschleunigung hinzu kommt, im Gegensatz zu Pythagoras bei ebener> Fahrt. Wenn er z.B. mit 0,1g verzögert, ändert sich der g-Vektor nur um> 1-Wurzel(1.01) = 0.5% (statt 10% bei 90° bergauf oder bergab)
Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir
verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft
angeben.
Nehmen wir an wenn das Fahrrad horizontal steht ist die X-Achse des
Sensors in Fahrtrichtung (kann man so montieren und das wäre
softwaretechnisch am einfachsten auszuwerten).
Dann ergibt das beim Beschleunigen des Rads eine positive Beschleunigung
entlang der X achse.
Fährt das Fahrrad im unrealistischen 45Grad Winkel aufwärts an, liegt
die Beschleunigung entlang der X Achse halt nurnnoch bei der Hälfte. Sie
ist aber immernoch messbar.
Selbiges beim Bremsen.
In der Tat bräuchte er kein 6DOF Modul, aber dies macht die Auswertung
einfacher und er ist bei nem Bastelprojekt kein Kostenfaktor.
Glaub der TE hat einen auch schon bestellt.
Alex G. schrieb:> Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir> verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft> angeben.
Wie schon geschrieben ist das erst mal so pauschal unmöglich.
> Fährt das Fahrrad im unrealistischen 45Grad Winkel aufwärts an, liegt> die Beschleunigung entlang der X Achse halt nurnnoch bei der Hälfte. Sie> ist aber immernoch messbar.> Selbiges beim Bremsen.
Du kannst entlang der X-Achse noch etwas messen. Aber du kennst den
Anteil von Gravitation gegenüber der Beschleunigung nicht. Du kannst
nicht wissen ob das Rad jetzt im 45 Grad Winkel am Berg steht, oder aber
auf ebener Strecke gleichmäßig Beschleunigt bzw. Verzögert. Der Wert
wäre exakt derselbe.
Du kannst natürlich noch die Z-Achse auswerten. Und über die Zeit
integerieren usw. usw. Es gibt Möglichkeiten. Aber nicht so einfach über
EINE Achse du es darstellst.
Du willst es nicht verstehen.
Diese Sensoren geben die Beschleunigung unabhängig von der Schwerkraft
an. Punkt.
Wir haben schon geklärt dass dies erstmal unmöglich erscheint, aber es
ist der Fall. Jedenfalls in ausreichender Genuigkeit für den TE.
Der TE sollte erstmal auf die Ankunft der Teile warten und den Code aus
dem verlinkten Video testen. Dann sehen wir weiter.
Alex G. schrieb:> Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir> verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft> angeben.
Dann gib den Link bitte nochmal an, ich finde den hier nicht!
Alex G. schrieb:> Du willst es nicht verstehen.> Diese Sensoren geben die Beschleunigung unabhängig von der Schwerkraft> an. Punkt.
Nein das tut ein MPU-5060 eben nicht von allein. Die obige Aussage war
falsch und ist immer noch falsch. Darum korrigiere ich dich ständig.
WENN dann kann ein Board mit Controller und MPU-5060 und entsprechender
Software so was ähnliches ausgeben.
https://www.youtube.com/watch?v=M9lZ5Qy5S2s
Der Code der da in der Videobeschreibung angegeben ist, liest direkt die
Werte durch eine importierte Library aus. Also als Nutzer musst du
nichts mehr rechnen.
(das gibts es übrigens alles schon:)
https://helmheld24.wordpress.com/2016/03/08/lumos-fahrradhelm-mit-blinker-und-bremslicht/Cyblord -. schrieb:> Nein das tut ein MPU-5060 eben nicht von allein.
naja: The sensor has a "Digital Motion Processor" (DMP), also called a
"Digital Motion Processing Unit". This DMP can be programmed with
firmware and is able to do complex calculations with the sensor values.
der Sensor könnte das also sicher alleine (hat er doch CPU und Software
onboard)
Alex G. schrieb:> Youtube-Video "Ep. 57 Arduino Accelerometer & Gyroscope Tutorial> MPU-6050 6DOF Module"> Der Code der da in der Videobeschreibung angegeben ist, liest direkt die> Werte durch eine importierte Library aus. Also als Nutzer musst du> nichts mehr rechnen.
Den Link hast Du doch oben schon gepostet.
Und in dem Video wird eben die Schwerkraft genau NICHT
herausgerechnet, sondern ist (grob) 1g!
Hast Du Dir das Video überhaupt angeschaut?
Oder gibt es da bei Minute 17 oder so ein paar Bilder, wo alle Werte 0
sind?
Oder verwechselst Du die Drehraten (die natürlich meist 0 sind) mit den
Beschleunigungswerten (die 0,0,1 sind)?
Fabian F. schrieb:> Wenn dir ums basteln geht, viel Spaß. Wenn du eigentlich nur das> Rücklicht mit Bremsleuchte willst, so was gitb es schon:> https://www.bumm.de/de/produkte/dynamo-rucklichter/produkt/323-5altv.html?
Deren Lösung ist simpel: einfach die Frequenz der vom Nabendynamo
gelieferten Spannung überwachen. Aber warum einfach, wenn es auch
kompliziert geht, der teutsche Inschinjör braucht Beschäftigung…
Robert L. schrieb:> Uhu U. schrieb:>> der teutsche Inschinjör braucht Beschäftigung…>> ich kenne niemanden der einen (Naben)dynamo hat..
Ich kennen niemanden der überhaupt noch irgendeinen Dynamo hat. Seit die
Dinger uncool geworden sind, werden Fahrräder durch Aufstecklichter mit
leeren Batterien (nicht) beleuchtet. Ganz ehrlich, grade jetzt im Winter
seh ich kaum Räder mit Licht. Scheint nicht mehr Mode zu sein.
Erst mit E-Bikes ist wieder genug Saft an Board. Wobei es genug E-Bikes
gibt die trotzdem noch Aufstecklichter mit extra Batterien haben. Find
ich zwar irre aber jeder so wie er mag.
Alex G. schrieb:> Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir> verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft> angeben.
Ja Super. Das find ich jetzt wirklich nicht schön.
Du behauptest mehrfach irgendwas, erklärst alle für blöd, die Dich
korrigieren, gibst vage Links, die Deine Thesen widerlegen und klinkst
Dich aus, wenn Du konkret werden sollst.
Entweder Du hast Beispiele oder Argumente, dann bringe sie doch auch.
Oder Du hast Dich (mehrfach, massiv) vertan, dann sag das doch auch
kurz.
Wenn jemand hier 2+2=5 schreibt, und von 3 Leuten korrigiert wird, dann
war das ein Fehler und gut ist.
Wenn aber jemand das mehrfach wiederholt und das dann mit Seiten
untermauert, die 2+2=4 zeigen, dann ist das eine andere Nummer.
Alex G. schrieb:> Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir> verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft> angeben.
Solche Beschleunigungs-Sensoren gibt es nicht. Aufgabe eines a-Sensors
ist es, die momentan wirkenden Beschleunigungskräfte zu messen - dazu
gehört selbstverständlich auch der Anteil der Schwerkraft, denn
unterscheiden kann der Sensor die Anteile nicht.
Wie anschließend die vom Sensor gelieferten Daten verrechnet werden, ist
ein ganz anderes Thema - da kann man natürlich irgendwelche Annahmen
machen und die in die Rechnung einfließen lassen. Dass die Annahmen
richtig sind, muss der Anwender selbst sicherstellen, den a-Sensor geht
das aber schlichtweg nichts an.
Uhu U. schrieb:>> Wie jetzt schon drei mal geklärt, gibt es Sensoren (wie den von mir>> verlinkten) welche Beschleunigungskräfte unabhängig von der Schwerkraft>> angeben.> Solche Beschleunigungs-Sensoren gibt es nicht. Aufgabe eines a-Sensors> ist es, die momentan wirkenden Beschleunigungskräfte zu messen - dazu> gehört selbstverständlich auch der Anteil der Schwerkraft, denn> unterscheiden kann der Sensor die Anteile nicht.> Wie anschließend die vom Sensor gelieferten Daten verrechnet werden, ist> ein ganz anderes Thema
Ich vermute mal, da gibt es ein Verständnisproblem bei Alex.
Du (Uhu) sprichst von "nackten" Sensoren, Alex dagegen nennt
ein Gerät, welches mehrere Sensoren plus aufwändige Daten-
verarbeitung enthält, insgesamt "Sensor". Solche Geräte gibt
es anscheinend. Da man aber nicht genau weiss, wie die Daten
intern verarbeitet werden, ist es auch nicht klar, ob dieses
Gerät wirklich für den TE geeignet ist.
Harald W. schrieb:> Alex dagegen nennt> ein Gerät, welches mehrere Sensoren plus aufwändige Daten-> verarbeitung enthält, insgesamt "Sensor". Solche Geräte gibt> es anscheinend.
Eben nicht. Er hat bisher keinen Link oder Typ genannt, der sowas macht.
Im Gegenteil. Sein nochmal geposteter Link misst 1g in einer Achse, 0g
in den anderen.
Harald W. schrieb:> Du (Uhu) sprichst von "nackten" Sensoren
Alles andere ist sinnlos, wenn man von Sensoren spricht - sonst könnte
man z.B. mit dem Begriff "Motor" auch ein ganzes Auto meinen…
Die klare Definition der Begriffe ist die Grundlage jeder Verständigung.
Uhu U. (uhu) schrieb:
>Harald W. schrieb:>> Du (Uhu) sprichst von "nackten" Sensoren>Alles andere ist sinnlos, wenn man von Sensoren spricht - sonst könnte>man z.B. mit dem Begriff "Motor" auch ein ganzes Auto meinen…>Die klare Definition der Begriffe ist die Grundlage jeder Verständigung.
Ja, genau so doof, wie manch einer einfach Trafo sagt, aber ein ganzes
Netzteil meint ...
