Hallo,
ich war jetzt schon 3 Tage am programmieren und bekomme es einfach nicht
hin. Hoffentlich kann mir jemand hier helfen.
Mein Problem ist:
In der Schule baue ich zur Zeit ein Quadrocopter. Damit dieser dann
stabil in der Luft liegt wollte ich jetzt einen Gyrosensor
programmieren. Der Sensor enthält zusätzlich einen Temperatursensor,
diese Werte kann ich problemlos auswerten. Doch wenn ich die Gyrowerte
(x,y und z- Achsen) auslesen will, bekomme ich nur ständig wechselnde
Werte.
Ist das normal? ich dachte der Wert bleibt gleich und ändert sich nur
wenn ich den Sensor drehe!
Der Gyro, der über I²C von einem ATMega32 angesteuert, ist auf einem
Breakout-Board gelötet.
http://www.watterott.com/de/Tri-Axis-Gyro-Breakout-L3G4200D
Hoffe es kann mir jemand helfen.
Gruß Martin
Gyro = Drehrate. Wenn du konstant schnell drehst sollte er konstante
Werte liefern. Das ist richtig. So sollte es sein. Bei solchen
Billigsensoren ist das natürlich nie der Fall. Der Zirkus rauscht und
driftet bis zum geht nicht mehr. Darum braucht man gute Filter.
Stichworte hier wären Komplementärfilter oder besser Kalmanfilter.
Gerade letzterer ist allerdings mathematisch ziemlich anspruchsvoll und
mit Schulmathematik nur schwer zu durchschauen.
http://de.wikipedia.org/wiki/Kalman-Filter
Ob man es schafft ihn zu implementieren ist eine andere Sache.
Bist du dir denn sicher, dass deine Versorgunggspannung steht? Also dass
die Spannung korrekt ist und du keine Schwankungen / Ripple drin hast.
Das kannst allerdings nur mit einem Oszilloskop rausmessen. Wenn du
Versorgungsspannung schwankt, dann tut das vermutlich auch der Output.
Sonst alles richtig Beschalten? Nochmal testen.
@ Michael
Versorgung steht konstant, wird von einem Labornetzteil gebracht.
Oszilloskop besitze ich auch. Von dem her hab ich es getestet.
Gyro = Drehrate => Drehzahl z.B. wenn der Gyro auf einem Propeller von
einem Motor sitzt, dass er dann die Drehzahl anzeigt?
@Gast
Ja aber die Werte, die ich messe (16-Bit Auflösung), schwanken so stark,
dass das die Erddrehung nicht sein kann. => MSB ändert sich auch ständig
Aber danke für den Hinweis :)
für ein schulprojekt ist das aber echt anspruchsvoll, aber hohe Ziele
setzen ist ja nicht unbedingt verkehrt.
Zunächst die ganze Filtergeschichte und dann noch die ganzen
Driftprobleme welche durch die Aufintegration der Gyrodaten
zustandekommen. Und wenn man all das hinbekommen hat, weis der
Quadrocopter am Ende nur welche Lage er bezogen auf den
Einschaltzeitpunkt hat, ob er zum Einschaltzeitpunkt orthogonal zur
Erdoberfläche lag, weis er noch lange nicht.
Gibt es nicht mitlerweile intelligentere Sensoren die einem wenigstens
die Filterung und Integration weitestgehend abnehmen?
ArduIMU+ V3 ist doch für solche Fälle gedacht oder? Also für
Flugprojekte die nicht all zu viel Aufwand und Eigenentwicklung
beinhalten sollen.
Edit: Gyro zur Drehzahlmessung? dann nehm ich alles zurück was ich
gesagt hab.
Martin schrieb:> Gyro = Drehrate => Drehzahl z.B. wenn der Gyro auf einem Propeller von> einem Motor sitzt, dass er dann die Drehzahl anzeigt?
Jein - Drehrate ungleich Drehzahl. Die Drehrate ist eine Angabe in °/s
Martin schrieb:> z.B. wenn der Gyro auf einem Propeller von> einem Motor sitzt, dass er dann die Drehzahl anzeigt?
Völlig falsche Anwendung. Dein Sensor eignet sich für max. 2000°/s =~
334U/Min. Ich nehme mal an das willst du aber nicht.
Ist denn das Signal auch schon so ein Mist, wenn du es mit dem Oszi
anschaust? Könnte was bei der AD-Wandlung schief gehen?
Martin schrieb:> @Gast> Ja aber die Werte, die ich messe (16-Bit Auflösung), schwanken so stark,> dass das die Erddrehung nicht sein kann. => MSB ändert sich auch ständig> Aber danke für den Hinweis :)
Die Erdbeschleunigung ist mit dem Offset sowieso draußen.
Martin schrieb:> @Gast> Ja aber die Werte, die ich messe (16-Bit Auflösung), schwanken so stark,> dass das die Erddrehung nicht sein kann. => MSB ändert sich auch ständig> Aber danke für den Hinweis :)
Alignment passt? Stichwort Little/Big Endian oder zappeln alle Bits,
von vorne bis hinten?
@Chris
ich hab mir das davor auch nicht so aufwendig vorgestellt :P
Little / Big Endian kann man in einem Register setzen, hab ich aber
nicht gemacht => MSB ist auch MSB
Was bedeutet Alignment?
@Michael
Das Signal kann ich ja nur digital abgreifen über I²C.
Jetzt versteh ich so langsam auch den Unterschied zwischen Gyro und
Beschleunigungssensor. In Wiki wird nähmlich angegeben, dass der Gyro
ein Beschleunigungssensor ist. Das stimmt ja dann nicht. Er ist ein
Drehratensensor.
Das bedeutet: Gyro = Drehrate (durch Integral: Grad pro Zeit)
Beschleunigungssensor = Beschleunigung der Drehung
Wäre so ein Kompassmodul für mich dann besser?
http://www.pollin.de.......Kompassmodul HDMM01
Martin schrieb:> Der Gyro, der über I²C von einem ATMega32 angesteuert, ist auf einem> Breakout-Board gelötet.>> http://www.watterott.com/de/Tri-Axis-Gyro-Breakout-L3G4200D
Stolzer preis. Ich habe mir ein "Breakout" für den L3GD40 (Nachfolger
von 4200d), MMA8451Q, MAG3110 und MPL3115A entwickelt. Die Komponenten
kosten etwa 10-15€, die Platine nur 1€.
Martin schrieb:> Mein Problem ist:>> In der Schule baue ich zur Zeit ein Quadrocopter. Damit dieser dann> stabil in der Luft liegt wollte ich jetzt einen Gyrosensor> programmieren. Der Sensor enthält zusätzlich einen Temperatursensor,> diese Werte kann ich problemlos auswerten. Doch wenn ich die Gyrowerte> (x,y und z- Achsen) auslesen will, bekomme ich nur ständig wechselnde> Werte.
Jeder Sensor rauscht. Dein Problem ist einfach nur dass du vorerst nur
die "Rohwerte" betrachtest, also vermutlich als Integer. Bei 250dps ist
es völlig normal, dass er so um die 90 digits rumzappelt.
Dieses Rauschen tanzt jedoch um einen "Nullpunkt", aber mit einem
Gewissen Offset. Dieser Offset ist nicht bei "0" sondern ist im Mittel
etwas positiver oder negativer. Dies resultiert beim Aufintegrieren (was
man ja macht um die absolute Lage zu erhalten) in einem Drift.
Was man also macht, ist erstmal in Ruhelage zu schauen wie der Offset
ist. Dies macht man im einfachsten Fall also z.B. so:
1
offset_x=0;
2
offset_y=0;
3
offset_z=0;
4
for(i=0;i<255;i++){
5
offset_x+=getGyroRAW_x();
6
offset_y+=getGyroRAW_y();
7
offset_z+=getGyroRAW_y();
8
}
9
offset_x/=255;
10
offset_y/=255;
11
offset_z/=255;
Im späteren Programmablauf liest du dann immer die RAW werte aus und
ziehst den Offset ab. Damit hast du schonmal den "schlimmsten" Drift
rausgerechnet.
Um die absolute Lage zu erhalten liest du einfach z.B. alle 20ms den
Gyro aus und addierst einfach alles immer wieder auf:
1
while(1){//deine "Main-Loop"
2
if(zwanzig_ms_vergangen){
3
zwanzig_ms_vergangen=0;
4
gyro_readComp(&x,&y,&z);
5
angle_x+=(double)x*0.0175*0.02;
6
angle_y+=(double)y*0.0175*0.02;
7
angle_z+=(double)z*0.0175*0.02;
8
}
9
printf("Absoluter Winkel_x: %f",angle_x);
10
//usw.
11
}
in diesem Fall liest "gyro_readComp(&x,&y,&z);" die bereits
kompensierten Gyrowerte aus (also RAW-Offset).
0.0175 ist die Auflösung des Gyros beim 500dps Bereich (siehe
Datenbaltt). 0.02 ist Abtastzeit des Gyros (z.B. gesetzt durch einen
Timer => zwanzig_ms_vergangen = 1).
Du wirst sehen, dass das Zappeln quasi in den unteren Kommastellen
verschwindet (da ein digit ja nur 17.5 mdps sind, bzw. je nach
Messbereich halt entsprechend anders)
Zwischendurch musst du dann aber immer wieder den Gyro abgleichen mit
einem Beschleunigungssensor oder Magnetometer um den Drift wieder
rauszubekommen.
Bedenke auch dass der Drift sehr stark temperaturabhängig ist, deswegen
ist auch ein Temperatursensor in den Gyros eingebaut damit du den
Kompensieren kannst. Es gibt auch einige AppNotes für den Sensor, wo
eben auch drin steht wie man damit umgeht, z.B. TA0343)
Martin schrieb:> Das bedeutet: Gyro = Drehrate (durch Integral: Grad pro Zeit)> Beschleunigungssensor = Beschleunigung der Drehung
wie wo WAS? nein nein nein.
Gyroskope, auch Drehratensensoren genannt messen, wie der name schon
sagt, die Drehgeschwindigkeit, also wie schnell sich eine Objekt um eine
seiner Achsen dreht. Durch Integration dieser Drehgeschwindigkeiten,
bekommt man die Lage des Objekt bezogen auf den Ausgangspunkt bei dem
man die Integration gestartet hat. Damit kannst du angeben in welche
Richtung sich dein Quadrocopter gerade neigt oder um die eigene Achse
(Z- oder Yaw-Achse) gedreht ist. Sie werden gern mit
Bescheunigungssensoren verwechselt weil ihr innenaufbau der einem
Beschleunigungssensors ähnelt, bzw, sogar mal gleich war glaub ich.
Bescheunigungssensoren hingegen geben die die aktuelle Bescheunigung in
X-,Y- und Z-Richtung an, auch diese kann man aufintegrieren. Durch eine
erste Integration bekommt man die aktuelle Geschwindigkeit und durch
eine weitere Integration die aktuelle Position, wieder bezogen auf den
Ausgangspunkt.
In der Theorie ganz simpel, und für eine Lagestabilisierung eines
Quadrocopters auch ausreichend (theoretisch). Praktisch hast du das
Problem das die Sensoren Rauschen und driften. Konstante Drifts kann man
mit etwas Aufwand wieder rausrechnen. Problematisch sind die Drifts die
nicht konstant sind sondern bei jedem Einschalten des Sensors anders,
wie man die los wird hab ich keinen Dunst, daher sollte man diese
Sensoren nur als Unterstützung nehmen, meiner Meinung nach.
Wenn du näher darauf eingehst was du mit dem Quadrocopter vor hast kann
man dir vielleicht gezielter helfen.
Grüße
Chris
ps: Alignment nennt man die Reihenfolge der Bytes im Speicher, also
Little oder Big Endian.
Martin schrieb:> => MSB ändert sich auch ständig
Die Drehrate ist ein Wert der durchaus auch negativ sein kann.
Also ohne jetzt mal das Datenblatt zu lesen würde ich davon ausgehen das
MSB entspricht dem Vorzeichen. ==> also dein Meßwert zappelt um den
Nullpunkt.
Was auch zu erwarten ist wenn der Sensor auf dem Tisch liegt.
Genau, wird direkt als 16-Bit Zweierkomplement ausgeben. Kann man also
direkt in ein int16_t rein shiften & odern, je nach Endianness eben so
oder so herum.
Martin schrieb:> @Michael> Das Signal kann ich ja nur digital abgreifen über I²C.> Jetzt versteh ich so langsam auch den Unterschied zwischen Gyro und> Beschleunigungssensor. In Wiki wird nähmlich angegeben, dass der Gyro> ein Beschleunigungssensor ist. Das stimmt ja dann nicht. Er ist ein> Drehratensensor.> Das bedeutet: Gyro = Drehrate (durch Integral: Grad pro Zeit)> Beschleunigungssensor = Beschleunigung der Drehung>> Wäre so ein Kompassmodul für mich dann besser?
Moment mal Meister,
also erstmal grundsätzlich: Dein oberstes Ziel ist die Erkennung der
Lage zur Eroberfläche.
Gyro = Drehrate = Winkelgeschwindigkeit in °/s, also du nimmst dein
Handy und drehst es innerhalb einer Sekunde einmal um die eigene Achse,
dann hast du eine Winkelgeschwindigkeit von 360° pro Sekunde. Das ist
die Drehrate.
Als Anmerkung: Die Tntegration der Winkelgeschwindigkeit (das was der
Gyro misst) über die Zeit ergibt logischer Weise einen Winkel, nämlich
den Differenzwinkel zwischen den beiden Zeitpunkten zwischen denen
integriert wird. Klingt gut aber in der Praxis rauschen die Sensoren zu
stark und der Wert fährt so binnen Sekunden voll an die Wand.
(exorbitante Werte, völlig unbrauchbar) Das alleine reicht nicht aus um
eine Winkelmessung (-> 3x -> Lage im Raum) festzustellen.
Beschleunigungssensor misst zwar die Beschleunigung aber nicht die
Drehbeschleunigung. Der Beschleunigungssensor hat meist 3 Achsen x,y und
z. Er misst immer nur die Beschleunigung genau in Achsrichtung. Er misst
also getrennt voneinander die Beschleunigung nach: vorne/hinten,
links/rechts und oben/unten. (Wolltest du die Drehbeschleunigung messen,
so könntest du das mittels vektorieller Addition der x und y- Achse
machen. Das willst du aber nicht!). So warum verwendet man
Beschleunigungssensoren: Zum einen messen sie die Erdbeschleunigung mit.
Dadurch dass der Sensor nur immer in Achsrichtung sensitiv ist, so kann
man auch den Winkel in Ruhelage (!) messen. Auf die hoch/runter-Achse
(meist z) wirken im Ruhezustand und genau parallel zur Erdoberfläche
genau 1g (=9,81m/s^2). Kippt man den Sensor, dann z.B. nach links, so
werden die Werte auf der z-Achse weniger, dafür nehmen auf einer anderen
Achse wiederrum zu. Also ist der Beschleunigungssensor dazu geeignet
Abweichungen von der genau parallelen Lage zur Erdoberfläche zu
erkennen. Das funktioniert auch blendend solange man den Sensor nicht
anderweitig beschleunigt (z.B. wenn er auf einem Quadrocopter
ausbalanciert wird, dann wirken noch andere Beschleunigungskräfte als
die der Erdbeschleunigung, da sich der Quadro ja auch bewegt) ist also
auch nicht das perfekte Mittel.
Kompass hast du auch angesprochen. Auch der funktioniert nur bedingt, da
er weder sonderlich genau ist, noch störunanfällig. Jedes Metallteil,
etc bewirkt Störungen. Gleiches gilt für hohe Ströme, wie sie
beispielsweise bei den Brushlessmotoren beim Quadrocopter vorkommen. Das
ist alles nicht gut für den Kompass =) muss man sich gut überlegen wo
man ihn montiert. Im Übrigen sollten die Kompasse neigungskomensiert
sein (tilt-compensation), ansonsten zeigen sie ,wenn sie nicht parallel
zur Erdoberfläche liegen, nur Mist an.
Du bemerkst schon, dass diese 3 Möglichkeiten (viel mehr gibt es auch
nicht) alle ziemlich unzuverlässig und ungenau sind. Die Kunst besteht
nun darin mittels spezieller Algorithmen (Kalmanfilter, ...) meist Gyro
und Beschleunigungssensor so zu kombinieren (miteinadner Verrechnen,
etc) und zu filtern, dass da vernünftige Ergebnisse rauskommen. Das
allerdings ist eine hohe Kunst und in keinster Weise für Anfänger
geeignet. Es macht also die Kombination aus den verschiedenen Filtern
und vor allem der dahinter stehende Algorithmus.
> http://www.pollin.de.......Kompassmodul HDMM01
keine Neigungskompensation, keine 3 Achsen. Kompassmodule
neigungskompensiert und 3-achsig sind ziemlich teuer und bringen eher
weniger. Das kann man später noch einarbeiten, wenn Gyro + Beschl.
arbeiten.
Zu deinem Problem:
1. Du bist dir sicher, dass du den Sensor richtig ausliest? Bei 16 Bit
musst du ja 2 x 8 Bit einlesen. Mit dem Alignment ist gemeint, ob du
diese beiden Bytes auch richtig aneinanderreihst. Bits gehen ja von 0-15
(=16 Bit).
Bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 (richtig)
Bit 15 14 13 12 11 10 9 8 0 1 2 3 4 5 6 7 (falsch)
Fehler dieser Art sind ziemlich beliebt. Das könnte sowas erklären
2. Du schaust jetzt ja hoffentlich nicht nur das MSB an und sagst - ja
wenn sich das ändert dann zappelt es ja im ganzen Zahlenbereich. Das MSB
kann ja auch bei einer änderung von +/-1 rumzappeln. Schau mal die
Dezimalwerte an.
3. Eine andere Möglichkeit ist, dass es sich bei dem vermeintlichen MSB
um ein Vorzeichenbit handelt. Das steht aber alles im Datenblatt das du
hoffentlich ausreichend studiert hast.
4. Funktioniert deine I2C-Auswerte Routine überhaupts richtig oder
könnte es sein, dass du völligen (zufälligen) Mist vom Bus liest?
Lehrmann Michael schrieb:> Moment mal Meister,>> also erstmal grundsätzlich: Dein oberstes Ziel ist die Erkennung der> Lage zur Eroberfläche.>> Gyro = Drehrate = Winkelgeschwindigkeit in °/s, also du nimmst dein> Handy und drehst es innerhalb einer Sekunde einmal um die eigene Achse,
...
und das um 1uhr morgens, respekt, da sei dir auch verziehen das du
geschrieben hast das Rauschen den Sensor an die Wand fahren lässt ;-)
Lehrmann Michael schrieb:> also erstmal grundsätzlich: Dein oberstes Ziel ist die Erkennung der> Lage zur Eroberfläche.
Nein, das oberste Ziel bei einem Quadcopter ist es, das Abkippen um eine
Achse zu erkennen und über die Motoren zu kompensieren. Deshalb ist in
den
meisten Projekten (z.B. Multiwii) ein Gyroskop (z.B. aus einem
WiiMotion+) erforderlich, ein Linearbeschleunigungsmesser (der "unten"
definiert) aber optional.
Der Gyro misst dabei die Winkelgeschwindigkeit (°/s): kippt der Copter
um eine Achse, ist die Firmware bemüht, diese Änderung auf 0 zu bringen,
damit der Copter seine Position im Raum hält: die kann aber natürlich
auch schräg sein, wodurch der Quadcopter dann halt in eine bestimmte
Richtung fliegt.
> Die Kunst besteht> nun darin mittels spezieller Algorithmen (Kalmanfilter, ...) meist Gyro> und Beschleunigungssensor so zu kombinieren (miteinadner Verrechnen,> etc) und zu filtern, dass da vernünftige Ergebnisse rauskommen. Das> allerdings ist eine hohe Kunst und in keinster Weise für Anfänger> geeignet. Es macht also die Kombination aus den verschiedenen Filtern> und vor allem der dahinter stehende Algorithmus.
Für den Anfang reicht ein PID-Regler völlig aus. Ich habe selber so ein
Teil gebaut und es ist erstaunlich mit wie wenig Aufwand (im Prinzip^^)
ein sehr stabiler Flug erreicht werden kann. Allerdings ist das
Einstellen der Regelparameter eine doch recht aufwändige Angelegenheit.
Hierzu empfielt sich ein Testgestell (ohne fast unmöglich).
Zum Gyro:
Der Gyro ermittelt den Winkel durch Aufintegration. Der digitale Gyro
(ich habe den L3G4200D benutzt) hat interne, digital einstellbare Filter
schon intern (Hochpass + Tiefpass). Ich habe eine Regelfrequenz von
500Hz verwendet und den Gyro auf eine Output Data Rate von 800Hz
eingestellt.
Noch einen Tip: Um Zeit zu sparen empfielt sich statt I2C lieber SPI zu
nehmen. Der Chip unterstützt das und kann dann mit 10MHz ausgelesen
werden. Dadurch hat man mehr Zeit für die ganzen anderen Dinge.
Der Winkel driftet langsam weg (pro Minute kommen so sicher mal > 30
Grad zusammen). Mit einem ACC habe ich ermittelt, ob der Gyrowert mit
dem ACC-Winkel übereinstimmt. Wenn nicht, habe ich den Wert ganz langsam
nachgezogen. Also eine simple If-Abfrage ob der ACC-Winkel kleiner oder
größer als der Gyrowinkel ist und dementsprechend einen Korrekturwert in
die Integrationsroutine gepackt.
Aber ich sag es gleich: Trotz des einfachen Prinzips steckt der Teufel
im Detail und man braucht schon einige Testläufe bis alles funktioniert.
Für einen Anfänger oder Schüler stufe ich das Ganze als etwas arg schwer
ein.
Um den Gyro-Drift raus zu bekommen kann man auch einfach einen
Komplementärfilter implementieren. Der ist erheblich schneller und
einfacher als der Kalman, und für solche Zwecke eigentlich ausreichend.
roll_angle - absoluter Winkel in Grad
gyro_roll_axis - aktuelle Winkelgeschwindigkeit in °/s
angle_accerlerometer - Roll-Winkel in Grad aus
Beschleunigungssensordaten
Ich glaub ich hab den Fehler gefunden. Hab die Werte mal mit dem 2er
Kompliment versucht. Die Werte sehen jetzt schon mal besser aus. Jedoch
stand davon nix im Datenblatt.
@TIMMO
Hab den Offset, wie du es vorgeschlagen hast, ausgemessen. Dabei habe
ich mal 26 Werte angeschaut.
Min: 87
Max: 124
Hab also immer noch ein Rauschen von 37 Bits. Hattest du das auch?
Martin schrieb:> Ich glaub ich hab den Fehler gefunden. Hab die Werte mal mit dem 2er> Kompliment versucht. Die Werte sehen jetzt schon mal besser aus. Jedoch> stand davon nix im Datenblatt.
Klar steht das da. Schau mal auf Seite 35 oben (jeweils bei den
Registern). Der Rest steht eben in den AppNotes.
> @TIMMO> Hab den Offset, wie du es vorgeschlagen hast, ausgemessen. Dabei habe> ich mal 26 Werte angeschaut.> Min: 87> Max: 124>> Hab also immer noch ein Rauschen von 37 Bits. Hattest du das auch?
37 Bits? Wohl eher 37 digits. Schau mal ins Datenblatt, da steht doch
das Zero-Rate level z.B. bei 500dps bis zu +-15dps sind.
Wenn du in die TA0343 auf S.21 schaust siehst du ein paar gemessene
Werte. Bedenke, ein digit entspricht bei 500dps-Messbereich 17.5mdps/s
Der Mittelwert aus deinen gemessenen Werten entspricht dem Offset, den
musst du immer abziehen (gilt aber nur bei der Temperatur bei der du den
Mittelwert gebildet hast, siehe TA0343)
Das Rauschen rauscht quasi um diesem Mittelwert.
Wenn du das wie ich beschrieben habe auf integrierst, also
1
angle_x+=(double)x*0.0175*0.02;
dann steht in "angle_x" der absolute Winkel. Und wenn du die den ständig
ausgeben lässt, wirst du sehen, dass er relativ konstant bleibt (in der
Ruhelage) und um ein paar 0.x Grad alle paar Sekunden wandert. Das ist
der Drift der der Mittelwert/Offset (quasi der virtuelle Nullpunkt)
nicht konstant ist. Wenn du dann mal den Sensor etwas erwärmst oder
kühlst wirst du sehen dass der Winkel sehr viel schneller in die eine
oder andere Richtung wandert.
Und diesen "Rest-Drift" kann man eben z.B. mit einem Kalman oder
Komplementärfilter und einem Beschleunigungssensor und oder Magnetometer
ausgleichen.
Habe gerade nochmal gemessen... Bei 255 Werten schwankt bei mit der
Rohwert (bei 500dps und ~21°C) zwischen -20 und +100. Der Mittelwert
liegt bei 44. Also habe ich ein Rauschen von etwa +-60*17.5 mdps = +-1
dps um einen Offset von 44. Je mehr Werte man vorher mittelt umso
genauer wird es.
@ Martin,
Winkel = Integralwert mal Sensitivity mal (1/Abtastfrequenz)
dabei sind:
Winkel = Winkel in Grad
Integralwert = Der Wert den du aus den Rohdaten durch Integration
gebildet hast (vorher aber Offset rausrechnen)
Sensitivity = Empfindlichkeit (8.75mdps/digit bei Messbereich 250dps)
Abtastfrequenz = Frequenz mit der du aufintegrierst (guter Wert ist
500Hz)
Gruß
Jonny
Martin schrieb:> Die Werte, die ich gemessen habe, sind schon Mittelwerte von 255> Messungen.
Äm, nö?
Martin schrieb:> Hab den Offset, wie du es vorgeschlagen hast, ausgemessen. Dabei habe> ich mal 26 Werte angeschaut.> Min: 87> Max: 124
Das sind min und max, der Mittelwert ist die Summe aller
Messungen/Anzahl_der_Messungen
> Finde kein Datenblatt für den TA0343.
TA0343 ist ein "TECHNICAL ARTICLE" zum Gyro (insb. L3G4200D). Einfach
mal googlen (zweiter Link) oder auf der Produktseite unter "Design
Support"
> Wie kommst du auf die 0.0175?
Bei 500dps entspricht ein digit 17.5 mdps. Habe ich doch schon gesagt:
Timmo H. schrieb:> 0.0175 ist die Auflösung des Gyros beim 500dps Bereich (siehe> Datenblatt).
Siehe Datenblatt S. 10. Bisher hast du ja nie gesagt welche
Empfindlichkeit du eingestellt hast. Je nach Empfindlichkeit ändert sich
natürlich auch das Rausch- und Drift-Verhalten (siehe TA0343:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/TECHNICAL_ARTICLE/DM00034730.pdf)
Und im Datenblatt stehts ja auch, DVoff, OffDr etc.
Hab noch ein Fehler in meinem Programm gefunden. Jetzt sehen die Werte
schon viel besser aus. Bei der Einstellung 250dps und ODR = 800Hz hab
ich nur noch ein Rauschen von ca. 15 Digits.
@Timmo
Wenn die Sensitivity 0.0175 mdps/digit bei 500dps ist. Müsste dann nicht
(2^16 = 65 536) 0.0175 x 65 536 = 500 sein? Ist es ja nicht!
Martin schrieb:> @Timmo>> Wenn die Sensitivity 0.0175 mdps/digit bei 500dps ist. Müsste dann nicht> (2^16 = 65 536) 0.0175 x 65 536 = 500 sein? Ist es ja nicht!
Wenn dann müssten es 1000 dps sein, weil du ja +-500dps hast. Aber das
ist nunmal nicht so, darum stehts ja im Datenblatt.
Thread beobachten
Seitenaufteilung abschalten