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?
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
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.
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 ?
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?
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".
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.
Zitieren)
Lesezeichen