Hallo zusammen, ich bin Anfänger im Nutzen von IMUs, und würde gerne wissen ungefähr wie groß die Datenmenge ist pro Abtastperiode, die man von 3-4 9DOF IMUs bekommen würde. Nur so grob gerechnet. Mir geht es darum, dass ich die Sensormessungen aus 3-4 IMUs, wie gesagt, seriell zu einem Computer schicken muss, der für einen Regelungsalgorithmus eine Abtastrate von 1kHz braucht. Also 6DOF IMUs werden auch in Erwägung gezogen, es geht halt darum ungefähr pro DOF wie viel daten pro Abtastperiode geschickt werden, also wie groß die Messung ist. Nehmen wir an mit 400kHz I2C Übertragung. Und also ob man das mit einem anderen IC machen kann statt einem uC? Die Datenblätter sagen meistens was über die Abtastrate aus, die sowieso Standard I2C oder SPI ist, aber nicht viel über die Datenmenge, die eine Messung brauchbar macht. Vielen Dank! -- Hi guys I’m new to the whole IMU business. If I’m trying to gather information from 3-4 different 9DOF IMUs and send it over a serial bus to a computer, and I need that computer to get a total sampling frequency of 1000Hz for the control algorithm to work with, do I necessarily need a microcontroller or is it possible to bundle and send the data with a specific chip? Also, how big is the data bundle that a measurement/sample would have to carry? Say, per DOF, ballpark number? I can't quite figure it out from the Datasheets, they only show the normal SPI/I2C frequencies instead of more detailed information on the data size. Cheers
Die Datenmenge welche die Sensoren Ausgeben ist das kleinste Problem an einer solchen Geschichte. Ein Blick ins Datenblatt deines Sensors dürfte dir alles verraten. Sind aber oft nur wenige Bytes. Wenn dein Roboter, oder was auch immer du baust, nicht gerade alle Mikrosekunden seine Achsen korrigieren soll, sind wohl die 400kHz für I2C auch etwas hoch. Es bringt dir nicht viel, soviele Daten rauszuholen. Ich denke du hast dich bestimmt darüber Informiert, dass die Daten eines IMU's Fusioniert werden müssen. Die Rohwerte bringen dir wenig. Okay, du arbeitest zwar mit einem PC, kann dir aber aus Erfahrung sagen, 400kHz Übertragung mit I2C würde einen Mikrocontroller überfordern, da er innert kurzer Zeit zu viele Daten hätte und mit der Verarbeitung nichtmehr hinterher kommt. Ein PC ist da natürlich schneller, musst halt testen was da so geht.
Also erstmal danke für die Antwort! Ja, also in diesem Arbeitsschritt geht es mir lediglich darum, zu gewährleisten, dass der Regler im Computer (xPC/Simulink Realtime) mit 1kHz die Daten von bis zu 4 9DOF-IMUs bekommt. Ich hab mir jetzt ein weiteres Datenblatt von einem IMU z.B. angeschaut, der pro DOF 16 bits überträgt (LSM9DS0 mit dem SparkFun Breakout). Bei 4 solchen 9DOF-IMUs hätte man 4*9*16 = 576 bits, gewünschte 1000 Mal pro Sekunde. Zudem gibt's bei I2C noch das ganze ACK-Geschäft und Adressierung, also eventuell noch ein bisschen Delay bei der danzen Sammlung der Daten der 3-4 IMUs. Heißt das nicht dass man theoretisch 576kHz "Baud Rate" braucht und somit eher SPI geeignet wäre? Wo habe ich was falsch gedacht? Nicht zu erwähnen, dass ich das noch vom uC aus über UART und dann als RS485 irgendwie zum PC schicken muss. Aber ein Schritt nach dem anderen. Ich hab tatsächlich in anderen Foren gelesen, z.B. bei den Arduino Leuten, dass 1kHz komplette Abtastrate schon ziemlich hoch sein sollte, die haben da immer deutlich weniger als die Hälfte davon hinbekommen, aber nach der Fusionierung, die du erwähnt hast. Die sollte bei mir wie gesagt kein Problem sein, da es keine Arbeit für einen Mikrocontroller ist, sondern für den Computer. Diese 1kHz Abtastrate ist für den digitalen Regler nötig, der in einem Computer läuft. Was danach passiert ist mir weniger wichtig - ich bin zunächst für die digitale Sensorik und für die Lieferung der Daten an den Regler mit 1kHz zuständig. Cheers!
Dann rechne doch einfach mal 4*9DOF*2Byte=72Byte. Das ganze dann halt mit 1kHz. Allerdings bezweifle ich dass sowas sinn macht. Wo ist denn die Bandbreite deiner Sensoren angesiedelt? Manche Sensoren liegen da deutlich drunter!
Marc O.S. schrieb: > Ich hab tatsächlich in anderen Foren gelesen, z.B. bei den Arduino > Leuten, dass 1kHz komplette Abtastrate schon ziemlich hoch sein sollte, > die haben da immer deutlich weniger als die Hälfte davon hinbekommen, > aber nach der Fusionierung, die du erwähnt hast. 1kHz ist auch viel. In meinen Augen zu viel. Ich bezweifle stark dass irgendein System über 1000 mal pro Sekunde nachregeln muss. Zumindest nichts, was normale Menschen zusammenbauen. :P Also kann da nur aus Erfahrung sprechen, ich entwickle derzeit eine eigene Drohne. Braucht natürlich auch ein IMU. Da reicht es ein paar mal pro Sekunde zu Regeln, mehr ist da nicht nötig. Bist du denn sicher dass du bei deiner Applikation eine derart hohe Rate brauchst? Sei dir bewusst, 1'000 mal pro Sekunde etwas Regeln ist enorm viel. Was für ein Gerät muss jede Millisekunde neu ausgerichtet werden? Also in meinen Augen schiesst du/ihr bei deinem/eurem Projekt mit Kanonen auf spatzen. Nop schrieb: > Dann rechne doch einfach mal 4*9DOF*2Byte=72Byte. > Das ganze dann halt mit 1kHz. Er hat gerechnet. Und zwar korrekt. Sehe da nicht, was es zu korrigieren gibt.
:
Bearbeitet durch User
Also ich werde mich da nach euren Einwänden neulich über diese Datenrate informieren müssen, weil es mir eben schon bewusst ist, dass es für die mesiten üblichen Fälle sehr hoch ist. Aber da es eine Forschungsanwendung in der Medizintechnik ist, wo wir gewisse hochfrequente Störungssignale an einen Exoskeleton schicken müssen, kann ich schon gewissermassen nachvollziehen, warum mir diese hohe Zahl gegeben wurde. Werde ich natürlich nochmals nachhacken. Danke nochmals für die Anregungen! Und bitte gerne mehr Infos und Quellen geben wenn ihr wollt =)
Ich wuerde mal weiterdenken in der Richtung, die Regelung in den Controller zu verschieben. Der PC macht das kHz naemlich nicht. Bei weitem nicht.
Siebzehn Zu Fuenfzehn schrieb: > Der PC macht das kHz naemlich nicht. Bei > weitem nicht. Ein normaler uC genau so wenig. Zumindest wenn die Daten Fusioniert werden mit Komplementär oder Kalman Filter. Das wären zu viele Float Rechnungen in so kurzer Zeit. Anmerkung: Beispielsweise im Modellbau werden IMU's oft 50 mal pro Sekunde (50Hz) ausgewertet. Ein MPU6000 (weit verbreiteter Sensor und relativ neu!) sampelt Gyrodaten mit 8kHz, die Accelerometer Daten gerade mal noch mit 1kHz. Ein erster Problem dass sich dir also stellt: Welcher Sensor ist schnell genug? Viel Erfolg beim finden. Die Übertragung der Daten ist das eine, aber wie du siehst kommt dann auch die Geschwindigkeit des Sensors an sich hinzu.
Okto P. schrieb: > Nop schrieb: >> Dann rechne doch einfach mal 4*9DOF*2Byte=72Byte. >> Das ganze dann halt mit 1kHz. > > Er hat gerechnet. Und zwar korrekt. Sehe da nicht, was es zu korrigieren > gibt. Dann schau Dir mal die Zeiten an. 2 min zwischen den Posts. Vllt. hat sich da was überschnitten? ;-)
Nop schrieb: > Dann schau Dir mal die Zeiten an. 2 min zwischen den Posts. Vllt. hat > sich da was überschnitten? ;-) Mag sein. War nur überrascht dass du zum rechnen 2 Bytes verwendet hast & 9DOF, obwohl zu diesem Zeitpunkt nie die Rede davon war dass es nun wirklich 2 Bytes sind. Gut geraten? Wie dem auch sei, tut mir leid. :P Noch als kleine Anmerkung: Je schneller der Sensor, desto grösser das Rauschen. Ein wieterer Grund wieso in der Modellbautechnik oft Sensoren verwendet werden, welche es erlauben die Sample Rate einzustellen. Ist zwar wieder die rede von Modellbautechnik, aber ich behaupte mal ein IMU ist und bleibt ein IMU. Zumindest mehr oder weniger.
Ja, natürlich gibt's auch systemtheoretische Probleme wenn die Datenrate zu hoch ist. Ich müsste diejenige Fragen, die für die Regelungstechnik erstmal zuständig ist, wo die Bandbreite liegt, weil das natürlich auch eine Begrenzung der Abtastfrequenz ist. Die ganze Sache mit digitaler Regelungstechnik die ihr wahrscheinlich schon wisst. Die Aufgaben sind hier halt geteilt und ich bin nunmal erst für die Sensorik zuständig. Mir wurde halt einfach diese Zahl auf den Schoß geschmissen, ich muss noch fragen ob sie das wirklich meinen mit 1000*(Ganze-IMU-Daten) pro Sekunde oder einfach 1000 bit/s. Oder was genau. Aber danke nochmals. Weitere Anregungen und Quellen gerne genommen. Falls das noch niemanden kennt finde ich es übrigens eine gute Quelle für KF gegen Komp. Filter: http://www.olliw.eu/2013/imu-data-fusing/
Hallo hacky, Marc benutzt kein Standard-Betriebssystem, sondern xPC-Target (heute Simulink Realtime). Das ganze ist ein Echtzeit-Betriebssystem für PCs, auf dem kompilierte Simulink-Modelle laufen. Das System ist dadurch sehr schnell. Wir lassen unsere Regler mit bis zu 7kHz laufen, ohne dass es Aussetzer gibt. Stefan
Stefan H. schrieb: > Marc benutzt kein Standard-Betriebssystem, sondern xPC-Target (heute > Simulink Realtime). Das ganze ist ein Echtzeit-Betriebssystem für PCs, > auf dem kompilierte Simulink-Modelle laufen. Das System ist dadurch sehr > schnell. Wir lassen unsere Regler mit bis zu 7kHz laufen, ohne dass es > Aussetzer gibt. Ja, also es handelt sich hier schon um gute Hardware für Forschung im Gebiet der Medizintechnik. Die werden von mir denke ich schon keinen kompletten Unsinn verlangen. Weshalb ich mich hier gerne lieber auf die Sensorik konzentrieren würde also wenn möglich, wie ich so gegen 576 bits 1000 Mal pro Sekunde von 3 bis 4 9DOF-IMUs über seriellen Bus an einen Computer hingehauen bekomme. Ob das rein machbar ist. Aber trotzdem cool dass ihr an der Diskussion engagiert seid!
> Das wären zu viele Float Rechnungen in so kurzer Zeit. Float .. schon verloren. Was sollen float ? Wer braucht soviel dynamischen Bereich? Ein Beschleunigungssensor macht kein Kilosample, die Bandbreite is vielleicht 100Hz. Zudem muss man ja nicht grad einen AVR nehmen. Irgendwas anderes ohne Betriebssystem. Mit einem PC sollte es genuegen an den Parametern zu drehen. Und die Resultate zu ueberwachen.
Marc O.S. schrieb: > wie ich so gegen 576 > bits 1000 Mal pro Sekunde von 3 bis 4 9DOF-IMUs über seriellen Bus an > einen Computer hingehauen bekomme. Darum musst du dich in dem Sinne garnicht kümmern, dass ist wohl das kleinste Problem. Die meisten der Sensoren lassen sich über SPI ansprechen, problemlos schnell genug also. Wie du die auf einen PC kriegst? Habe ich noch nie gemacht und ehrlich gesagt weiss ich auch nicht was da Standard ist. Spontan fällt mir da die Idee ein die Daten mit einem USB fähigen uC auszulesen und sie danach an den PC zu übertragen. Das dürfte funktionieren. Ob's einfacher geht weiss ich nicht, nie gedanken darum gemacht. Stefan H. schrieb: > Wir lassen unsere Regler mit bis zu 7kHz laufen, ohne dass es > Aussetzer gibt. Was sind das für Regler? Komplette IMU Systeme? Falls ja, was für Sensoren braucht ihr? Das würde mich mal brennend interessieren. Siebzehn Zu Fuenfzehn schrieb: > Float .. schon verloren. Was sollen float ? Wer braucht soviel > dynamischen Bereich? Wenn du dich ein bisschen mit IMU beschäftigen würdest, wüsstest du vielleicht wie ich darauf komme. Wie gesagt, die Daten müssen verarbeitet werden. Geh bisschen Googlen nach Kalmann FIlter oder Komplementär Filter. Siebzehn Zu Fuenfzehn schrieb: > Ein Beschleunigungssensor macht kein Kilosample, die Bandbreite is > vielleicht 100Hz. Awas. Die neueren Accelerometer schaffen 1kHz Sample. Aber da hörts dann auch langsam auf. Siebzehn Zu Fuenfzehn schrieb: > Zudem muss man ja nicht grad einen AVR nehmen. Irgendwas anderes ohne > Betriebssystem. Seit wann hat ein AVR ein Betriebssystem?
dann nimm eben SPI oder UART, je nach dem was deine Sensoren unterstützen. Wenn Uart, kannst du auch gleich direkt auf den PC gehen. lg Mat
Okto P. schrieb: > Nop schrieb: > Dann schau Dir mal die Zeiten an. 2 min zwischen den Posts. Vllt. hat > sich da was überschnitten? ;-) > > Mag sein. War nur überrascht dass du zum rechnen 2 Bytes verwendet hast > & 9DOF, obwohl zu diesem Zeitpunkt nie die Rede davon war dass es nun > wirklich 2 Bytes sind. Gut geraten? Wie dem auch sei, tut mir leid. :P Wenn du meinst. 8Bit nimmt heute nun mal keiner an wenn er ne IMU will. Die Folge davon ist, dass es 2 Byte sind. Aber so komplizierte Denkweise steht nicht jedem ;-) > Noch als kleine Anmerkung: > Je schneller der Sensor, desto grösser das Rauschen. Ein wieterer Grund > wieso in der Modellbautechnik oft Sensoren verwendet werden, welche es > erlauben die Sample Rate einzustellen. Ist zwar wieder die rede von > Modellbautechnik, aber ich behaupte mal ein IMU ist und bleibt ein IMU. > Zumindest mehr oder weniger. Aha, ich dachte immer das wird durch die Bandbreite des Sensors beschränkt. Das bei einer langsameren Abtastrate vllt noch ein gleitender Mittelwert oder anderer Filter gerechnet wird erhöht dir vllt ein bisschen das SNR.
Klaus B. schrieb: > Wenn du meinst. 8Bit nimmt heute nun mal keiner an wenn er ne IMU will. > Die Folge davon ist, dass es 2 Byte sind. Aber so komplizierte Denkweise > steht nicht jedem ;-) Wäre ja auch durchaus denkbar dass da ein ganzes Protokoll angeflogen kommt. Ausserdem danke für das liebe kompliment mit dem denken. Ich bin längst nicht so schlau wie viele hier im Forum, bastle aber seit Jahren an RC-Modellen. Spätestens seit meinem selbst entwickeltem BLDC-Controller würde ich es mal wagen zu behaupten, die komplizierte Denkweise ist mir nicht unbedingt Fremd. ;) Soviel dazu. Klaus B. schrieb: > Aha, ich dachte immer das wird durch die Bandbreite des Sensors > beschränkt. Das Rauschen? Klar, irgendwann kommst du an den Punkt an dem es absolut unbrauchbare Daten werden. Aber nur weil ein Auto 250km/h fahren kann, fährst du ja nicht mit der Geschwindigkeit durch die Grossstadt? ;) Klaus B. schrieb: > Das bei einer langsameren Abtastrate vllt noch ein > gleitender Mittelwert oder anderer Filter gerechnet wird erhöht dir vllt > ein bisschen das SNR. Ist dann eine Frage des Sensors. Der MPU6050 hat einen integrierten CMP. Bisschen durchs Datenblatt lesen, ganz nett das Teil. Hat eine völlig revolutionäre Technologie welche sich invensense direkt hat patentieren lassen. Wird wohl ST und andere Hersteller ziemlich nerven :P
>Siebzehn Zu Fuenfzehn schrieb: >> Float .. schon verloren. Was sollen float ? Wer braucht soviel >> dynamischen Bereich? >Wenn du dich ein bisschen mit IMU beschäftigen würdest, wüsstest du >vielleicht wie ich darauf komme. Wie gesagt, die Daten müssen >verarbeitet werden. Geh bisschen Googlen nach Kalmann FIlter oder >Komplementär Filter. Die benannten Operationen sind Matrizen. Solange ein Sensorbereich linear ist, ist ein prozessierter Bereich auch linear. Immer noch kein Grund fuer float. So ganz nebenbei bietet Longint mit 32 bit 10^9 dynamischen Bereich, waehrend Single zwar mehr Bereich bietet, 10^308, aber weniger Bits, naemlich 24. Oder aehnlich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.