Habe Probleme mit Drift bei Gyro ADIS16250

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.

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/refle...&index=0&ID=29

Gruss reflection

sieht cool aus.

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

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.

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 ?

@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

@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.

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?

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

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.

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.

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

@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

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

Salu Volker

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

Gruss reflection

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

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?

@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

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.

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

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

Hi reflection,


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


Viele Grüße,
bluesparkAB

Zitat:

---

Zitat von bluespark

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?

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.

Zitat:

---

- 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.

Zitat:

---

-- 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.

Zitat:

---

-- 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.

---

Code:

---

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.

Zitat:

---

-- 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..

Zitat:

---

-- 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.

Zitat:

---

-- 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 ?

Zitat:

---

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.

Zitat:

---

-- 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

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

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.