Habe Probleme mit Drift bei Gyro ADIS16250

[reflection]

Hallo zusammen

Habe mich schon einige Male auf Eurer tollen Homepage rumgetrieben. Ich selber baue keine Roboter, aber vielleicht helft ihr mir ja trotzdem bei einem Problem welches Euch vielleicht auch schon einmal beschäftigt hat. Ich fahre Autorennen und baue mir gerade ein Gerät welches mir die rein dynamische Beschleunigung ausgeben soll (also ohne Erdbeschleunigung) Da das Auto ja nicht immer gerade steht, muss ich also die Neigung erfassen können. Hierzu verwende ich die Gyros ADIS16250 von Analog Device. Als Beschleunigungssensor dient ein SCA3000 von VTI.

Und hier nun zu meinem Problem. Den Code sowie das Datenblatt könnte ich posten falls es etwas bringen sollte.

Habe schon diverse Artikel gelesen über die Drift bei Gyros. Mein Problem ist es nun, das ich genau das habe, aber in einem Mass in dem ich es mir nicht erklären kann. Wenn ich mein Gerät einfach auf dem Tisch liegen lasse, also eigentlich nur die Erddrehung einen Einfluss hat, läuft mir das Teil einfach hoch. Das heisst, die Anzeige zeigt ca. 1°/s an dann 2,3,4.....20°/s und fängt dann wieder bei 1 an (wie ein interner Reset). Dieser Durchlauf dauert ca. 2s. Der Winkel den der Sensor dann natürlich intern daraus integriert, läuft in gleichem Masse davon. Muss sagen, dass alle drei immer gegen (-) laufen. Auch wenn ich sie ein paar Stunden eingeschaltet habe, ist die Drift nicht besser. Spannung ist Stabil. Temperatur auch.
Der Sensor kostet einzeln ein ganz schönes Geld und ich kann mir einfach nicht vorstellen, dass dies so extrem sein soll. Kann vielleicht mal jemand ins Datenblatt schauen. Habe es schon mehrmals durchgelesen, aber verstehe einige Sachen noch nicht genau.
Um es ein bisschen weniger Empfindlich zu machen habe ich die Filter Taps auf 128 gestellt, aber an der Anzeige sehe ich absolut keinen Unterschied. Einen externen Kondensator habe ich noch nicht verbaut. Mich wundert einfach wieso die Drift in °/s immer mehr zunimmt und nicht konstant bleibt. Wenn er sagen wir mit Konstant 3°/s driftet kann ich das ja rel. einfach filtern, aber wenn der macht was er will, wie soll man da dran gehen. Ach ja, wenn ich das Teil ein bisschen drehe, sehe ich wie er mir pos. und neg. Werte je nach Richtung anzeigt. Ob sie von der grosse her stimmen kann ich halt im Moment nicht sagen, da ich es eben nur von Hand ein bisschen drehen kann. Was mir auch noch aufgefallen ist, ist, dass sich der Winkel den das Teil intern integriert von -320 - +320° geht !? Also ein Kreis hat für mich immer noch 360° *g* Da bin ich auch noch nicht gestiegen. Ist das erste mal das ich solche Bauteile einsetze und wäre froh wenn mir jemand helfen könnte. Vielleicht mache ich ja auch einfach sonst was falsch mit der Ansteuerung.

Danke schonmal im Voraus für die Hilfe

Gruss reflection

[reflection]

Salu zusammen

Wollte nur noch einmal nachfragen ob das Problem niemand kennt, oder halt eben nicht kennt. Wäre über Infos echt froh. Bleibt bei Euch die Drift stabil, also z.B. 3°/s oder so, oder läuft es auch so aus dem Ruder wie bei mir. Vielleicht ist das ja normal, wie gesagt, habe noch nie solche Bauteile verbaut und wäre über Erfahrungen, auch mit anderen Typen sehr froh.

Gruss reflection

[MeckPommER]

Ich kann dir da nur die Kollegen vom UFO-Forum empfehlen. Piezo-Gyros werden meistens eher im Flugbereich eingesetzt und dort ist reichlich Erfahrung vorhanden :)

http://forum.xufo.net

Dort solltest du per "Suche" einiges an Informationen finden.

Gruss MeckPommER

[BastelWastel]

Da es keine volle 360grad sind wuerde ich spontan darauf tippen dass du nen Wurm in deiner Software hast?

[tobimc]

Hi.

Das haben diese Gyros einfach an sich, dass die davon driften.
Da kann man (fast) nichts dagegen machen.
Da ich zur Zeit was ähnliches entwickle (naja fast www.tobias-schlegel.de/?id=lena ) habe ich ein ziemlich ähnliches Problem wie du.
In der Professionellenszene werden die Gyros mit allerhand Mathematik behandelt (bestimmte Frequenzen gedämpft oder ausgefiltert, das macht man auch schon hardwareseitig per Tiefpass etc, ganz wichtig ist da auch der Kalman-Filter).
Ohne diese Mathematischen Tricks wirst du dem Drift nie beikommen, da dein Rennauto auch ganz schön vibbrieren dürfte.

Aber wenn ich dein Anliegen richtig verstanden habe, brauchst du garkeinen Gyro.
Du verwendest ja einen 3-Achsigen Beschleunigungsmesser. Und dir ist die Fallbeschleunigung g (= 9,81m/s²) bekannt.
Dein Problem ist, dass sich dein Auto in der Kurve neigt, und du so die Beschleunigung nicht exakt messen kannst.
ABER *Trick*:
Wenn du dich in der Kurve neigst, wird ja die Z-Beschleunigung größer als g. Dazu kommt die Seitenbeschleunigung a(x), die du von der X- und Y-Achse ablesen kannst.
Du kannst also die Gesamtbeschleunigung berechnen aus:
a[ges]² = (a(z)-g)² + (a(x))² (Satz des Pythagoras).

Ich hoffe ich hab richtig verstanden was du messen willst, und keinen schweren Denkfehler gemacht ;)

VLG Tobi

[BastelWastel]

Der Drift is klar..aber ~20° in 2 Sekunden nur durch Rauschen wenn das Ding flach auf dem Tisch liegt? Und hatten die iMEMS mit I²C nicht auch schon integrierte Digitalfilter?..naja..

Ja tobi, die Seitenneigung kann man auch über die änderungen an der Senkrechten Achse messen.

btw. tobi, Kalmanfilter...hast du selbigen schon implementiert? Das kommt demnächst auch auf mich zu nur leider entzieht sich die Thematik vollständig meinem Verständnis ;)
Ein paar Codeschnippsel in Bascom wären super.

[tobimc]

Hi

20° in 2 Sekunden... ouch.
Hast du mal versucht einen Tiefpass zu implementieren? Viele Sensoren haben diesbezüglich schon was vorgesehen... (Externer Kondensator oder so).

Joa, also würd ich den Gyro weglassen, nur etwas, was das Ergebnis verfälschen kann.

Den Kalmanfilter... nein. Davon hab ich leider auch (noch??) keine Ahnung.
Aber ich hab gehört, dass es den Filter komplett implementiert irgendwo im Netz zun downloaden gibt, genauso wie Libs zum Fast-Fourier-Transformieren.
Da müsstest du dann allerdings auf C umsteigen...

VLG Tobi

[BastelWastel]

Das mit C wollt ich eigentlich umgehen..da bin ich eher mager bewandert x.x
Naja, ich werd mal Google bemühen..muß eh erst mal das BGA auf die PCB gepfriemelt bekommen.

[reflection]

Du verwendest ja einen 3-Achsigen Beschleunigungsmesser. Und dir ist die Fallbeschleunigung g (= 9,81m/s²) bekannt.
Dein Problem ist, dass sich dein Auto in der Kurve neigt, und du so die Beschleunigung nicht exakt messen kannst.
ABER *Trick*:
Wenn du dich in der Kurve neigst, wird ja die Z-Beschleunigung größer als g. Dazu kommt die Seitenbeschleunigung a(x), die du von der X- und Y-Achse ablesen kannst.
Du kannst also die Gesamtbeschleunigung berechnen aus:
a[ges]² = (a(z)-g)² + (a(x))² (Satz des Pythagoras).

Vielen Dank für die ausführlichen Tipps. Also ich denke schon das ich Gyros benötige. Wenn ich ja in eine Kurve fahre wird die z- Beschleunigung kleiner (teilt sich auf zwei Vektoren auf) als 1g (das Gerät ist fix im Auto drin) da ich aber nun nicht weiss welcher Teil der Beschleunigung durch die Schräglage kommt und welcher Teil durch die Beschleunigung des Fahrzeugs benötige ich die Gyros, oder bin ich jetzt seit Monaten von falschen Bedinungen ausgegangen? Vielleicht verstehe ich auch einfach Deine Antwort falsch. Würdest Du mir vielleicht nocheinmal erläutern wie Du es machen würdest?

Gruss reflection

[Crazy Harry]

um einen gyro kommst du nicht rum, da hier zentrifugalkräfte auch eine rolle spielen und das ergebnis total verfälschen. die rechnung von tobimc dürfte nur im stand stimmen wenn du den sensor kippst.

ein beschleunigungssensor müßte eigentlich in Y-richtung in fahrt (wenn ich z.b. von einem fahrrad in schräglage ausgehe) 0 anzeigen ..... falls nicht fällt man gerade auf die schn...e :D

[reflection]

Ah, ok, dann habe ich ja doch keinen Denkfehler drin, wäre mir jetzt auch echt peinlich gewesen :-b

Hier mal noch der Code, wegen der +-320° wie ich oben in nem Post mal schrieb. Wäre toll wenn es vielleicht mal jemand durchschauen könnte. Programmiere auf einem MSP430, das Gyro ist wie gesagt, dass ADIS16250 von AD.

Gruss reflection

[tobimc]

Hi

Tatsächlich. Meine Gleichung stimmt. Das Problem ist, nur ab einem Zentrifugal-Wert, der (auf die Achsen des Wagens angewendet) größer oder gleich der Hangabtriebskraft ist.

Da müsste es zwar noch einen Weg geben, aber mit Winkel sollte es doch wesentlich einfacher zu lösen sein.

VLG Tobi

[jeffrey]

hi,
@tobi: nee, das geht nicht ohne gyro, weil sobald du den sensor kippst wirkt die zentrifugalkraft auch in richtung der z-achse. dadurch überlagert sie sich mit der erdbeschleunigung und die sind nicht mehr voneinander zu unterscheiden.
mfg jeffrey

[reflection]

Salu zusammen

Ich möchte nun mal versuchen einen externen Kondensator zu bestücken und vielleicht damit die Drift zu verringern. Der ADIS16250 bietet dies ja an. Die analoge Bandbreite kann somit vermindert werden. Ohne C ist sie ca. 50Hz. Was denkt ihr, auf welchen Wert soll ich sie reduzieren? Habt ihr da irgendwelche Erfahrungswerte?

Gruss reflection

[fumir]

also ich kenn diese beschleunigungssensoren ja nicht, aber die z-beschleunigung sollte bei nem fahrzeug, das nicht gekippt ist und über die straße fährt immer =0 sein, unabhängig vom erdfeld und der bewegung auf der straße. denn das fahrzeug wird ja eben in z-richtung nicht beschleunigt! sonst würde es ja fallen.
wenn das fahrzeug in schräglage geht, zeigt der z-sensor deshalb nur einen anteil der radialen beschleunigung an und kümmert sich nicht um die erdbeschleunigung.
von daher halte ich den gyro auch für sinnlos.
allerdings kann man mit gyro und den beschleunigungswerten auf den kurvenradius zurückrechnen. damit hat man also ne weitere information, die jedoch hier noch nicht angesprochen/gesucht war.

ich vermute mal, das diese sogenannten beschleunigungssensoren gar keine beschleunigung anzeigen, sondern die kraft die auf eine frei schwebende masse wirkt.
d.h. da drin ist ne masse an ner feder aufgehängt und der ausgang ist ein signal proportional zur auslenkung der feder. das ist aber nicht das selbe wie die beschleunigung des sensors! in dem fall zeigt der z-sensor natürlich nicht 0 an sondern die erdanziehungskraft (auf die testmasse im innern des sensors)
das macht aber auch nichts, denn man kann diesen konstanten wert (auto waagrecht) ja einfach abziehen und den sensor damit kalibrieren!
auch in diesem fall benötigt man keinen gyro.


ps. bau doch ein aktives fahrwerk ein, damit das fahrzeug gerade bleibt! damit hats dann auch gleich viel bessere fahreigenschaften, oder nicht? :-)

[reflection]

Hallo

Also es ist ein Beschleunigungssensor der dynamische sowie statische Beschleunigung misst, daher brauche ich schon Gyros. Sonst weiss ich ja nicht welcher Teil statisch und welcher dynamisch ist. Kippe ich mein Auto sagen wir um 45°, dann teilt sich ja das 1ne g Erdbeschleunigung genau zu gleichen Teilen auf zwei Achsen auf. Fahre ich nun in eine Kurve, verändern sich die Werte, ich weiss aber nicht welcher Anteil dynamisch ist und welcher statisch.

Gruss Serge

[fumir]

Hallo

Also es ist ein Beschleunigungssensor der dynamische sowie statische Beschleunigung misst, daher brauche ich schon Gyros. Sonst weiss ich ja nicht welcher Teil statisch und welcher dynamisch ist. Kippe ich mein Auto sagen wir um 45°, dann teilt sich ja das 1ne g Erdbeschleunigung genau zu gleichen Teilen auf zwei Achsen auf. Fahre ich nun in eine Kurve, verändern sich die Werte, ich weiss aber nicht welcher Anteil dynamisch ist und welcher statisch.

Gruss Serge

also ich bin physiker, habe aber so etwas wie statische und dynamische beschleunigung noch nie gehört :-) da liegt womöglich der verdacht nahe, das du keine ahnung hast, worum es überhaupt geht, oder was für nen sensor du eigentlich benutzt bzw. was der eigentlich macht.
eine masse ist entweder beschleunigt oder nicht. was bitte schön stellst du dir unter einer statischen beschleunigung vor? der begriff ist schon ein widerspruch in sich, denn ne beschleunigung hört sich für mich nach ner ziemlich dynamischen sache an, oder nicht?

poste doch mal deine sensoren, am besten mit nem link aufs datenblatt, dann kann ich dir das vielleicht besser erklären :-)

[reflection]

Also, als statische Beschleunigung bezeichne ich hier die Erdbeschleunigung. Als dynamische, die, die durch das Fahren auftreten (Fliehkräfte). Ich möchte aber nur die "dynamische" :cheesy:

Hier der Link zum Datenblatt, es ist der SCA3000 D01

http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/

Ich wollte hier nicht Deine Kompetenz anzweifeln, aber ich habe auch schon mit diversen Leuten diskutiert und bis jetzt sind alle darauf gekommen, dass es neben dem Beschleunigungssensor auch noch Gyros braucht. Ich lasse mich gerne von etwas anderem Überzeugen, aber ich habe es mir zig mal überlegt und skizziert und verstehe nicht wie es nur mit einem Beschleunigungssensor gehen soll. Dann müssten ja auch Modelhelikopter ohne Kreisel auskommen, oder? Ist ja in etwa das selbe Problem?

Gruss reflection

[reflection]

Habe mir nochmals alles durchgelesen. Ich glaube ich weiss wo der Knopf liegt... Ich möchte nicht die Gesamtbeschleunigung über alle Achsen, sondern pro Achse ein Wert. Wenn es nur um die Gesamtbeschleunigung geht (1 Vektor) kann ich mir durchaus vorstellen dass es nur mit einem Beschleunigungssensor geht, aber wenn ich jede Achse einzeln möchte....?

Gruss reflection

[fumir]

dacht ichs mir doch, das du keine ahnung hast *fg*
also spiel ich mal den erklärbär:

diese sensoren werden nicht nur zur beschleunigungsmessung, wie du es vorhast, verwendet, sondern auch um schwingungen (z.b. von gebäuden, maschinen) zu messen.
bei einer schwingung wird der sensor sozusagen ständig hin und her beschleunigt. mit einer bestimmten frequenz (genauer, mit ner überlagerung verschiedener frequenzen)
das ist es, was die hersteller dieser sensoren unter dynamischer beschleunigung verstehen.
mit deiner anwendung hat das rein gar nichts zu tun (es sei denn, du interesierst dich dafür, wie rund dein motor läuft).
statische beschleunigung im sinne dieser hersteller ist dann das was du vorhast: die beschleunigung ändert sich nur verhältnismäßig langsam, z.b. sobald das fahrzeug die richtung ändert (ich nehme mal an, das du mit den modelbauservos nicht mehr als einge wenige lenkausschläge/sek schaffst, während die schwingungen um die es den herstellern geht wesentlich schneller sind)

im prinzip kann man sich nen sensor vorstellen, der nur die schwingungen erfasst, aber ich hab jetzt bei meiner kurzen recherche keinen gesehen, der derart ungeschickt konstruiert ist. die üblichen sensoren gehen alle bis 0Hz (statisch) runter. die hersteller erwähnen das nur öfters nicht, denn wenn man schwingungen messen will, ist das nicht wichtig. sondern dann kommt es drauf an, wie groß die maximale frequenz ist, die erfasst werden kann. und was bei der resonanzfrequens des sensors passiert.

dann zu den hubschraubern:
dein beschleunigungssensor kann nur beschleunigungen entlang einer linearen achse erfassen. wenn du den sensor um seinen exakten mittelpunkt drehst, merkt er nichts davon. der hubschrauber (dessen steuerung) muss aber auch auf drehungen reagieren.
genau das machen die gyros, das sind sozusagen beschleunigungssensoren für die drehungen um die 3 achsen. für deine anwendung ist das überflüssig. beim auto interessiert man sich vor allem für die beschleunigung in fahrtrichtung (schneller/langsamer) und für die beschleunigung quer zur fahrtrichtung (stichwort seitenführungskräfte)
möglicherweise hast du auch deshalb so große drift bei deinen gyros.
die wollen eben gedreht werden, damit sie richtig arbeiten!

[fumir]

jetzt noch mal zum auto:

dein sensor scheint mir generell ungeeignet.
nehmen wir mal an, dein modelauto fährt mit 5m/s (18km/h) durch ne sanfte kurve mit 1m radius. dann hast du schon 4g radialbeschleunigung (a=v^2/r). dein sensor schafft aber nur 2g (oder gehts hier um ein richtiges auto, selbst dann scheint mir 2g zu wenig)

jetzt zu deinem schräglagenproblem.
nehemn wir an, deine achsen seien z.b. : x in fahrtrichtung, y nach rechts, z nach unten.
und dein sensor gibt ne spannung von 1V wenn ne beschleunigung von 1m/s^2 wirkt.

was zeigt dein sensor an, wenn das auto waagrecht steht?
nun - da kommt vermutlich x=y=0V und z=9.81V raus.
welche beschleunigung wirkt auf das auto?
na? genau: x=y=z=0m/s^2, denn das auto bewegt sich nicht!
da kann also was nicht stimmen, oder?

des rätsels lösung: dein sensor zeigt eben nicht die beschleunigung an, sondern etwas prinzipiell anders:
im sensor ist ne masse an ner feder befestigt (prinzipiell)
wird der sensor beschleunigt, drückt die masse auf die feder, die position der masse ändert sich, der sensor zeigt was an. der sensor zeigt also die kraft auf die feder an.
diese hat natürlich was mit der beschleunigung zu tun (F=ma) aber es kommt eben auf das bezugssystem an!

wenn das auto steht (vor uns auf dem boden) dann steht es relativ zu einem rotierenden, beschleunigten bezugssystem (die erdoberfläche), und deshalb zeigt der sensor nicht das an, was wir wollen: die beschleuingung relativ zu unserem rotierenden bezugssystem. sondern er zeigt die beschleunigung relativ zu einem inertialsystem an.

lassen wir das auto doch mal nen fahrstuhlschacht runterfallen.
was zeigt der sensor an?
genau: x=y=z=0V, denn jetzt ist das fahrzeug in relation zu nem inertialsystem in ruhe!

zum glück läßt sich das problem leicht beheben: wir ziehen vom z-wert einfach 9.81V ab. dann haben wir die z-beschleunigung relativ zur erdoberfläche!

[fumir]

jetzt auto teil 2:

wir lassen das auto mit v=5m/s durch ne kurve mit radius r=1m fahren.
nehmen wir mal an, das auto bleibt dabei waagrecht.
was zeigt der sensor an?
nun - er sagt uns x=0, z=9.81V und y=4V (oder y=-4V je nach kurvenrichtung)
wir ziehen 9.81V von z ab und wir erhalten: a_x=a_z=0m/s^2, a_y=4m/s^2

jetzt nehmen wir an, das auto ist am kippen: 30° geneigt
was zeigt der sensor?
das ist jetzt doch nicht so einfach, wie zuerst gedacht.
wir müssen die beiden werte z=9.81V und y=4V jeweils in ein um 30° gedrehtes sytem umrechnen und addieren.
y_n=y*cos30°+z*sin30° = 8.37V
z_n=-y*sin30°+z*cos30°= 6.50V
(zur kontrolle: sqrt(y^2+z^2) muss gleich sqrt(y_n^2+z_n^2) sein)
das sind also die neuen werte die unser gekippter sensor anzeigt.

wie kommen wir jetzt zu unseren 4g zurück, die wir eigentlich erhalten wollen?
wir kennen die gesamtbeschleunigung a=sqrt(y_n^2+z_n^2)
und wir wissen, das sich diese aus dem wert z=9.81 und dem gesuchten y zusammensetzt a=sqrt(y^2+z^2)
also (y_n^2+z_n^2)=(y^2+z^2)
oder:
y=sqrt(y_n^2+z_n^2-z^2) = 4V

und das beste: wir brauchen wirklich keinen gyro !!!

[fumir]

noch ein nachschlag gefällig?

der neigungswinkel des fahrzeugs ergibt sich als w=arctan(z/y)-arctan(z_n/y_n)
(offensichtlich auch ohne gyro)

damit kann man jetzt also sogar erkennen, wie weit das fahrzeug noch vorm umkippen ist.
(maximale neigung ist von fahrzeugbreite und höhe des schwerpunktes abhängig)
das hat jetzt aber auch rein gar nichts mehr mit beschleunigung zu tun :-)

wenn du jetzt immer noch nen gyro einbauen willst, dann denk doch mal über nen propeller aufm dach nach *fg*

ach - und vergiss nicht:
wenn du die beschleunigung in fahrtrichtung (gasgeben/bremsen) messen willst, dann beachte, das sich das fahrzeug wegen der federung in der xz-ebene dreht :-)

[reflection]

Also, ich schnalle es nicht, aber anscheinend bin ich einfach zu blöd. Werde mir das ganze noch einmal durch den Kopf gehen lassen. Ich stehe jetzt einfach zwischen verschiedenen Aussagen. Die einen sagen es geht ohne Gyro, so wie Du, die anderen sagen es braucht zwingend Gyros. Meine Infos habe ich von zwei Leuten (beide Doktor in Physik) und ich kann mir irgendwie nicht vorstellen das beide keine Ahnung haben. Werde es mir aber wie gesagt mit all Deinen Formeln am Wochenende mal durchrechnen. Langsam aber sicher lege ich glaube ich das Projekt auf Eis. So kanns ja nicht weitergehen, dann bin ich in 5 Jahren ja noch nicht fertig.
Übrigens, wieso muss dann in einem guten GPS System ein Gyro rein????? Das würde ja dann laut Deinen Aussagen auch ein Beschleunigungssensor tun (ist sicher günstiger), ist aber in der Praxis immer ein Gyro.

Gruss reflection

PS: Was genau ist bei Dir x und was x_n?

PPS: Es handelt sich übrigens nicht um ein Modellauto, sondern um ein richtiges Fahrzeug. Zu den 2g, die reichen gut aus. Schau sonst mal was ein Porsche o.ä. an Kurvenbeschleunigung hinbekommt O:)

[fumir]

sollen doch die doktoren (damit kann ich leider nicht dienen) meine formeln mal checken, und gegebenfalls korrigieren. kann ja auch sein, das ich der bin, der zu doof ist :-)
ich hatte es übrigens heute morgen auch erst mal falsch hier rein gestellt und mußte alles noch mal neu schreiben. ist also nicht so ganz banal, die sache (kann man aber trotzdem mit maximal gymnasialwissen hinbekommen).


(
ein gps integriert die beschleunigungswerte um damit auf den zurückgelegten weg zu kommen. das ganze funktioniert prima, solange sich das fahrzeug nicht dreht.

dreht es sich aber, dann würde das gps die werte sozusagen zu den falschen richtungen integrieren. (beim drehen wird aus x y). deshalb brauchts nen gyro, damit das gps weiß, in welche richtung es gerade schaut, während es die linearen beschleunigungen integriert.
)
das ist natürlich völliger unsinn (und alles andere was ich in diesem zusammenhang gepostet habe auch):-)
hab das gps mit dem trägheitsnavigationssystem verwechselt.
ein gps braucht (im prinzip) weder beschleunigungssensoren, noch gyros !

irgendwie hat das fast keiner gemerkt, komisch.


x ist der wert des sensors in x-richtung wenn das fahrzeug waagrecht steht.
x_n ist der neue wert, der sich ergibt, wenn das fahrzeug/der sensor gekippt wird.
(entsprechend y und z)
man sollte sich klar machen, das immer die gleiche gesamtbeschleunigung auf das fahrzeug wirkt, unabhängig von der strassenlage. nur wirkt sie eben in bezug auf auto und sensor in ne unterschiedliche richtung wenn das fahrzeug gekippt wird.

mit der (hier willkürlichen) festlegung 1V=>1m/s^2 besteht der unterschied zwischen dem sensorsignal (spannungswert) und der beschleunigung (physikalische größe) nur in der einheit.

auf die schnelle ist meine bezeichnungsweise vielleicht hier und da etwas unsauber oder zu knapp ausgefallen.

freut mich für dich, das du in nem porsche rumfahren kannst :-)
hätte halt doch besser im physikunterricht schlafen sollen und was richtiges lernen.

was schafft so ein porsche denn an kurvenbeschleunigung?
für ein formel-1 auto reichen 2g aber sicher nicht.
auch sollte man berücksichtigen das kurzzeitig auf jeden fall höhere beschleunigungen auftreten (stöße durch farhbahnunebenheiten, etc.)
davon sollte der sensor zumindest nicht kaputt gehen (ist nicht bei allen sensoren selbstverständlich)

[fumir]

noch ne kleinigkeit ist mir eingefallen:

wenn mans genau nimmt bekommt man mit den beschleunigungssensoren natürlich nur die beschleunigungen genau am ort des sensors. das mag aber nicht immer ausreichen.
wenn das fahrzeug z.b. schleudert, bewegt es sich nicht mehr auf ner kreisbahn, sondern dreht sich um die eigene achse. da würde dann natürlich der beschleunigungssensor nicht das liefern, was uns interessiert.
das gilt natürlich für alle bewegungsformen, bei denen das fahrzeug nicht mehr auf einer einfachen idealisierten bahn unterwegs ist (driften, überschlagen, etc., da fällt dir vermutlich mehr ein, als mir)

für solche fälle könnte in der tat ein gyro helfen.
aber ich würde eher in der nähe der beiden achsen (also in der mitte zwischen den rädern, etwa auf höhe der radnabe) jeweils nen dreiachsen-beschleunigungssensor anbringen. das dürfte für die ermittlung der seitenführungskräfte genauer sein (da unmittelbarer), als ein gyro, bei dem man dann ziemlich rumrechnen müsste.
mit drei geeignet angebrachten dreiachsen beschleunigungssensoren sollte man den beschleunigungszustand des fahrzeugs (incl. möglicher drehungen) auch ohne gyros komplett erfassen können. (hat auch den rein praktischen vorteil, das man sich nur mit einer art sensor beschäftigen muss => einfacher zu lernen, zu verdrahten und zu programmieren)

[fumir]

und wer immer noch mehr will, kann ja auch noch zusätzlich an jedes radlager nen eigenen sensor anbringen. dann erfährt man auch noch was über die straßenbeschaffenheit, die aufhängungseigenschaften und anderes :-)

[jeffrey]

Hi,
das Problem ist aber, dass sich das Auto beim fahren und kippen auch rauf und runter bewegt, wodurch eine unbekannte zusätzlich z-Komponente hinzukommt. Deswegen funktioniertz die Rechnung von der letzten Seite nicht.
MfG Jeffrey

[fumir]

da ist was dran, schade auch :-)
dieser aspekt der vertikalen bewegungen wurde aber auch bis jetzt noch nicht angesprochen. das ist wie in nem agathe christi krimi: wenn man glaubt, man wisse was los ist, wird eine neue person eingeführt :-)

diese eher schnellen (im vergleich zur kurvenbewegung) z-bewegungen könnte man aber vielleicht weitgehend rausmitteln.

ansonsten sollte man das aber auch dann mit drei dreiachsen-beschleunigungssensoren erfassen lassen, oder?
bin immer noch der meinung, das es einfacher und genauer wird, wenn man an jede seite des autos (in der nähe der räder) nen dreiachsen-sensor macht.
damit bekommt man die interesante querbeschleunigung an den achsen recht direkt und muss nur ne eher kleine korrektur vornehmen, mit den rotationsdaten, die man nebenbei aus den vier linearen beschleunigungssensoren bekommt.

hätte man ja gleich erwähnen können, das da ein jeep bei nem offroad-rennen vermessen werden soll *gg*

aber gut, soll er eben seinen gyro einbauen, wenns ihm spass macht :-)
das thema ist jedenfalls interesanter als es zunächst aussah.

wo wir nach langem irrweg mal wieder beim thema sind:
könnte die trifft des gyros durch externe el.mag.felder (im "labor") verursacht sein, oder sind diese sensoren gegen so was immun?

[fumir]

so, hab mir jetzt doch mal das datenblatt von gyro und die c-datei angeschaut.

ist schon ein interesantes teil dieser gyro. hab mich bisher noch nicht damit beschäftigt.

also für mich siehts so aus (hab aber nur schnell mal drüber geschaut), als ob bei der initialisierung des gyro die calibrierung vergessen wurde. auf seite 14 des datenblatts wird beschrieben wie das sogennante auto null durchzuführen ist. ich seh das im c-code irgendwi e nirgens!
ohne diese calibrierung des sensors, ist es klar, das da was ziemlich schnell wegtrifftet (womöglich dann mit irgendwelchen internen überläufen)

wenn die calibrierung im c-code doch drinsteht, dann bitte mal etwas erläutern.

wichtig: bei der kalibrierung ist die wartezeit nach einstellen des digitalen filters zu beachten!

[fumir]

wurde denn mal der selftest des chips bemüht?

auch das auslesen des statusregisters könnte nützlich sein.

[fumir]

die behandlung des zweier-komplements beim einlesen scheint mir auch nicht ganz richtig:
es gibt sowohl bei 12 als auch bei 14 bit datenlänge jeweils werte mit und ohne vorzeichen.
im code wird aber immer
12bit -> ohne vorzeichen und 14bit -> mit vorzeichen
angenommen

ist auch sinnlos die oberen zwei bits zu maskieren, wenn man sie dann doch mit << 2 rausschiebt.
ein bischen mehr präzision beim codieren erleichtert die fehlersuche!

[fumir]

dynamik range wird im code auf 80°/s eingestellt, im kommentar steht aber 320°/s
vermutlich wurde der kommentar nach änderung des codes nicht aktualisiert, oder?

nebenbei: diese 320° haben nix mit den 360° eines vollkreises zu tun. im ursprünglichen beitrag schien das nicht so ganz klar zu sein, oder?

[fumir]

wie man dem datenblatt entnehmen kann, ist die drift sehr stark temperaturabhängig.

d.h. wenn man den sensor einsetzt, muss man sicherstellen, das sich nach dem AUTO NULL die temperatur des chips nicht mehr ändert. sonst muss man erneut calibrieren.

am besten sollte man den chip also extern beheizen, um ne konstante umgebungstemperatur zu garantieren.

bei temp>30° (die hat der chip sicher bei ner normalen zimmertemperatur von ca 20°) ist die drift negativ, das passt doch auch zur fehlerbeschreibung, oder?

[fumir]

Langsam aber sicher lege ich glaube ich das Projekt auf Eis. So kanns ja nicht weitergehen, dann bin ich in 5 Jahren ja noch nicht fertig.

ach so pessimistisch würd ich das nicht sehen. wir quatschen hier doch erst ein paar tage drüber. gut ding will weile haben!

übrigens hat mich jemand ( 'GDriver' ) gebeten, ihn beim aufbau eines kfz temperatur/öldruck anzeigemoduls zu unterstützen. da würde doch ne beschleunigungsanzeige auch prima mit ins konzept passen. vielleicht könnte man sich da ja zusammenschliesen. red doch mal mit ihm!

[Volker-01]

Kleine Info an fumir:


ein gps integriert die beschleunigungswerte um damit auf den zurückgelegten weg zu kommen. das ganze funktioniert prima, solange sich das fahrzeug nicht dreht.

Wenn ich das so lese, dann glaub ich du hast dich noch nie mit GPS auseinander gesetzt.


Vom Beitrag: 14.12.2007, 11:23


der neigungswinkel des fahrzeugs ergibt sich als w=arctan(z/y)-arctan(z_n/y_n)
(offensichtlich auch ohne gyro)

Wenn ich das so lese, dann frag ich mich, wo hast du denn den Neigungswinkel (30°) her hast, um die n_x sowie n_y zu berechnen. Die kannst du in einem Inertialen system nicht wissen, wenn du sie nicht misst. Dazu benötigst du meiner Meinung nach den Gyro.


Und wer bei Navigations-Anwendungen oder bei Anwendungen wie dieser noch mit cos(), sin(), tan() und arctan() rumrechnet oder gar mit Drehmatrizen, der tut mir echt leid. Die Mathematischen instabilitäten können einem nämlich ganz schön zu schaffen machen und das ganze Projekt zum scheitern bringen. Spezialisten in diesem Bereich nutzen Quaternionen.


Edit:

Es gibt für alle interessierten ein sehr gute Buch, das die Zusammenhänge der Inertialen Navigation näher erläutert. Es ist meiner Meinung nach nicht unbedingt für jeder Mann geeignet, aber ein Mathematisch guter Gymnasiast sollte sich da eigentlich mit etwas arbeit durchkämpfen können. Der anfang des Buches (die ersten 100...130 Seiten) sind für jeder Mann gut geeignet, um sich einen ausführlichen Überblick über die Inertiale Navigation und deren Probleme zu verschaffen.


Das Buch:

Titel: Integrierte Navigationssysteme - Sensordatenfusion, GPS und Inertiale Navigation
Author: Jan Wendel
Verlag: Oldenburg Wissenschaftsverlag GmbH
ISBN: 978-3-486-58160-7

[fumir]

Kleine Info an fumir:
Wenn ich das so lese, dann glaub ich du hast dich noch nie mit GPS auseinander gesetzt.

stimmt! ich kenn nur das grundlegende prinzip, mit den details bin ich wirklcih nicht vertraut :-)




der neigungswinkel des fahrzeugs ergibt sich als w=arctan(z/y)-arctan(z_n/y_n)
(offensichtlich auch ohne gyro)
Wenn ich das so lese, dann frag ich mich, wo hast du denn den Neigungswinkel (30°) her hast, um die n_x sowie n_y zu berechnen. Die kannst du in einem Inertialen system nicht wissen, wenn du sie nicht misst. Dazu benötigst du meiner Meinung nach den Gyro.

den neigungswinkel hab ich an der stelle an der ich y_n,z_n berechne vorrausgesetzt. es geht da nur darum die exemplarischen werte (für das 30° beispiel) zu ermitteln, um die berechnung von y aus z_n, y_n, und z mit zahlenwerten veranschaulichen zu können. insofern hast du meinen beitrag etwas missverstanden, bzw. hab ich mich nicht klar genug ausgedrückt. ich hab aber später noch nen kommentar dazu gemacht.



Und wer bei Navigations-Anwendungen oder bei Anwendungen wie dieser noch mit cos(), sin(), tan() und arctan() rumrechnet oder gar mit Drehmatrizen, der tut mir echt leid. Die Mathematischen instabilitäten können einem nämlich ganz schön zu schaffen machen und das ganze Projekt zum scheitern bringen. Spezialisten in diesem Bereich nutzen Quaternionen.

zum einen werden die wenigsten hier im forum mit dem begriff quaternionen was anfangen können, und ich versuch mich eben an das vermeintliche (da kann man sich auch mal irren) niveau des lesers anzupassen.
zum anderen hab ich zwar schon davon gehört, bin aber auch ohne bis zum diplom (irgendwie) durchgekommen. kann also nicht (für jedes gebiet) derart wichtig sein :-)
zumindest ist bei mir hängengeblieben, das quaternionen z.b. keinen körper bilden und somit auch kein allheilmittel sind. aber für mich kannst du ja gerne mal vorrechnen, wie man das mit quternionen macht - ich lern immer gern dazu!
aber wenn ich eins gelernt habe, dann das nicht immer nur ein weg/formalismus der perfekte ist und das ne einfache lösung meist sinnvoller ist, als ein übertriebener formalismus.
du wirst wohl zugeben müssen, das für das problem, wie es hier formuliert war, eine beschreibung mit trigonometrischen funktionen durchaus angemessen war. und für eine größere zahl von lesern verständlich als eine beschreibung mit quaternionen.

wie man mit mathematischen instabilitäten bei der praktischen umsetzung klarkommt ist nun wirklich ein ganz anderes thema. aber nur mal so am rande: der avr kennt mit sicherheit keine quaternionen. da wirst du deinen schönen mathematischen formalismus letztlich doch auf ein paar simple reelle operationen zurücktransformieren müssen :-)
mal davon abgesehen, das ich ja nicht so ein ding bauen/verwenden will, sondern auch nur versuche zu helfen.




Es gibt für alle interessierten ein sehr gute Buch, das die Zusammenhänge der Inertialen Navigation näher erläutert. Es ist meiner Meinung nach nicht unbedingt für jeder Mann geeignet, aber ein Mathematisch guter Gymnasiast sollte sich da eigentlich mit etwas arbeit durchkämpfen können. Der anfang des Buches (die ersten 100...130 Seiten) sind für jeder Mann gut geeignet, um sich einen ausführlichen Überblick über die Inertiale Navigation und deren Probleme zu verschaffen.

Das Buch:

Titel: Integrierte Navigationssysteme - Sensordatenfusion, GPS und Inertiale Navigation
Author: Jan Wendel
Verlag: Oldenburg Wissenschaftsverlag GmbH
ISBN: 978-3-486-58160-7
danke, aber so genau will ich es im moment gar nicht wissen :-)
falls irgendwann doch, frag ich dich noch mal. (wobei ich dann hoffe, dass du wirklich was davon verstehst und nicht nur ein paar begriffe aus wikipedia abgeschrieben hast, um mich zu trizzen :-) )

[Volker-01]

Ich hab das thema als Diplomarbeit gehabt (vor ca. 3 Monaten) und bin mich derzeit am einlesen über die Mathematische Seite. Da ich meine Masterarbeit auf diesem Bereich machen werde.

Gruß, Volker


P.S. es geht dem anfragenden ja um eine Praxis-Lösung. Daher fand ich es Angebracht anzumerken, das der Winkel, den du exemplarisch verwendet hast im Allgemeinen durch den Gyro ermittelt werden kann und dieser, meiner Meinung nach, daher doch von nöten ist.

Zum anderen hat ein GPS im übrigen gar keine Beschleunigungssensoren sowie auch keine Gyros. Es gibt zwar den Fall, das zumeist Gyros für Omega_Z neötigt werden, jedoch ist dies soweit ich weis nur in der Anwendung als Fahrzeugnavigationssystem sinnig. Dort kann anhand der Gyro-Informationen die Genauigkeit und Zuverlässigkeit des GPS verbessern. Im Falle eines inertialen Sensorsystems wie dem meiner Diplomarbeit ist es sogar nötig noch mehr informationen zu sammeln, als nur die Drehraten um Z (Omega_Z) sowie die Beschleunigungen in allen 3 Achsen.

[fumir]

Ich hab das thema als Diplomarbeit gehabt (vor ca. 3 Monaten) und bin mich derzeit am einlesen über die Mathematische Seite. Da ich meine Masterarbeit auf diesem Bereich machen werde.

prima, dann erklär das mal kurz mit den quaternionen (insbesondere wie man damit diesen mathematischen instabilitäten aus dem weg gehen kann). ich meinte das durchaus ernst. kannste ja als pn schicken, dürte hier für die öffentlichkeit kaum sinnvoll sein.



P.S. es geht dem anfragenden ja um eine Praxis-Lösung. Daher fand ich es Angebracht anzumerken, das der Winkel, den du exemplarisch verwendet hast im Allgemeinen durch den Gyro ermittelt werden kann und dieser, meiner Meinung nach, daher doch von nöten ist.

nun ja, ich hab eben versucht, aufzuzeigen, das man es ohne gyro ausrechnen kann.
kann man auch, solange sich das fahrzeug nicht auch noch auf und ab bewegt (was es in der praxis natürlich macht)
der sensor gibt einem ja die länge des gesamtbeschleunigungsvektors. den kann man dann in den erdbeschleunigungsvektor und den radialen vektor zerlegen, da man ersten kennt und zweiter senkrecht dazu ist.
aber das geht eben leider nur (wie jeffrey richtig erkannt hat) solange das fahrzeug sich nicht auf und ab bewegt.



Zum anderen hat ein GPS im übrigen gar keine Beschleunigungssensoren sowie auch keine Gyros. Es gibt zwar den Fall, das zumeist Gyros für Omega_Z neötigt werden, jedoch ist dies soweit ich weis nur in der Anwendung als Fahrzeugnavigationssystem sinnig. Dort kann anhand der Gyro-Informationen die Genauigkeit und Zuverlässigkeit des GPS verbessern. Im Falle eines inertialen Sensorsystems wie dem meiner Diplomarbeit ist es sogar nötig noch mehr informationen zu sammeln, als nur die Drehraten um Z (Omega_Z) sowie die Beschleunigungen in allen 3 Achsen.
jetzt wo du's sagst, sehe ich auch, das ich völlig auf der falschen bahn war (was das gps betrifft)
nach der frage von reflection: "Übrigens, wieso muss dann in einem guten GPS System ein Gyro rein?????"
hab ich irgendwie ans trägheitsnavigationssystem gedacht und das mit dem gps verwechselt.
natürlich braucht man beim gps (beim empfänger) weder beschleunigungssensoren, noch gyros. werde meinen kommentar oben entsprechend ändern.

[Manf]

also ich bin physiker, habe aber so etwas wie statische und dynamische beschleunigung noch nie gehört da liegt womöglich der verdacht nahe, das du keine ahnung hast, worum es überhaupt geht
... deshalb brauchts nen gyro, damit das gps weiß, in welche richtung es gerade schaut, während es die linearen beschleunigungen integriert.
das ist natürlich völliger unsinn (und alles andere was ich in diesem zusammenhang gepostet habe auch):-)
hab das gps mit dem trägheitsnavigationssystem verwechselt.
ein gps braucht (im prinzip) weder beschleunigungssensoren, noch gyros !

irgendwie hat das fast keiner gemerkt, komisch.

Gehe bitte davon aus dass es wohl viele der Leser bemerkt haben, das Thema Beschleunigungsmessung wird hier öfters diskutiert, es wird sich nur nicht jeder in dem sehr persönlichen Stil auseinandersetzen wollen.

Es wäre einfacher, wenn Du Dich etwas auf ein Forum einstellen würdest in dem ein hoher Anteil an technisch erfahrenen Leuten anwesend ist. Es ist bestimmt nicht das Ziel, jedem der einmal etwas falsches gesagt hat, dies schnellstens aufzuzeigen. Schließlich gibt es auch auf vielen Gebieten etwas Neues und neue Meinungen sollen respektiert werden.

Das Forum ist ganz bestimmt auch eine gute Gelegenheit für Leute mit ganz unterschiedlicher Erfahrung, sich in der Diskussion zu üben. Dazu ist ganz bestimmt jeder eingeladen.
Manfred

[fumir]

ok ok, da war ich wohl etwas voreilig :-)

hab aber trotzdem das gefühl, das da jemand eigentlich nicht so genau wußte, was mit dynamischer und statischer beschleunigung gemeint ist. ich hab mir jedenfalls die mühe gemacht diesen für mich neuen begriff zu recherchieren.

was das gps angeht: da stand ich echt aufm schlauch. dämliche verwechslung.

wenn ich hier mist schreibe, ists mir am liebsten, man sagt mir das gleich.
wenn ich z.b. das gps mit dem trägheitsnavigationsverfahren verwechsle und diejenigen die's gemerkt haben schweigen, dann werden andere die es noch nicht gemerkt haben unnötig in die irre geführt. also bitte erkannte fehler gleich "anmeckern" !

es wird ja öfters gesagt, man solle erst mal in ruhe drüber nachdenken, bevor man postet.
da ist natürlich was dran, aber es kann eben auch daneben gehen, wenn man zu zögerlich ist. im falle meines fehlers mit dem gps haben vermutlich einige lange versucht, herauszufinden, wie das denn sein kann, was ich da gepostet habe. diese mühe hätte man ihnen ersparen können, indem man schnell reagiert.

ich halte das so: wenn mir was komisch/falsch erscheint, dann mach ich gleich nen kommentar dazu und recherchier nicht erst ein paar tage lang. dann kann man immer noch drüber diskutieren, was nun richtig oder falsch ist. auf jeden fall ist dann schnell klar, das es diskussionsbedarf gibt.

[reflection]

Ouha, das war ja ein ganzes Stück zu lesen :cheesy:

Ich habe mir das Ganze im Vorfeld wirklich ausführlich überlegt, darum bin ich auch nicht gestiegen was Du gemeint hast. Für mich war natürlich klar, dass sich auch in z-Richtung etwas ändert und das nicht zu knapp. Wäre das nicht, hätte ich das ganze Problem nicht.

Mit der Initialisierung der Gyros habe ich mich noch nicht auseinander gesetzt. Das mit den 80°/s habe ich in einem Post geschrieben, war ein Fehler weil ich rumprobiert habe, wurde bereits korrigiert.

Ich werde mich jetzt als nächstes daran machen einmal einen externen Kondensator zu verbauen und das Dingens korrekt zu initialisieren. Vielleicht sieht die Welt dann schon anders aus. Habe über die Feiertage mal Zeit dazu und werde meine Erfahrungen hier sicherlich kund tun.

Nebeinbei, ich fahre keinen Porsche, aber etwas das minimum genau so viel Spass bereitet. Leider habe ich im Moment nicht so viel Zeit weil ich noch nebenbei studiere, aber hier mal die Bilder vom letzten Training auf dem Nürburgring -->

http://www.reflectionracing.ch/reflection/pics/pics.asp?menuID=4&subID=7&index=0&ID=29

Gruss reflection

[fumir]

sieht cool aus.

das fehlen von AUTO NULL bei der initialisierung würde ich als erstes angehen.

[Volker-01]

Kleine Info zum Auto-Null Befehl:

Es gibt bei diesem Baustein einige Befehle, die zur Folge haben, das die Werte für den Offset usw. ins EE-Prom zurückgeschrieben werden. Vergewissere dich, ob dies bei diesem Befehl der Fall ist. Wenn ja, dann ist das Autonullen kein Befehl, welcher bei jedem Start durchgeführt werden sollte. Wenn du es nicht aus dem Datenblatt entnehmen kannst, dann gibt es eine ganz einfache Möglichkeit dies herauszufinden. Lese den Wert "Writeendurance" und dann führe Auto Null aus. Wenn du danach nochmals die "Writeendurance" ausliest, kannst du diese mit dem ersten Wert Vergleichen. Bei unterschied wurde auf das EE-Prom geschrieben.

Kleinen Tipp zu den Kommunikationsroutinen:
Am einfachsten ist es, wenn du dich zuerst einmal darauf beschränkst das Temperaturregister des Sensors auszulesen und diesen Wert in eine Temperatur umzurechnen. Du kannst an diesem Wert sehr leicht abschätzen, ob der Sensor ordnungsgemäß angesprochen wird.

Eine Wichtige sache, die nicht im Datenblatt steht ist, das du dem Sensor nach dem einschalten der Betriebsspannung genug Zeit lässt um sich zu initialisieren. Wenn du ihn zu früh ansprichst, kommst du ihm unter umständen in die quere und er funktioniert dann nicht richtig. Den Fall hatte ich mal ganz am Anfang.

Gruß, Volker


P.S. Ich hab den Sensor schon in meiner Diplomarbeit implementiert, daher kann ich dir anbieten mal über deine Kommunikationsroutinen und die Sensorroutinen drüber zu gucken. Sofern du diese in "C" programmiert hast.

[fumir]

laut datenblatt wird nach auto-null und factory-reset immer ein flash-update gemacht.

wie wärs mit ner email anfrage an den hersteller, wegen der drift ?

[reflection]

@Volker-01

Vielen Dank für die Tipps! Bis Dato habe ich wie gesagt nur die .c Routine welche ich schon gepostet habe. Falls ich aber mal in Deine Initialisierungsroutine schauen dürfte, wäre das natürlich toll.


Eine Wichtige sache, die nicht im Datenblatt steht ist, das du dem Sensor nach dem einschalten der Betriebsspannung genug Zeit lässt um sich zu initialisieren. Wenn du ihn zu früh ansprichst, kommst du ihm unter umständen in die quere und er funktioniert dann nicht richtig. Den Fall hatte ich mal ganz am Anfang.


Wie lange wartest Du denn? Ich schalte das Dingens ein (Betriebsspannung) und mache dann gleich mal einen Hardware Reset. Dann initialisiere ich noch andere Ports ect. und schon geht es los. Mache sonst einfach mal ein Delay rein.
Eine andere Frage da Du den Baustein ja zu kenne scheinst. Wenn bei mir wie gesagt die Winkelgeschwindigkeit raufläuft 1-20°/s, wieso resetet sich das TEil bei 20°/s automatisch? Kann man das irgendwo einstellen? Das wäre natürlich die beste Variante. Wenn man das z.B. auf 1°/s begrenzen könnte und er dann intern wieder auf 0 geht und nicht erst bei 20°/s. Über dieses automatische Null setzen finde ich auch nichts im Datenblatt, oder irre ich da?


Das Auslesen klappt glaube ich nicht schlecht. Ich habe zuerst die Betriebsspannung genommen um zu schauen ob ich den Sensor richtig auslese. Diese zeigte dann irgendwann mal 5.013V oder so an und nahm an dass es nun stimmt. Als nächstes kam die Temp. Diese stellt sich bei ca. 50°C ein da es sich um die Die Temperatur handelt und der Baustein ein bisschen mehr als Handwarm wird. Denke als das sollte auch stimmen.

Das mit dem Auto Null muss ich mir nochmal zu gemüte führen. Ist halt nicht ganz so ein einfacher Sensor, aber irgendwie bekomme ich auch das gebacken! Finde es auf alle Fälle toll, dass ihr mir so viel helft, ist auch nicht selbstverständlich!

Ich werde sicherlich berichten wie es weitergeht und falls ich wie gesagt mal Deine Routine sehen dürfte, wäre das natürlich toll!

Wünsche Euch allen einen guten Start in die neue Woche!

Greets reflection

[Volker-01]

@reflection

Den Effekt, den du beschreibst, habe ich nie in der Art wie du ihn beschreibst gehabt. Einziges Problem, das ich zu Beginn hatte, war, das mein Sensor am Anfang nix wirklich Sinnvolles außer der Spannung un der Temperatur von sich gab, so das ich ihm ein wenig Zeit zum Initialisieren lies. Dann war das Problem Geschichte. Der Sensor sowie das interne ASIC arbeiten mit Frequenzen im oberen kHz-Bereich. Daher kann es eben sehr schnell passieren, das man mit nem Controller viel zu schnell ist und der Sensor beim ersten Ansprechen noch nicht mit der Initialisierung fertig ist (gerade bei 72MHz, wie bei mir, dauert die gesamte Initialisierung des Controllers nur wenige 100 µs). Ich hab ihm einfach mal in etwa ne 1/4 Sekunde eingeräumt, da ich die Geschwindigkeit beim Hochfahren nicht als kritisch ansehe (zumindest für meine Anwendungen).

Gruß, Volker


P.S. Meine Software-Routinen darf ich nicht herausgeben, zumindest jetzt noch nicht. Da hat hier leider jemand was dagegen.

[fumir]

das auto null findest du im datenblatt auf seite 14 unter global commands.

auch beim autonull kommts auf timing an. die schreiben, man soll erst mal den digitalfilter auf maximale länge stellen, und dann warten bis das signal durch den digitalfilter durchgelaufen ist, bevor man auto-null startet. soweit ich das mal überflogen habe, könnte das schon ne weile dauern (bezogen auf die µC taktrate),
aber den filter versteh ich nun wirklich nicht :-)

ob das auto-null hilft ist natürlich nicht sicher. diese starke drift ist doch recht merkwürdig.
aber es könnte ja sein, das der drift-korrekturwert im flash aus irgendwelchen gründen, völlig falsch ist. der mögliche kalibrierungsbereich ist +-37.5°/s. ein falscher wert im flash könnte die starke drift also erklären (jedoch nicht das verändern der driftrate)

@volker-01
kann man die analoge bandbreite von 50Hz so verstehen, das durch den digitalfilter 50 werte/s laufen? oder wie ist das genau?

[reflection]

Ist schon komisch, vor allem das alle drei Gyros genau gleich driften. Wie gesagt, das Hochlaufen der Werte macht mich auch sehr stutzig. Wie stabil sind sie denn bei Dir? Irgendwie glaube ich, die Teile wollen noch was von mir was ich ihnen bis jetzt nicht gebe :) Hast Du eine externen Kondensator verbaut? Wenn ja, kannst Du mir sagen wie gross dieser ist?

Gruss reflection

PS: Das wegen dem Code verstehe ich, ist kein Problem, werde Dir ansonsten vielleicht mal meinen schicken wenn ich denn weiterkommen sollte. Die aktuelle Version habe ich ja eine Seite weiter vorne gepostet

[Volker-01]

Also die Ausmaße der Drift finde ich auch sehr merkwürdig. Gearde da die Sesnoren, welche ja bestimmt in verschiedenen Raumachsen ausgerichtet sind unterschiedlich driften müssten. Ich nutze genauer gesagt den ADIS16255. Der ist zwar etwas besser wie der 16250 aber ich denke auch für einen 16250 ist die Abweichung einfach viel zu groß. Bei mir hab ich nach einem Auto-Null meist Driftwerte im Bereich um die 60..80°/h bekommen.

[reflection]

Aha, dann habe ich ja jetzt mal einen Anhaltspunkt, merci!

Das heisst, Du musst zwingend einen Auto-Null ausführen um anständige Werte zu erhalten? Falls ja muss ich das auch mal machen. Machst Du das einmal nach dem Einschalten des Geräts? Was stellst Du bei Dir alles ein?

Digitalfilter?
Auflösung?
Auto-Zero / Factory Calibration?

Gruss reflection

PS: Werde so rasch als möglich mal ne Init Routine schreiben und diese Posten.

[reflection]

So, habe hier mal über Mittag noch ein bisschen programmiert. Das Gerät habe ich leider gerade nicht zur Hand. Wäre aber toll wenn ihr mal drüberschauen könntet (Volker-01 :) )
Einige Fragen habe ich noch. Da steht was von 8 und 16Bit breiten Registern. Ich kann von meinem uP aus keinen 16Bit Wert übertragen, muss ich in 2x8 aufstückeln. Wie verhält es sich nun mit dem Schreiben von Registern, mache ich das so korrekt? Also mein uP shiftet das MSB zuerst raus. Bin mir halt mit den Adressen und so nicht ganz sicher, aber vielleicht kannst Du (Volker) mich ja beruhigen. Da muss doch was zu machen sein. Wenn ich das richtig verstanden habe muss ich das nur 1x machen, oder? Der Wert sollte ja dann automatisch gespeichert werden, oder muss ich da einen manuellen Flashupdate machen? Ich komme, wie ihr sicherlich merkt irgendwie mit dem Ding einfach nicht klar. Irgendwie ist das für mich ein Buch mit sieben Siegeln :-b

Gruss und Danke im Voraus

reflection

[reflection]

@Volker-01

Konntest Du Dir meinen Code einmal kurz durchschauen? Würde mich interessieren ob Du es auch so gemacht hast mit der Initialisierung, oder ob ich da noch Fehler drin habe.

Gruss reflection

[Volker-01]

Hab leider gerade keine Zeit. Lese es mir heute Abend mal durch und überleg dann mal ein bischen. Jetzt hab ich erst mal noch ne Vorlesung zu hören.

Gruß, Volker

[reflection]

Salu Volker

Danke, mach Dir keinen Stress, muss nicht sofort sein! Bin schon mehr als glücklich, dass mir hier geholfen wird!

Gruss reflection

[Volker-01]

Hallo reflection,

Ich hab da soo ein paar Sachen gefunden, aber ich glaube derzeit net, das damit dein Problem behoben ist. Im Source-Code hab ich dir immer mal wider ein paar Kommentare gemacht und Fehler markiert. Die beginnen alle mit ** . Kannste also mit der Suche finden.

Darf ich mal fragen, wie lange du schon C programmierst ?

Gruß, Volker

[fumir]

laut datenblatt soll man erst den filter auf maximale länge stellen, bevor man auto-null startet.
das wäre dann doch
- aktion B
- aktion C
- warten bis filter voll
- aktion A
- wieder warten bis filter voll (da nach dem autonull andere werte in den filter laufen)
- jetzt kann's losgehen mit der eigentlichen messung
oder?

@volker-01
wie genau etwa kann man denn eine trägheitsnavigation (für nen langsam fahrenden roboter) mit verhältnismässig preiswerten sensoren hinbekommen?

[Volker-01]

@fumir:

Du hast recht, da hab ich mich im Eifer des Gefechts wohl vertan/verschrieben.

Zu deiner Frage:
Es handelt sich bei der Inertialen Navigation leider um ein sehr komplexes Thema. Daher kann ich das leider nicht einfach so mal hier erklären.

Ganz kurz beschrieben:
1.) Sensoren, die im stande sind die geringen Beschleunigungen bzw. Drehraten zu erfassen sind in jedem Fall notwendig.
2.) Um so schlechter die Sensoren, desto besser muss die Signalvorverarbeitung sein. Geht aber auch nur in stark begrenztem Maß.
3.) Alle Sensordaten müssen in geeigneter weise miteinander "Fusioniert" werden (z.B. mittels Kalman-Filtern).
4.) Numerisch stabile Mathematik.

Nur wenn du , wie in deinem Beispliel, fährst, dann müsste es auch über einen Drehratensensor und eine einfache Wegmessung möglich sein, die Genauigkeit relativ gut hin zu bekommen. Aber genau hab ich mir das Beispiel "Inertialsensornavigation eines langsam fahrenden Roboters noch nicht angesehen".

Gruß, Volker

[reflection]

Hallo Volker

Vielen Dank für Deine Hilfe. Ich progge erst seit ein paar Monaten C. Habe das nie gelernt. Musste halt was machen und habe es mir kurzerhand selber beigebracht. Das das nicht das gelbe vom Ei ist, ist mir schon klar, denke aber mit der Zeit werde ich das auch noch besser hinbekommen! Ich werde mir Dein Prog mal anschauen und am Wochenende auf den Controller schmeissen, dann kann ich mich ja wieder melden wie es aussieht.

Greets

PS: Habe mir den Code mal angeschaut

** Nimm mal ne neue Reihenfolge: "B", "A", lange genug warten bis alle Filter-Taps gefüllt, dann "c" und zum Schluss lange genug WARTEN.

Habe mir das nochmal durchgelesen, meinst Du nicht B,C,A? Dann würde ich es verstehen.

[Volker-01]

Du hast recht, hat mich fumir gestern auch schon drauf aufmerksam gemacht. War halt schon Spät und ich hab mich da dann vertan.

Gruß, Volker

[bluespark]

Hallo reclection,



bist du noch an der Weiterentwicklung des Gyro-Codes interessiert?

Ich beschäftige mich momentan mit ihm und er performt ganz ordentlich an einem ARM7 Controller. Genauigkeit von weniger als 1 °/s ist nicht zu erreichen, aber das ist OK.

In deinem Code machst du einige grobe Schnitzer:

-- Du rechnest die Zweikomplementwerte falsch in vorzeichenbehaftete Werte um. Das darf nie durch Abschneiden der Vorzeichenbits geschehen. Zweikomplementwerte und vorzeichenbehaftete Werte werden immer durch die Operationen "Komplement bilden"--"Eins addieren" in das jeweils andere Format umgewandelt.

-- Deswegen dürfen nicht alle 12bit Werte sowie auch nicht alle 14bit-Werte gleich maskiert werden. Ich würde das switchen also eher auf die "address" anwenden und darin dann für jede Adresse separat die Umwandlung der beiden Bytes dummy/result_int in ein float vornehmen.

-- Du vertauschst in der Read-Funktion beim Einlesen der Werte im zweiten 16bit-Transfer LSB und MSB. Zuerst wird das MSB übertragen!

-- Die Abfolge sollte deshalb sein: 1) Beide 8bit Werte richtig aneinander hängen 2) ggf Zweikomplementwandlung 3) scale factor anwenden, ohne ihn mit 4 zu multiplizieren.

-- Deine Init-Routine schafft es nicht, einen bekannten Anfangszustand herzustellen. Die Register SMPL_PRD und GYRO_SCALE müssen abgeprüft und ggf verändert werden.

-- Das Belegen der Register "dummy" und "rsult_int" durch VerODERn ist fehleranfällig. Wieso weist du im ersten Schritt nicht direkt zu?

-- in der Funktion Read sendest du im zweiten Transfer die adress erneut. Da ist unnötig, aber nicht falsch. Du wertest ja die ersten beiden Bytes die zurückkommen nicht aus.

-- Wenn du möchtest dass nach einem kurzen Spannungsausfall am Sensor die richtigen Werte wieder aus dem flash geladen werden, solltest du Auto-Null NACH den Änderungen am SENS/AVG machen, dadurch werden diese Werte (genauso wie GYRO_SCALE auch, falls du einen nicht-default-Wert nehmen willst) nämlich auch mit ins flash geschrieben und nach einem power-up wieder richtg geladen.

-- 40us Wartezeit zwischen den 16bit Transfers ist nicht nötig. Es muss nur die stall time eingehalten werden, 15us. Alle anderen deiner delays, zwischen CS und der clock, sind unnötig.

-- Nach Autonull hingegen in der Init machst du zuwenig Pause: Stelle sicher dass mindestens 50ms (!!!) gewartet wird, denn nach Autonull folgt automatisch ein flash-update und das braucht lange.

Ich wäre dann mal an deinen Erfahrungen interessiert. Bei mir zappeln nach einem Auto-Null bei GYRO_SCALE auf default die Messwerte +/-5LSB, während der Sensor in Ruhe ist. Wie ist es bei dir?

Bleibt mir noch die Bemerkung, dass ich die Aussagen der "Experten" fumir und Volker-01 als schwer irreführend, wenig hilfreich und eher selbstgefällig-selbstdarstellerisch ansehe. Wenn Deutschlands Diplomierte und Physiker solch einen Wissensquerschnitt darstellen, wundert mich nichts mehr.


Viele Grüße,
bluesparkAB

[bluespark]

Hi reflection,


eins habe ich vergessen: in der Init-Funktion sollte die startup-time von 160ms sichergestellt werden!


Viele Grüße,
bluesparkAB

[fumir]

Bleibt mir noch die Bemerkung, dass ich die Aussagen der "Experten" fumir und Volker-01 als schwer irreführend, wenig hilfreich und eher selbstgefällig-selbstdarstellerisch ansehe. Wenn Deutschlands Diplomierte und Physiker solch einen Wissensquerschnitt darstellen, wundert mich nichts mehr.


1. kommt deine hilfe mehr als einen monat später, und ne unzureichende hilfe ist dann unter umständen immer noch besser als gar keine.
2. einige der von dir festgestellten fehler im programm wurden längst behandelt.
3. haben weder volker noch ich behauptet experten auf dem gebiet zu sein.
4. hab ich in der tat noch nie was mit so nem sensor zu tun gehabt.
ich hätte natürlich einfach die klappe halten können.
aber ich finds konstruktiver vorläufige meinungen auszutauschen anstatt nen monat später die mutmaßliche patentlösung zu präsentieren.
5. anstatt den wissensstand der deutschen physiker in frage zu stellen, könnte man auch genauso gut mutmaßen, dass du den thread erst mal verfolgt hast, dir dann das nötige equipment gekauft hast, und lange genug rumprobiert hast, um dann den schlaumeier spielen zu können! kannst mir ruhig glauben: mit genügend geld, einem monat zeit und genügend langeweile, wären sowohl volker (vermut ich mal) als auch ich in der lage deine aussagen zu reproduzieren. so what?

[Volker-01]

Hallo bluespark,

mal nicht mit allen immer gleich so schwer ins Gericht gehen! Fällt nämlich häufig auch auf einen selbst zurück. Es kann immer mal passieren, das sich jemand verwerkelt oder etwas übersieht.



- Du vertauschst in der Read-Funktion beim Einlesen der Werte im zweiten 16bit-Transfer LSB und MSB. Zuerst wird das MSB übertragen!

Da muss ich allerding sagen, habe ich auch schon ganz schön geschlafen.



-- Du rechnest die Zweikomplementwerte falsch in vorzeichenbehaftete Werte um. Das darf nie durch Abschneiden der Vorzeichenbits geschehen. Zweikomplementwerte und vorzeichenbehaftete Werte werden immer durch die Operationen "Komplement bilden"--"Eins addieren" in das jeweils andere Format umgewandelt.

Soweit ich sehe, schneidet er doch nirgend wo ein Vorzeichen ab.




-- Deswegen dürfen nicht alle 12bit Werte sowie auch nicht alle 14bit-Werte gleich maskiert werden. Ich würde das switchen also eher auf die "address" anwenden und darin dann für jede Adresse separat die Umwandlung der beiden Bytes dummy/result_int in ein float vornehmen.



signed int result_int;
unsigned int dummy;

result_int = result_int << 8; // Schiebe MSB um 8 nach links
result_int |= dummy; // Füge LSB hinzu



switch(bit_count) // Bit Maskieren
{
case 12: result_int &= 0x0FFF; break; // Maskiere oberste 4 Bit --> 12-Bit Wert ** Fehlerhaft bei Auslesen vom >>Sensor Temperature Data<< -Register (Fällt bei pos. Werten unter Umständen gar nicht auf)
case 14: result_int &= 0x3FFF; // Maskiere oberste 2 Bit --> 14-Bit Wert
result_int = result_int << 2; // Shifte um 2 nach li. wegen Vorzeichen ** Fehlerhaft bei Auslesen vom >>Angel<< -Register
break; // wird mit /4 beim Scalefactor kompensiert
}



result_float = result_int; // Resultat als float abspeichern
result_float = (result_float * scale_factor); // Counts skalieren


Wenn ich mir den Code mal gerade ansehe, muss ich sagen, das dieser auf den ersten Blick schon Funktionieren sollte. (Unter Berücksichtigung der impliziten Typumwandlungen der Kompiler). Zudem hab ich nie gesagt, das der Code besonders gut oder schlecht programmiert wurde.



-- Deine Init-Routine schafft es nicht, einen bekannten Anfangszustand herzustellen. Die Register SMPL_PRD und GYRO_SCALE müssen abgeprüft und ggf verändert werden.

soweit ich das im Datenblatt erkennen kann, hab ich da gelesen, das diese Register >> NONVOLATILE<< sind. Diese Register werden während des Startups selbstständig vom internen ASIC wider restauriert..


-- Das Belegen der Register "dummy" und "rsult_int" durch VerODERn ist fehleranfällig. Wieso weist du im ersten Schritt nicht direkt zu?

Wie schon geschrieben, habe ich nie gesagt, das der Code besonders gut oder schlecht programmiert wurde. Es gibt hier sehr viel Optimierungspotentieal. Zudem nutzt man bei solchen Anwendungen am besten gar keine floats. Die produzieren nämlich aufgrund ihrer Darstellung nur Fehler.



-- in der Funktion Read sendest du im zweiten Transfer die adress erneut. Da ist unnötig, aber nicht falsch. Du wertest ja die ersten beiden Bytes die zurückkommen nicht aus.

Warum soll ichs dann erwähnen ?




eins habe ich vergessen: in der Init-Funktion sollte die startup-time von 160ms sichergestellt werden!

hab ich in meinem Beitrag vom 17.12.2007, 09:45 erwähnt.



-- Nach Autonull hingegen in der Init machst du zuwenig Pause: Stelle sicher dass mindestens 50ms (!!!) gewartet wird, denn nach Autonull folgt automatisch ein flash-update und das braucht lange.

Habe ich auch im überarbeiteten Code unten geschrieben. Wobei ich mich in der Reihenfolge vertan habe, was mir fumir dankbarer weise gleich mitgeteilt hat, so das wirs klar gestellt haben.


Gruß, Volker

[reflection]

Salu zusammen

Sorry das ich mich nicht mehr gemeldet habe, aber ich hatte sehr viel Arbeit und in der Schule waren auch noch Prüfungen.
Werde mich aber in nächster Zeit wieder vermehrt dem Projekt widmen können. Möchte noch einmal allen für die tollen Artikel danken! Natürlich werde ich meine Erfahrungen, Erfolge, Misserfolge hier kund tun! Denke es ist noch so einiges im Argen :) aber das kriege ich auch noch irgendwie hin. Ist ja bekanntlich noch kein Meister vom Himmel gefallen

Greets reflection

[reflection]

Salu zusammen

Bitte entschuldigt, dass ich diesen „alten“ Thread noch einmal ausgrabe aber ich habe immer noch Probleme mit dem ADIS16250.
Hatte leider erst jetzt wieder Zeit mich dem Problem zu widmen

Folgendes Funktioniert im Moment:

- Die Spannung die ich auslese ist 5V
- Die Temperatur beträgt (inkl. Den 25Grad die man addieren muss) ca. 52Grad
- Der intern integrierte Winkel bleibt im Ruhezustand stehen *freu* und wechselt nun auch zwischen 0 und 360Grad. Der Winkel stimmt ungefähr. Also wenn ich das Gerät um 45Grad drehe zeigt er das auch an.
- Der Gyro Wert ist in etwa konstant. Driftet aber mit ca. 1Grad/s davon.

Denke also das mit der Initialisierung habe ich gepackt.

Nun zu dem was komisch ist:

MSB / LSB:

Ich lese immer noch so aus wie bis anhin. Also ich nehme an dass ich zuerst vom Sensor das LSB erhalte. Ich weiss, das in allen Datenblättern das Gegenteil steht, aber wenn ich annehme, dass der erste Wert das MSB ist, komme ich nie auf 5V oder 52Grad, oder einen Winkelwert der im Entferntesten stimmt. Habe dann irgendwelche Werte die unmöglich stimmen können (Temp. Z.B. 300Grad ect.)
Ich könnte ja jetzt einfach darüber hinwegsehen *dumdidum* aber das macht mir dann doch ein bisschen ein mulmiges Gefühl in der Magengegend

Gyro Winkel:

Problem beim Winkel ist folgendes. Probiere es mal zu beschreiben aber ist nicht so einfach:
Wenn ich einschalte ist der Winkel auf ca. 0Grad (alle Achsen) Die untersten Bits schlackern irgendwie rum, also die Nachkommastellen. Das machen sie rel. flott, also mehrere Mal pro Sekunde wechselt der Wert im Nachkommabereich.
So, drehe ich nun das Gerät passiert erst einmal nix mit dem Winkel der ausgegeben wird. Drehe ich weiter springt er auf einmal von 0Grad auf ca. 9-10Grad. Drehe ich weiter, springt er das nächste mal auf ca. 20Grad usw. Sind also 9-10Grad Schritte der er ausgibt. Der Winkel stimmt dann aber auch in etwa. Also wenn er auf 20Grad springt und ich das messe, dann stimmt das. Aber es kommen halt keine Werte mehr bis ich über den nächsten 10Grad Sprung raus bin.

Kann mir da jemand weiterhelfen. Wie gesagt, die Werte werden schneller ausgelesen (Ruhelage). Erst wenn ich das Gerät drehe gibt er nur alle 9-10Grad einen Wert aus.

Habe auch schon mit der Sensitivity gespielt, brachte nix, ausser das er mehr oder weniger Werte samplet, das funzt natürlich…


Hoffe mir kann einer weiterhelfen. Ich verzweifle. Ein Kollege von mir hat mir auch schon versucht zu helfen, bis jetzt erfolglos. Ist jetzt nicht so, dass wir das erste Mal programmieren, aber so einen Hund hatte ich schon lange nicht mehr drin. Wäre echt wichtig eine Lösung zu finden da die Zeit immer knapper wird.

Merci schon mal im Voraus für Eure Hilfe

Gruss reflection

PS: Achja, ich weiss jetzt nicht ob alle Kommentare noch stimmen, wurde gestern rel. spät.