Hallo zusammen, ich kenne mich nicht mit Mikrocontroller-Programmierung aus und auch mit C++ sieht es schlecht aus. Zu bieten habe ich ganz gute Kenntnisse in Sachen Zustandsschätzung, Sensordatenfussion, Modellierung dynamischer Prozesse, Identifikation, höherer Regelungstechnik und ins Besondere Fusion von Daten für Beschleunigung, Drehrate, Magnetfeld, GPS uns so on. Ich würde mich freuen, wenn jemand ein Fahrzeug oder Fluggerät mit einer einigermaßen leistungsfähigen Rechenmaschine besitzt und dafür eine ordentliche Sensordatenfusion und evtl. auch Regelung implementieren möchte. Ich weiß noch nicht mal genau welche Programmiersprache man am besten verwendet, meine Vermutung wäre C++. Hab gesehen, dass es da die Boost-Bibliothek gibt, die einige Matrix-Klassen und -operationen bereit stellt. Generell bin ich aber für alle Ideen offen. Der Mikrocontroller müsste schon ne richtige Gleitkomma-Recheneinheit haben um der Aufgabe gewachsen zu sein denke ich, vor allem wenn ein nichtlinearer Zustandsschätzer zum Einsatz kommen soll - aber erst mal ganz klein anfangen. Wie ich mir die ganze Sache konkret vorstelle: Es wird definitiv auf etwas Arbeit hinaus laufen. Erst mal muss das dynamische Modell identifiziert werden. Dazu muss ich wissen wie das Fahrzeug aufgebaut ist. Wo sitzen die Sensoren, Aktoren. Dann benötige ich aufgezeichnete Messdaten aller Sensoren bei bestimmten Bewegungen. Ich liefere dann die Gleichungen mit Erklärung und Diskussion und dann genaue Überlegungen, welche Algorithmen verwendet werden müssen (z.B. zum Matrix invertieren bzw. umordnen je nach Fall). Ich hoffe dann, dass wir gemeinsam Programmcode zustande bringen. Bei den Experimenten bin ich dann wohl nicht dabei, aber bei der Auswertung und Fehlersuche. Wär das eine Idee? Hätte jemand Interesse oder wollen wir gleich ne kleine Gruppe auf machen? Mein Ziel wär es halt mal zu erfahren wie es praktisch so laufen kann, da ich bisher nur mit Matlab/Simulink unterwegs war, was ja im wissenschaftlichen Bereich sehr verbreitet ist. Ansonsten ist das ja etwas unpraktikabler Mist, immer von Mathworks abhängig zu sein. Liebe Grüße Tobi
Nabend, Grundsätzlich wäre ich an einer Zusammenarbeit interessiert. Fluggerät alla Quadrokopter, habe ich zur Verfügung. Ich bin gerade selbst dabei die Regler für die Motoren mit FOC, und Zustandsregler zu bauen. Der Zeit stehe ich aber noch beim Hardwaredesign. Vllt besteht ja schon auf der seite Interesse bei dir? MfG Tec
Hallo Tec, das hört sich interessant an. Ich muss jedoch sagen, dass ich mich mit diesen Freuquenzumrichter Raumzeiger Geschichten nicht so auskenne. Müsste man mal sehen, ob/wie ich dir da eine Hilfe bin. Dafür wär ich dann im nächsten Schritt besser dabei, wenns um Sensordatenfusion/Flugregelung geht. Was für Hardware/Sensoren werden denn an Bord sein? MfG Tobi
Moin, Ich dachte an einen Playstation Move Controller. Da ist n STM32f103 drauf, 3 Achs-Magnetfeld,Beschleunidung und Drehrate. ich wollte noch dGPS ergänzen. Vllt später mal n 2. Playstation Move, Ich hab hier ne Dissertation liegen über die Fusion von 2 gleichen Sensoren zu Verbesserung der Drift kompensation über einen Kalman Filter. Zum FU mein Aktueller Ansatz ist die AN1078 von Microchip. Ich bin gerade dabei die HW für einen Prototypen so zu designen das ich die Endstufe mit einem dsPIC33F und meinem STM3210B Eval board steuern kann. Ich muss mal sehen wie viel Rechnenleistung ich wirklich brauche. Wenn du lust hast kannst dich dich gern mit der Systemmodelierung einer 14-pol Außenläufer permanent erregten Syncronmaschine/BLDC aus ein ander setzen. Das grundsätzliche Verfahren ist in der Appnote beschrieben. Es gibt auch fertige Modelle der PMSM(permanent Magnet Syncronmaschine) im Netz bei goMatlab. Ich wollte erst mal die HW fertig machen. MfG Tec
Ich bin nun schon gedanklich seit 2009 dabei (nicht kontinuierlich) so ein Teil zu bauen. Wie ich das Hardwareseitig im Endstadium aufgezogen haben möchte steht (kein 1-Prozessor System sondern etwas anders), Schaltplan möchte ich demnächst beginnen. Mir bereitet im Moment noch die Mathematik und modellierung des Systems bauchweh. Die Bausteine kenn ich, wie sie zusammen gehören auch aber aufgestellt bekomme ich das Modell nicht. Ich wollte den weg über DCM gehen. Quadrocopter oder sonstige Hardware sind damit noch nicht vorhanden, sollen aber in Zukunft folgen (wenn der Rest mal steht). Wir können uns ja mal kurzschließen.
Ano Nym schrieb: > Mir bereitet im Moment noch > die Mathematik und modellierung des Systems bauchweh. Die Bausteine kenn > ich, wie sie zusammen gehören auch aber aufgestellt bekomme ich das > Modell nicht. Ich wollte den weg über DCM gehen. Hallo, da trifft man sich noch mal wieder... ich hatte dir ja mal einen kleinen Tipp gegeben, wie man mit der Modellierung anfangen könnten: Beitrag "Re: Kalman Filter zur Sensorfusion mit Simulink" Hat das etwas weiter geholfen, oder so gar nicht? LG Tobi
Tec Nologic schrieb: > Ich dachte an einen Playstation Move Controller. Da ist n STM32f103 > drauf, > 3 Achs-Magnetfeld,Beschleunidung und Drehrate. ich wollte noch dGPS > ergänzen. Vllt später mal n 2. Playstation Move, Ich hab hier ne > Dissertation liegen über die Fusion von 2 gleichen Sensoren zu > Verbesserung der Drift kompensation über einen Kalman Filter. > > Zum FU mein Aktueller Ansatz ist die AN1078 von Microchip. Ich bin > gerade dabei die HW für einen Prototypen so zu designen das ich die > Endstufe mit einem dsPIC33F und meinem STM3210B Eval board steuern kann. > Ich muss mal sehen wie viel Rechnenleistung ich wirklich brauche. > > Wenn du lust hast kannst dich dich gern mit der Systemmodelierung einer > 14-pol Außenläufer permanent erregten Syncronmaschine/BLDC aus ein ander > setzen. Das grundsätzliche Verfahren ist in der Appnote beschrieben. Es > gibt auch fertige Modelle der PMSM(permanent Magnet Syncronmaschine) im > Netz bei goMatlab. Ich wollte erst mal die HW fertig machen. Magnetfeld, Beschleunigung und Drehrate, evtl. GPS ist ja ne wirklich gute Ausstattung. Wenn ich das richtig sehe bringt dieser dsPIC33F auch ordentlich Rechenleistung. Um später die Flughöhe in den Griff zu kriegen würde ein kleiner Drucksensor sicher noch einiges raus holen. Ich würde dann mal überlegen wie man die Informationen verrechnet, noch ist ja etwas Zeit denke ich mal. Die Motor-Geschichte ist ja leider nicht so mein Ding, wie ich bereits sagte :-( MfG Tobi
Tobias no schrieb: > Ano Nym schrieb: >> Mir bereitet im Moment noch >> die Mathematik und modellierung des Systems bauchweh. Die Bausteine kenn >> ich, wie sie zusammen gehören auch aber aufgestellt bekomme ich das >> Modell nicht. Ich wollte den weg über DCM gehen. > Hallo, da trifft man sich noch mal wieder... > ich hatte dir ja mal einen kleinen Tipp gegeben, wie man mit der > Modellierung anfangen könnten: > Beitrag "Re: Kalman Filter zur Sensorfusion mit Simulink" > Hat das etwas weiter geholfen, oder so gar nicht? > LG > Tobi Ein wenig. Ich habs irgendwie nie geschafft zu Antworten obwohl das Tab in meinem heimatlichen Firefox seither offen ist. Hab aber neue Erkenntnisse die ich hoffentlich die Tage poste. Ich hoff ich find die ganzen LInks noch ... mein Firefox ist demletzt abgestürzt und hat nicht alles wieder hergestellt :/ Hab aber nen super DCM Algorithmus gefunden den ich versuche zu adaptieren. Wie gesagt, ich verstehe das Modell bzw seine Bazusteine bekomms aber nicht so richtig auf die Kette das auf eigene Faust zusammenzubasteln ...
Ano Nym schrieb: > Hab aber nen super DCM Algorithmus gefunden den ich versuche zu > adaptieren. Wie gesagt, ich verstehe das Modell bzw seine Bazusteine > bekomms aber nicht so richtig auf die Kette das auf eigene Faust > zusammenzubasteln ... Das kann ich verstehen... ist ja auch nicht ganz ohne sicherlich. Um einen Fehler zu finden muss mans ja meist alles komplett im einzelnen verstanden haben, anstrengenderweise. Mir bereitet die Implementierung die größten Probleme, bzw. hab es auch noch nie ausprobiert und weiß gar nicht wo ich anfangen soll, hab auch gar keine Hardware. In Gleichungen kann ich es hingegen aufschreiben... und halt in Matlab-Code, was ja etwas das selbe ist. Naja, jedenfalls hab ich mich ja deshalb hier gemeldet, in der Hoffnung gemeinsam was auf die Beine zu stellen.
Eine Gemeinschaft wär sicherlich nicht das verkehrteste.
Kurz zu meiner Idee:
o Sensoren sollten sein
- ACC
- Drehrate
- GPS (statt Kompass da man so gleichzeitig die Geschwindigkeit mit
dabei
hat und ein abgleich fehlt)
- Druck (für Höhe)
o Sensorfusion in einem kleinen FPGA oder CPLD (wenn möglich) um die
Daten
echtparallel in den Chip zu bekommen - VHDL/Verilog Erfahrung hab ich
so gut wie keine
o Der Fluglageregler und ggf. eine Navigation und was sonst noch so
anfallen könnte soll ein Leistungsstarker/ärkerer ARM (STM?) übernehmen
o Brushless Regler tuts entweder der von Mikrokopter.de oder man baut
auch
da was eigenes - jeweils wieder mit eigenem Prozessor das man eben
ein
verteiltes System erhält und so die Rechenleistung verteilt (soll
sich
doch jeder Regler selbst um seinen Motor kümmern)
o Platine soll 4 Lagen maximal haben. Als Software stünde Eagle zur
Verfügung, überlege aber das gaze in KiCad zu Planen, einfach um mal
was
anders benutzt zu haben
Das ist so mein Plan... Ambitioniert, vielleicht an der ein oder anderen
Stelle überflüssig, aber ich fänd das interessant umzusetzen.
Tobias no schrieb: > richtig sehe bringt dieser dsPIC33F auch > > ordentlich Rechenleistung moin zusammen, Die dsPic33f sind nur für die Motor Controller, bringt dann hoffendlich mal einen höhere Dynamik und weniger Geräusche an den Motoren. Ich kann ja bereichten wie ich weiter komme, die Motorregler will ich im Nächsten Monat so weit haben das sie laufen. Die richtige Regelung sollte auf dem STM32 aka Arm Cortex M3. Der hat noch etwas mehr Leistung und sollte auch mit Daten loggen auf SD-Karte und Funkbrücke keine Probleme haben. Falls du und orim ne Simulation fertig bekommt, probiere ich gern die Regelung in meine Hardware zu implementieren. Eckdaten: m ca.: 1kg Rotoren im Kreuz angeordnet. Von der Mitte zum Motor sind ca: 24cm Masse am Ausleger ca. 100g. Tägheitsmoment habe ich nch nicht berechnet. Max Schub pro Motor ca.: 800g im Stand, was auf Schweben ja passt. MfG Tec
Ich werf mal einen Pointer in den Raum http://gentlenav.googlecode.com/files/DCMDraft2.pdf Les ich eben nebenbei (während mein Hardwaretest hier rennt :) ) und siehe da, die nutzen scheinbar nur einen PI Regler und (wiedermal) Mahoneys Formeln
Ist hat das simpelste wenn du den Kalmanfilter und die Transformationen hast. wobei ich einen Zustandsregler für jeder Richtung der Lage vor ziehen würde. und vllt einen Großen für die xyz-Position. Aber das ist der zeit nur Spekulation. MfG tec
Lageregelung erstmal ausen vor gelassen - da macht Zustandsregelung durchaus Sinn. Ging mir erstmal nur um die IMU und da hege ich obigen Plan. Wobei ich denke das ein kleiner FPGA sinniger wäre.
Tec Nologic schrieb: > Die richtige Regelung sollte auf dem STM32 aka Arm Cortex M3. Der hat > noch etwas mehr Leistung und sollte auch mit Daten loggen auf SD-Karte > und Funkbrücke keine Probleme haben. > > Eckdaten: > > m ca.: 1kg > Rotoren im Kreuz angeordnet. Von der Mitte zum Motor sind ca: 24cm > Masse am Ausleger ca. 100g. Tägheitsmoment habe ich nch nicht berechnet. > Max Schub pro Motor ca.: 800g im Stand, was auf Schweben ja passt. Super Sache, wenn das mit dem Daten loggen klappt. Danke für die Eckdaten, da kann man ja schon ganz gut was mit anfangen. Bin grad auf Linux umgestiegen und hab deshalb kein CAC-Programm mehr am Start um den Trägheitstensor näherungsweise zu berechnen. Kann das jemand anders grad aus dem Ärmel zaubern? Welchen Abstand haben die Sensoren eigentlich vom Masse-Schwerpunkt, kannst du das etwa abschätzen? LG Tobi
Moin Tobi, Die Platinen sitzen genau auf dem Schwerpunkt, in der Mitte der Konstuktion. Davon ausgehend das der Schwerpunkt zum Akku hin verschoben wird sollte dieser in der Mitte des Kreuzes ca. 1cm unter der Ebene die das Kreuz aufspannt liegen. Geht man davon aus die Platinen kommen huckepack auf die andere Seite würde ich sagen das die Sensoren ca. 3cm in Z-Achse nach oben verschoben sind. Die Abweichung in X und Y kann ich noch nicht sagen die sollte sich aber im bereich von <2cm um den Mittelpunkt befinden. Der Mittelpunkt der Rotoren liegt ca. 4cm in der Z-Achse höher als der Schwerpunkt. Das Sollte glaube ich alles sein was man benötigt um die Mechanik zu modelieren. Zu den Rotoren kann ic der Zeit sagen das diese Ihren Drehzahl Sollwert näherungsweise als PT-2 Glied mit einer Dämpfung von 1/sqrt(2) Anfahren. Zeitkonnstanten muss ich noch Messen. MfG Tec
Tec Nologic schrieb: > Die Platinen sitzen genau auf dem Schwerpunkt, in der Mitte der > Konstuktion. Davon ausgehend das der Schwerpunkt zum Akku hin verschoben > wird sollte dieser in der Mitte des Kreuzes ca. 1cm unter der Ebene die > das Kreuz aufspannt liegen. Geht man davon aus die Platinen kommen > huckepack auf die andere Seite würde ich sagen das die Sensoren ca. 3cm > in Z-Achse nach oben verschoben sind. Die Abweichung in X und Y kann ich > noch nicht sagen die sollte sich aber im bereich von <2cm um den > Mittelpunkt befinden. Der Mittelpunkt der Rotoren liegt ca. 4cm in der > Z-Achse höher als der Schwerpunkt. Das Sollte glaube ich alles sein was > man benötigt um die Mechanik zu modelieren. Zu den Rotoren kann ic der > Zeit sagen das diese > Ihren Drehzahl Sollwert näherungsweise als PT-2 Glied mit einer Dämpfung > von 1/sqrt(2) Anfahren. Zeitkonnstanten muss ich noch Messen. Respekt. Studierst du E-Technik, oder schon fertig?
Klingt eher nach Mechatronik oder Hobby Maschinenbauer. Wir hatten zwar in Physik den ganzen Kram behandelt aber nie praktisch angewendet oder irgendeine Software genommen um irgendeine reale Mechanik zu charakterisieren...
Ano Nym schrieb: > Klingt eher nach Mechatronik oder Hobby Maschinenbauer. Wir hatten zwar > in Physik den ganzen Kram behandelt aber nie praktisch angewendet oder > irgendeine Software genommen um irgendeine reale Mechanik zu > charakterisieren... Bist du Mechatroniker?
Ich sagte doch wir hatten das nicht, daher denke ich das er Mechatroniker ist... wie kann ich denn, wenn ich sage das ich vermute das er Mechatroniker ist "wenn er das kann", Mechatroniker sein wenn ich das nie als Vorlesung gehört habe? :D Ne ich bin ETechniker
Tante Edit: Mir kam mittlerweile auch die Idee auf nur einen FPGA zu schnappen und dort einen Softcore für die Regelung, ggf den Kalman und parallel die Daten acquirierung als Hardware zu implementieren. Sozusagen ein IMU SOC. Ich erhoff mir nebenbei durch den Einsatz eines FPGA zur Daten akquirierung etwas mehr Updaterate - einfach weil man alle Daten gleichzeitig in den Chip kriegt und alle gleichzeitig normieren und transponieren kann, dann brauchts nur noch den Kalman zu berechnen. Ferner könnte man sich Matrix-Multiplikatoren in Hardware auslegen die die Software benutzt, macht das ganze auch noch mal schneller - ggf.
Angehängte Dateien:
-
QuadrocopterSpa__.png
440 KB
Hee, hab grad SolidWorks in ner virtualbox in linux zum laufen bekommen Schaut doch lustig aus oder? :-) Naja, is nur n Quatsch. Ich denke ich sollt das Material einfach homogen annehmen und dann nur die Masse in der Mitte als Zylinder und die Motoren außen als Zylinder und dann ist das sicher genügend genau angenähert oder was meint ihr? Ok, jetzt nicht lachen, das kriegt man sicher auch mit nem Schulmathebuch und dem Satz von Steiner hin.. ich erinnere mich, da war ja was. Aber kann ich von Hand auch schwupp die wupp den Trägheitstensor ausspucken, oder muss ich dann für jede Achse einzeln...
Ano Nym schrieb: > Tante Edit: Mir kam mittlerweile auch die Idee auf nur einen FPGA zu > schnappen und dort einen Softcore für die Regelung, ggf den Kalman und > parallel die Daten acquirierung als Hardware zu implementieren. > Sozusagen ein IMU SOC. Ich erhoff mir nebenbei durch den Einsatz eines > FPGA zur Daten akquirierung etwas mehr Updaterate - einfach weil man > alle Daten gleichzeitig in den Chip kriegt und alle gleichzeitig > normieren und transponieren kann, dann brauchts nur noch den Kalman zu > berechnen. Ferner könnte man sich Matrix-Multiplikatoren in Hardware > auslegen die die Software benutzt, macht das ganze auch noch mal > schneller - ggf. Du hast ja großes vor. Wär sicher gut, wenn du auch was aufbaust, vielleicht kommst du ja auch etwa soweit wie Tec Nologic und wir können mal vergleichen, welche Varianten so welche Vorzüge haben.
Ich bin gerade den ersten Monat im Betrieb also gerade erst fertig. Hab E-Technik studiert, Automatisierung. Das Model sieht gut aus tobi, ich dachte mir das auch so. Aber derzeit gehts mir um die Antriebe. Das mit dem FPGA hört sich nicht schlecht an, wobei ich glaube das du mit einem STM32F103 oder F20x genaus gut, und womöglich einfacher fährst. Der FPGA braucht externen Ram und Flash usw. das stellt ganz andere Anforderungen an das Layout und die Fertigung. Ich für meinen Teil bin da eher für keep it simple. Guck dir die Mikrokopter Jungs an die Fahren die Lage Regelung auf einem AVR und arbeiten mit 100Hz. mein Ziel sind 500 oder 1000Hz Regelzyklus. und eben nicht als PID sondern als Z-Regler, bzw PIZ-Regler. Und eben so viel Sensordaten wie möglich herran zu ziehen. Mit den Sensoren die ich vorher mal gepostet habe kannst du alle Zustandsgrößen Messen. damit kannste n Beobachter über Kalman abgleichen und gut. Dann musste nur noch den Regler dimensionieren. Das Große Problem sind die Winkel Funktionen in dem Matrizen usw. Da muss man in die Implementierung gehirnschmals Reinstecken um den rechnen Aufwand zu erschlagen notfalls mit ner Lut. Wobei ich das nicht glaube. Wenn das n Adurno oder son 644 von Atmel packt dann sollte das mit Cortex kein Problem darstellen, zur not dann n M4 von Freescale der hat ne FPU. MfG Tec
Klar, das packen die kleinsten Prozessoren irgendwie. Gibt für Matrixberechnungen Algorithmen noch und nöcher. Aber: Soweit ich das mitbekommen habe approximieren die meisten nur und machen viele annahmen. Die meisten benutzen noch nicht einmal einen Kalman Filter. Es hat ja auch seinen Grund warum die Preisspanne für fertige IMUs so weit auseinander geht. Ein STM32 oder ein OMAP oder so ein Vieh schafft das mit Sicherheit auch. Ich wollte einen FPGA nehmen um a) mal was anders zu machen (gibt nicht so viele IMUs mit FPGA - gerade im Hobby Bereich) und b) aus oben genannten Gründen. Um das ganze wirklich optimal auszulegen brauchts von der Rechenmaschine her schon Dinge die die Auswahl des Prozessors schwierig machen. Wenn man nun alle Fäden in der Hand hat, so hoffe ich, erschlägt man das ganze gerade so wie man möchte. Ein Selfmade SOC wenn man so möchte. Externer Speicher, Flash zum Speichern der Konfiguration, eine gewisse Bootzeit um die Konfig zu laden, mehrlagiges komplexes Layout sind die Nachteile des ganzen. Ich kann mir aber vorstellen das die Ersparnis beim akquirieren der Daten (Prozessor sagt "acquire" und im nächsten Moment werden Zeitgleich die Daten von ACC, Gyro, Magnetfeld und Höhe echtparallel ausgelesen und echtparallel normiert/transformiert) einen mehrwert darstellen. Klar, man müsste zwei Systeme parallel haben und die vergleichen, ansonsten sind es nur mutmaßungen. Ein weiterer Punkt bei dem ich mir noch nicht so einig bin ist die Positionierung der Sensoren. Am besten wäre alle auf einem mathematischen Punkt im Schwerpunkt anzuordnen. Geht aber nicht. Was aber geht ist die maximale Anzahl an Sensoren und deren Baugröße zu minimieren und so Platzsparend wie nur irgendmöglich verbauen. Mir schwebt da was im Kopf rum, weiß nur noch nicht wie machbar und sinnvoll das ganze sein würde ... Am aller geilsten wäre ein Sensor wo zumindest Gyro und ACC in einem Chip verbaut sind. Hat auch Nachteile, ganz klar, Vorteil wäre aber das die beiden sehr nah am Schwerpunkt sind. Sind nur relativ teuer soweit ich das in Erinnerung hab. Anyway, ich misch mich hier nur ein weil ich mich über einen Projektpartner nicht beschweren würde, zumal ich Hardwareseitig meine Ideen habe, ein gewisses Grundverständnis mitbringe, schön bescheuert und kreativ bin :D und es mathematisch irgendwie allein nicht so richtig auf die Kette bring das ganze selbst zu modellieren - man kann nicht alles können. @Schwerpunkt: Sollte der bei einem symmetrischen aufbau nicht im Schnittpunkt der Achsen liegen? @Tec Nologic: Wo hast du studiert? Oder machst du Hobbymäßig viel? Ich frag so doof weil wir mechanisch quasi gar nichts mitbekommen haben, du hingegen scheinst ja durchaus fundierte Kenntnisse in die Richtung mitzubringen, inkl. Solid Works know how (wenn ich dich nicht verwechsel)
Angehängte Dateien:
Ano Nym schrieb: > Ideen habe, ein gewisses Grundverständnis mitbringe, schön bescheuert > und kreativ bin :D und es mathematisch irgendwie allein nicht so richtig > auf die Kette bring das ganze selbst zu modellieren - man kann nicht Passt schon :-) Übrigens: mathematisch ist das kein Problem, wenn die Sensoren nicht im Massemittelpunkt liegen. Das ist ja auch gar nicht möglich. Oder glaubst du, in nem großen Jet werden die Koffer und der Treibstoff immer so gepumpt, dass der Sensor schön in der Mitte liegt :-) Der Masseschwerpunkt änder sich also fortwährend. Wenn ein Sensor im Schwerpunkt liegt, kann man sich die Berechnung einer Gleichung sparen und zwar siehe Bild. y: Beschleunigung wie sie vom Sensor gemessen wird v_q: körperfeste Geschwindigkeit (Masseschwerpunkt bezogen) w_q: " Drehrate " P_b,Sensor: Einbauposition des Sensors in Konstruktions-Koordinaten B_b,Masse: Momentaner Masseschwerpunkt in Konstru.... C_e_q : Transformationsmatrix Erdfest -> körperfest g: Erdbeschleunigung hoffe dich erhellt zu haben
Ano Nym schrieb: > @Tec Nologic: Wo hast du studiert? Oder machst du Hobbymäßig viel? Ich > > frag so doof weil wir mechanisch quasi gar nichts mitbekommen haben, du > > hingegen scheinst ja durchaus fundierte Kenntnisse in die Richtung > > mitzubringen, inkl. Solid Works know how (wenn ich dich nicht > > verwechsel) Ich hab in Hamburg studiert, das mit der Mechanik ist aber viel aus dem Hobby begründet und aus den Vorlesungen für Zustands und allg. Regelungstechnik. Also bei den sachen mit dem FPGA bin ich schon dabei. Ich habe aber von den dinger nur mäßig bis gar keine Ahnung. Ich arbeite meißt mit Cotrollern. Aber es gibt ja auch n Cortex M3 Softcore den Zu Programmieren Traue ich mir ohne weiteres zu. Grundsätzlich bin ich auch an einem Projektpartner interesiert. Ich will aber auch fertig werden. bzw. mal einen lauffähigen stand bauen den man dann erweitern bzw umbauen kann. Z.B mit STm32 anfangen, zum laufen bekommen, dann auf FPGA um steigen, und das System überarbeiten. MfG Tec
Klar machts nix wenns nich in einem Punkt im Masseschwerpunkt liegt - transformiert mans halt :) Hamburg, ok. Hätte nu München gedacht hehe. Also ich wär dabei bei sonem Projekt. Warum nicht gleich FPGA? Ich hab davon auch noch nicht so den Dunst, aber zwei Ingenieure sollten das doch gebacken kriegen. Cortex M3 Softpo...core klingt auch gut...
Ano Nym schrieb: > Also ich wär dabei bei sonem Projekt. Warum nicht gleich FPGA? Ich hab > davon auch noch nicht so den Dunst, aber zwei Ingenieure sollten das > doch gebacken kriegen. Cortex M3 Softpo...core klingt auch gut... Hast du schon mal ein kleines Test-Projekt mit FPGA realisiert und kannst das Ausmaß deines Vorhabens einschätzen? Aus der konkreten Entscheidung in Sachen Hardware möchte ich mich eigentlich raus halten, da das nicht mein Ding ist und ihr ja letztendlich davor sitzt und mit dem Teil kommunizieren müsst. Aber so ganz grundsätzlich halte ich es für besser sich etwas vorzunehmen, was man in definierter Zeit sicher hin bekommt. D.h. wo man vorher schon mal ein kleines erstes Projekt hin bekommen hat. Probleme und Schwierigkeiten entstehen dann ja trotzdem noch genug. Was meint ihr?
Moin Sehe ich auch so Tobi, ein Ende muss abzusehen sein. des wegen meinte ich ja erst mal mit nem µC das ganze machen, mit allen Nachteilen die das mitsich bringt. Und wenn das Läuft kann man aufs FPGA gehen, dann hat man für den Cortex M3 da drin auch schon Code und braucht nur das DeviceLayer der SW anfassen und den Perephierie code ändern. Im RTOS usw bleibt das meiste gleich wenn wir uns beim Code an CMSIS halten. MfG Tec
Ich hab mit FPGAs noch fast nichts gemacht. Schon gar keine Hardware. Ich hab mir VHDL zwar gezwungenermaßen mal angesehen und eine Lampe zum leuchten gebracht aber das wars dann auch im großen und ganzen. "Aber so ganz grundsätzlich halte ich es für besser sich etwas vorzunehmen, was man in definierter Zeit sicher hin bekommt" In dem Punkt geb ich euch recht. Aber: Wenn man nur so denkt kommt man nicht voran, man muss auch mal Neuland betreten ;) Aber klar, wenn man sich auf Cortex M3 einigt und es dafür Softcores gibt ist eine prototypsche Implementierung in einem Cortex M3 sicherlich nicht verkehrt - dann teilt man das in zwei Baustellen auf. Also wenn ihr wollt tu ich mich mit euch zusammen. Wir müssen nur schauen das jeder damit zufrieden ist was am Ende rauskommt :D PS: Ich hätte gerne ein Fluggerät ala Quadrocopter das 5kg Nutzlast tragen kann hust Wie gehen wir weiter vor? In dem Thread hier? Wo anders? Und welchen Prozessor ... STM? Oder einen OMAP L137 (ARM9/DSP)?
Also Ich bin auch dran interessiert. An HW habe ich hier ein Alukreuz mit 4 200W Motoren und Luftschrauben. Sollte ca. 1kg Nutzlast haben, da andere Motoren zu nehmen und die Endstufe der Regler aufzublasen ist kein Ding. Zum Thema Antriebe, würde ich mich Um die Antriebsregler kümmern da bin ich schon recht weit. Auf dsPic Basis, ich dachte an SPI Bus unter den Motor Controllern und dem Hauptprozie. Als Basis dachte für die Hauptplatine an einen Playstation Move Controller von dem habe ich die Schmatics und der hat alle Notwenigen Sensoren außer GPS drauf. Da für habe ich noch ne alte GPS Maus rum liegen. In dem Playstation ding ist ein STM32 drin. Außerdem habe ich ein STM3210B Eval Board in meinem Schrank deswegen wäre ich für den, ich habe aber auch n Evalbot von ti stehen der hat auch n CM3 drauf. Die Playstation Controller gibts für ca. 35Euro billiger bekommst du die Sensorik nicht. und für einen ersten Versuch ist das eine schöne Basis denke ich. Wenn man damit was zum fliegen hat, kann man sich bessere Sensoren suchen. und n Redesign machen. Vllt dann auch mit FPGA. Toll wäre es wenn sich Tobi darum Kümmert wie die Regelung laufen muss, Matlab Simulaton usw. Ich mach die Antriebsregler Fertig, und du Orrim Schaust dir die Hardware für den Hauptprozessor und Sensoren an? So als Vorschlag? MfG Tec
Hm die Sensoren bekommt man nicht günstiger als umsonst. Ich hab Sensoren im Wert von grob 120€ daheim rumfliegen, alles Samples von Analog... Genauer werden die allemal sein. Die Nummer ist nur das wir alle an einem Strang ziehen müssen und das auch als Projekt aufziehen müssen. Irgendwie zusammenwerfen ist blöd. Der Softi muss ja wissen was sich der Hardwareker gedacht hat. Als Bus tuts SPI das is richtig. I2C wäre auch nicht verkehrt. CAN und RS232 wahrscheinlich mit am Störsichersten.
Tec Nologic schrieb: > Toll wäre es wenn sich Tobi darum Kümmert wie die Regelung laufen muss, > Matlab Simulaton usw. bin ich dabei
Alex schrieb: > Für die Sensorik werfe ich das hier mal in den Raum: > > http://cgi.ebay.de/260766413411 > > MfG Hey, haben wir noch einen Mitstreiter bekommen?
Orrim sehe ich auch so, Wir sollten mal festhalten was der erste Schritt ist, wo wir hin wollen also was ist Ziel in erster Instanz? Schweben auf der Stelle mit GPS Positions Regelung? vllt Waypoints? Das Sensor Board ist gut, aber bei Sparkfun bekommste ähnliche, Genauigkeit ist ähnlich der auf dem Playstation Ding und das ist billiger aber mit Bastelaufwand verbunden. Orrim wenn du Sensoren liegen hast super, dann ist das Playstation ding außen Vor. Wir sollten uns Erst mal auf eine HW Plattform grob einigen. Proze, welche Busse welche Sensoren. Was fü ein Board? also 0.5mm Pinch kann ich doppel seitig privat ätzen, wobei wir ja mehrere Sind da lohnt sich das schon das Fertigen zulassen. MfG Tec
Ich hab halt bei dem ganzen ein bisschen einen höheren anspruch als irgendwie fertige Hardware zusammen zu suchen und zusammen zu basteln - wenn man das so sagen möchte. Die Sensoren die ich hab gibts mitlerweile nicht mehr. Aber Analog hat ja noch mehr zu bieten außer und es gibt viele als Sample. Egal wie, hier fangen alle an zu basteln. Löblich, funktioniert aber eventuell nicht. Ist ja etwas umfangreicher das ganze. Zumindest sehe ich pers. das so das wir ein bisschen im Projekt arbeiten sollten. In wie weit man das aufbläst ist eine andere Sache, aber man sollte sich zumindest einigen wer was macht, maximale Kosten, Hardware Spec (Platinen abmaße, max. Gewicht, Prozessor, Modularität etc), Software Spec und so weiter ... Sonst macht am Ende jeder alles
Das klingt nach einem Plan, erst mal die Spec zu klären ist auf jeden Fall sinnvoll, und notwendig. Des halb fragte ich ja wo wollen wir hin, was brauchen wir da für.
Tobias no schrieb: > Alex schrieb: >> Für die Sensorik werfe ich das hier mal in den Raum: >> >> http://cgi.ebay.de/260766413411 >> >> MfG > > Hey, haben wir noch einen Mitstreiter bekommen? Unter Umständen ;) Ich bin nur leider im Augenbick noch anderweitig gebunden (BA). Erfahrungen habe ich im Bereich Zustandsschätzung (spz Kalman-Filter) und was halt da so alles dran hängt. Ich hatte auch mal geplant einen Copter zu bauen und mich dementsprechend auch schon nach Sensorik usw umgeschaut. Bei dem Prozessor dachte ich an einen STM32F2 oder die Cortex M4 von ST mit FPU. STM32 aus dem Grund, da es die auch in einem kleinen Package für die Motortreiber gäbe und man somit sich nicht in unterschiedliche Prozessoren einarbeiten müsste. Zu den Sensoren kann ich sagen, dass ich über die Bosch-Sensorik bis jetzt nur Gutes gehört habe und das Board aus meinen Link im Vergleich zu den einzelnen von Sparkfun, Waterott echt billig ist. MfG
Was die Motorregelung angeht da bin ich gerade dran das in FOC zu realisieren aber mit dsPIc der Zeit, da ich dort ne schone Appnote habe, für die Zukunft sehe ich auch eine Erweiterung des ganzen auf einen STM32. aber erst wenn der dsPic Läuft. Die F20x von St finde ich auch interesant. Ich würde bei Arm Cortex ob M3 oder M4 bleiben, da diese sehr gute Entwicklungstools bieten. Wir sollen erst mal klären was wir haben wollen, wo mit alle halbwegs zu frieden sind. Solange wir noch so wenige sind, bei zu vielen wird das zu aufwändig. Wer schreibt mal ne Spec für den Copter? ich will mich erst mal auf den Motorregler konzentrieren weil ich dafür ales liegen habe gerade. MfG Tec
Tec Nologic schrieb: > Die F20x von St finde ich auch interesant. Ich würde bei Arm Cortex ob > M3 oder M4 bleiben, da diese sehr gute Entwicklungstools bieten. ein STM32F20x ist doch auch ein Cortex M3 MfG
Ja weiß ich, aber der M4 waar auch schon im Gespräch, wobi ich biher nur von freescale weiß das die einen auf dem Markt haben.
Das wusste ich nicht, Ich dachte es wäre eine Spec von ARM der der Kern ne FPU hat. Das ist wohl wie mit der DebugMicrocell des M3, die uch nicht jeder hat. Und ITM undterstützt ja auch kaum eine Entwicklungsumgebung
Also wenn es noch Möglichkeit gibt das in der Hardware zu berücksichtigen: Ich hab eine komplett fertige Zustandsschätzung in Matlab/Simulink fertig. Verarbeitet wird 3AchsBeschleunigung, 3AchsDrehrate, 3-Achs-Magnetfeld, Höhensensor, GPS, anpassung kein Problem, doppelte Sensoren kein Problem Einbauposition von allen sensoren durch transformation berücksichtigt. nichtlineare modellgleichungen kein problem, motor-sollwerte für schwebeflug können mitgeschätzt werden, stochastisches störspektrum durch luftströmung etc. mit drin und oben drauf leg ich noch ne modellbasierte fehlererkennung falls gebraucht OK und jetzt die Nachteile, die alles wieder zur nichte machen :-) das läuft mit dem unscented Kalman-Filter pro schritt muss zweimal ne choleskyzerlegung mit 2n+1 (n=dimension des zustandsvektors) durchgeführt werden. dazu noch matrixinversionen also Householdertransformation in dem fall glaube ich (das macht matlab ja so prima allein) Könnt ihr ja mal überlegen. Sonst wär vielleicht extendet kalmanfilter eher das richtige, wobei man sich da ja wieder n kopf um die ableitungen (jakobi-matrix) machen muss. das ist in obiger variante ja nicht nötig. und n looping fliegen ist da von der näherung der gleichungen auch nicht drin (schätz ich mal so ohne gewähr, müsst ich mal nachrechnen) wenn erste variante fast laufen würde gibt es noch die wurzelimplementierung, die hat vom rechenaufwand die ordnung des erweiterten kalmanfilters, jedenfalls nach der theorie. dazu wäre dann rank 1 update der cholexkyzerlegung und qr-faktorisierung zu implementieren. Hoffe den Entscheidungsprozess in Sachen Hardware nicht unnötig angeheizt zu haben.
Und welche Rechenleistung brauchst du für deine Monster-Mathe?
Hallo, ich hab mit dem EKF und dem Bierman-Algorithmus recht gute Erfahrungen gemacht, vor allem was die numerische Stabilität betrifft. Unter Umständen hatte ich sogar bei double-Werten in MATLAB Probleme, wenn man irgendwelche Konstanten mitschätzt. Zu der Rechenzeit kann ich leider nix genaues sagen, ss ist pro Rechenschritt eine Cholesky-Zerlegung notwendig, jedoch keine Matrixinversion oä. Von daher geh ich mal aus, dass ein einigermaßen potenter µC das ganze schon schaffen sollte, bei aktzeptabler Updaterate (200-500Hz). MfG
Abdul K. schrieb: > Und welche Rechenleistung brauchst du für deine Monster-Mathe? Das kann ich nicht sagen, da ich nicht weiß, wie ich das abschätzen soll. Kann mir das jemand sagen? Ich schau auch mal, ob da jemand über Erfahrung berichtet.
bekommste das Model in ne S-Function? dann könnte man das Model in Realtime laufen lassen und anhand der CPU leistung aussagen Treffen, aber da wäre ein Intel Atom Board wohl besser als ein kleiner Arm oder so was wie Pandaboard. Welche Ordnung haben eure Systeme? Ich hatte mal irgend wo n Zusammen hang zw Ordnung und benötigter Recheleistung gesehen. Kalman mit eingerechnet. Also n EKF mit optimierungen würde ich nem Cortex M3 mit 120MhZ zutrauen. Das er da einen Regelzyklus von 100Hz und größer schafft. Ist die Frage was für einen Regelzyklus benötigen wir? Das Modell Von Tobi ist schon für n 3GHz QuadCore aber nix für n Kleines UAV N IntelAtom, oder n dualCore Onap wäre da das besste, aber dafür musst du erst mal die Perepherie treiber bauen, oder dem das alles über n Buss rein schaufeln MfG Tec
Hm. Jede Biene kriegt das mit eine paar mW hin. Da müßt ihr noch einiges zulegen ;-)
Witzbold, ne Biene ist eigenstabil, n Quadrocopter nicht nur mal so....
Cortex M3 FOC MotorControl: Schaut Euch mal die Toshibas an. FOC mit Hardwarebeschleuniger. Die machen mit dem 80MHz Cortex zwei Motoren FOC gleichzeitig und haben noch Luft.
Aber alles was ich so gesehen habe bisher im netz musst du die Bibliotheken kaufen. wie bei ST die machen Auch Dual Motor FOC, aber die Sw oder ne App note haben die nicht da. Oder Weißt du wo ich die finden kann? MfG Tec
@Tec Nologic Wenn Du mich meinst, soweit ich weiß ist die Software frei, auch im Projekt kostenlos verwendbar. Appnote vermute ich mal auf der Toshiba Webseite. Vllt mal nach > toshiba cortex foc < suchen.
Ich bin da gerade am gucken, sieht ganz gut aus.
naja, da gibts zwar n Beispiel, aber da portiere ich lieber was Von Microchip Toshiba hat da kein wirkliches Library. Den Code muss ich erst mal gründlich aus einander pflücken.
Also die Nummer mit den Sensoren ist kein Problem. Die Nummer mit dem rechnen schon. Bei der Power die benötigt wird sollte es ggf doch ein OMAP L137 oder ein FPGA werden. Die Matrix multiplikationen tun halt doch weh ... Gibt aber wohl auch Prozessoren die in Hardware gegossene Matrix Mathe haben (weiß nich wie ichs besser ausdrücken soll grade :D ). Schaltplan und Layout übernehm ich gern :) Edit: Toshiba hat super Motor Controller. Aber: ich denke ein atmega 8 pro motor würds schon tun, die müssen ja nix machen auser PWM
Naja, wenn denn richtig, Dann kommt auf den atmega8 ne park und clark Transformation zu ein Beobachter für den Drehwinkel und die Geschwindigkeit 2 Strom regler für den Strom in D und Q richtung und zum Spass ein Drehzahl regler. und damit ist der aufjeden Fall überfordert, bei einem Regel zyklus kleiner 50µs. Des halb der dsPic, bzw n Cortex. Für den dsPic nehme ich gerade an1078 von Microchip. MfG Tec
Muss mans bei den Motoren so übertreiben? Reicht nicht I-Regler, Überstrom-Schutz und Drehzahlregler? Standard halt ... Beim Hauptprozessor seh ich erhöhten Aufwand ein, weshalb ich für die Mathe ein FPGA und für das Regeln einen ARM angedacht hatte. Oder einen OMAP, der könnte DSP und ARM
Mir fällt grad ein das die Entwicklungsumgebung vom OMAP etwas ... komisch ist. Weiß nicht ob die umsonst ist oder teuer oder ... ich weiß es nicht. Damit fällt der an und für sich schon wieder raus. Was ich eben entdeckte: http://focus.ti.com/docs/toolsw/folders/print/c6flo-dsptool.html?DCMP=dspc6ezflo-110427&HQS=Tools+BA+dspc6ezflo-bhp-sw#2 Für die C6000er DSPs - wie geil isn das?
So einen Standardregler habe ich schon mal mit ne atmega48 aufgebaut. Aber das ist halt standard. Und von der FOC verspreche ich mir höhere Effizienz und mehr Dynamik. Daher der Aufbau.
Ja aber für den Motor tuts ja erstmal was einfaches. Der muss ja am Ende wirklich nur Drehzahl machen ...
Die aber uch schnell ändern, ist aber auch worsch ich mach das ding jetzt fertig. Das portieren auf den Cortex mache ich dann wen ich mal ne Anwendung habe.
@Tec Nologic Bezogen auf das was Du für den Toshiba gefunden hast, welche Art von Lib erwartest Du ? Welche Aufrufe sollten das sein ?
Naja, er wartet hatte ich so was wie das Motorcontroll Lib von ST. Was ich so gesehen habe, hat der TMS360 von Toschi eine Vectoreinheit als Perepherie drin. Der Code als solches ist aber recht bescheiden dokumentiert. Was mich etwas abschrekt das Nachzu voll ziehen da bin ich schneller wenn ichs selbst schreibe. Die Variante mit der Lib von St wäre für mich verlockend aber die Lib ist ja nicht frei zu bekommen. Ich werde jetzt erst mal das mit dem dspic machen, das Board halte ich gerade so das ichs auch an men STM3210B anschließen kann. Von dem her sollte der Code von MC über portierbar sein. mal sehen. @Der Fuchs Hast du schon mal eine selbst FOC implementiert? MfG Tec
In der ZIP unten ist der Beispielcode zum Video... http://www.gerold-online.de/cms/wheelie/mein-wheelie/kalman-filter.html
Günter schrieb: > In der ZIP unten ist der Beispielcode zum Video... > http://www.gerold-online.de/cms/wheelie/mein-wheelie/kalman-filter.html Danke für die Info, es ist hilfreich zu sehen, wie man es mit der Drumherum-Implementierung lösen kann. Inhaltlich hoffe ich jedoch, dass wir um einiges über diese Lösung hinaus kommen. Wenn ich richtig mitgeschnitten habe, steht ein 3-Achs-Magnetfeldsensor zur Verfügung, welcher tatsächlich Informationen über die Lage im Raum ausgibt. Aufgrund dessen muss nicht mehr von der Behauptung ausgegangen werden, dass sich das Fahrzeug unbeschleunigt in waagerechter Lage befindet. Als Folge dieser falschen behelfsmäßigen Annahme kann man im Video sehen, dass bei der Seitwärts-Beschleunigung (seitwärts hin und her schütteln) ein falscher Winkel angezeigt wird. Setzt nun eine schnelle Regelung auf diese Informationen auf, wird sie versuchen, den Winkel auszuregeln. Auf Grund dieser Bewegung könnte wieder eine falsche Winkellage resultieren, sodass es noch schlimmer wird. In ungünstigen Fällen kann die zu starke ungewollte Rückkopplung also zur Instabilität des Gesamtsystems führen. Je nach Stärke dieser Effekte kann das alles für den Geradeausflieger uninteressant sein. Für den Einsatz als Kunstflugzeug ist aber eine Überlegung berechtigt.
Moin Tobi, bei dem Magnetfeldsensor musst du bedenken das du Motoren in der nähe hast. Die können schwankungen von +-5° ausmachen, da muss man mit dem Einbau sehr vorsichtig sein. So z.b. die Motorregler und Motorleitungen unter dem Rahmen verlegen, sowie den Akku. Oben auf dem Rahmen sollte dann lediglich 3V3 Elektronik sitzen ohne Leistung. MfG Tec
Hallo Tobias, gut beobachtet, jedoch würde ich nicht gleich soweit gehen und den Effekt mit nur EINER Theorie zu erklären: -ist meine Hand beim Schütteln immer waagrecht? -ist der Gyroanteil im Filter zu klein? -welche Fehler macht der eingesetzte Gyro-Sensor direkt ohne Filter? -von welchen Beschleunigungen und Geschwindigkeiten reden wir? es ist auch zu sehen, dass der Winkel der Platine etwas verstärkt auf den künstlichen Horizont geht, der Fehler wird also größer angezeigt als er ist. Durch das Abstellen der Platine zwischendurch wollte ich zeigen, dass sich die Fehler eben nicht wie erwartet aufaddieren und erst langsam zurückgehen. Schau mal hier: http://code.google.com/p/sf9domahrs/ und hier: http://www.watterott.com/de/9-Degrees-of-Freedom-Razor-IMU-AHRS-compatible Gruß Günter
Tec Nologic schrieb: > bei dem Magnetfeldsensor musst du bedenken das du Motoren in der nähe > hast. > Die können schwankungen von +-5° ausmachen, da muss man mit dem Einbau > sehr vorsichtig sein. So z.b. die Motorregler und Motorleitungen unter > dem > Rahmen verlegen, sowie den Akku. Oben auf dem Rahmen sollte dann > lediglich 3V3 Elektronik sitzen ohne Leistung. Solche Informationen sind Gold wert, jedenfalls für mich :-) Selbst die statischen Abweichungen aufgrund magnetischer Materialien oder statischer magnetischer Felder sind ja für jede Lage im Raum unterschiedliche. Ich kenn das vom Magnetkompass aufm Boot, da hat man eine Deviationstabellen, wo man für jeden Kurs nachschauen muss, wie die Abweichung ist. Die Tabelle muss vorher genau ausgemessen werden. Bei bewegten Feldern wirds sicher noch viel komplizierter. Alle diese Störungen sind ja auch fernab von Gaußschem Rauschen und im Kalmanfilter kaum unter Kontrolle zu bekommen. Deshalb ist's perfekt, wenn man einen Plan hat diese Störungen klein zu halten! Günter schrieb: > gut beobachtet, jedoch würde ich nicht gleich soweit gehen und den > Effekt mit nur EINER Theorie zu erklären: > > -ist meine Hand beim Schütteln immer waagrecht? > -ist der Gyroanteil im Filter zu klein? > -welche Fehler macht der eingesetzte Gyro-Sensor direkt ohne Filter? > -von welchen Beschleunigungen und Geschwindigkeiten reden wir? > > es ist auch zu sehen, dass der Winkel der Platine etwas verstärkt auf > den künstlichen Horizont geht, der Fehler wird also größer angezeigt als > er ist. > Durch das Abstellen der Platine zwischendurch wollte ich zeigen, dass > sich die Fehler eben nicht wie erwartet aufaddieren und erst langsam > zurückgehen. > > Schau mal hier: http://code.google.com/p/sf9domahrs/ > und hier: > http://www.watterott.com/de/9-Degrees-of-Freedom-Razor-IMU-AHRS-compatible Natürlich hast du Recht. Es spielen sehr viele Dinge in das Ergebnis rein. Und genau genommen hängt auch alles irgendwie miteinander zusammen. Und es ist eine sehr gute Leistung das alles so zum laufen zu kriegen, wie du es hin bekommen hast. Ich würde das nicht hin kriegen. Ich wollte lediglich EINE, meiner Ansicht nach sehr interessante Verkoppelung heraus stellen, die man im Auge behalten sollte, falls es später zu Problemen kommen sollte. Liebe Grüße Tobi
Ich hatte die algorithmische Seite letztes Jahr betrachtet: http://forums.openpilot.org/topic/1043-sigma-point-kalman-filters/ Es gibt eine Handvoll optimierte Sigma Point Kalman Filter, die mit weniger als 2n+1 Punkten auskommen Diese Vertreter kommt meist mit n+2 Punkten aus, jeder kann sich jetzt ausrechnen was der Unterschied bei 20+ States und ner Komplexität von O(n³) ausmacht. Hauptnachteil ist jedoch dass sie nur mit additiver Noise umgehen können. Selbst mit dieser optimierten Variante hat man aktuell keine Chance dies auf einer embedded CPU auszuführen mit ~500Hz Updaterate bei ausreichend Leerlauf. Vielleicht auf einem cortex-m4 mit hw fpu (wenns denn mal eine geben wird) sind dann 100Hz oder so möglich.
chris schrieb: > Hier noch was zur Anregung eigener Ideen: > http://www.youtube.com/watch?v=3CR5y8qZf0Y Die benutzen externe Kontrollsysteme, wahrscheinlich eins dieser super-teuren Kamerasysteme um die Position der Copter zu erfassen, das sieht man an den netten leuchtenden Kugeln am Rahmen der Copter. Da gibt es tonnenweise solche Videos, inkl. Copter die durch Hula-Hoop-Reifen fliegen und so. Ist nicht wirklich zu vergleichen mit dem Problem des TE.
Die Lagerregelung selbst findet sich mit Sicherheit im Quadrocopter und verwendet die internen Sensoren. Die Positionsregelung dürfte tatsächlich über Kameras gemacht sein.
Da wäre ich mir wie gesagt nicht so sicher, die meisten Paper auf der dazugehörigen Seite http://www.idsc.ethz.ch/Research_DAndrea/FMA führen nur das VICON Kamerasystem auf, ich hab auf die Schnelle keine Referenzen zur Nutzung von onboard Sensoren für Lageerkennung gefunden. Sind ja auch nicht notwendig, das Vicon system kann das locker ohne.
Das MIT die ETH Zürich und andere machen die Regelung der Quads mit den Cameras, die Quads haben nur eine einfache Lagestabilisierung. Mehr brauchen die auch nicht. OpenPilot sieht sehr interessant aus. @haldir Was bietet Das Board für Schnittstellen zu den Motorregelern? nur TurboPWM? MfG Tec
Tec Nologic schrieb: > OpenPilot sieht sehr interessant aus. > @haldir > > Was bietet Das Board für Schnittstellen zu den Motorregelern? nur > TurboPWM? Ich bin da ehrlich gesagt nicht mehr so aufm laufenden, ich bin bei dem Projekt nicht involviert, die alte OpenPilot-HW (die jetzt als INS Pro Version irgendwann mal laufen wird) war interessant, das CopterControl-Ding ist nur eine minimal Version mit Komplementärfilter und keinen weiteren Tricks, ich denke die wird nur PWM können. CopterControl ist laut den Jungs im rcgroups-Forum ganz nett als reine Fun-Plattform, also ohne GPS etc. Ich hatte meine Analysen zu den diversen SPKF dorthin gepostet, weil die für die originale HW einen EKF mit rund 15 Zuständen gebaut hatten/haben.
Hallo beisammen, um zu zeigen, dass unser wunderbares Projekt noch im vollen Gange ist (ich hoffe doch bei euch auch) möchte ich mich mal wieder zu Wort melden. Vielen Dank für den bisher eher unkommentierten Beitrag: Haldir schrieb: > Ich hatte die algorithmische Seite letztes Jahr betrachtet: > http://forums.openpilot.org/topic/1043-sigma-point... > > Es gibt eine Handvoll optimierte Sigma Point Kalman Filter, die mit > weniger als 2n+1 Punkten auskommen > > Diese Vertreter kommt meist mit n+2 Punkten aus, jeder kann sich jetzt > ausrechnen was der Unterschied bei 20+ States und ner Komplexität von > O(n³) ausmacht. Hauptnachteil ist jedoch dass sie nur mit additiver > Noise umgehen können. > > Selbst mit dieser optimierten Variante hat man aktuell keine Chance dies > auf einer embedded CPU auszuführen mit ~500Hz Updaterate bei ausreichend > Leerlauf. Vielleicht auf einem cortex-m4 mit hw fpu (wenns denn mal eine > geben wird) sind dann 100Hz oder so möglich. Das war in der Tat eine gute Anregung. Ich bin dabei einen entsprechenden Algorithmus zu schreiben bzw. die Verfahren besser zu verstehen. Mein momentaner Favorit ist das Square-Root Spherical Simplex Unscented Kalman Filter. Einigen Artikeln zur Folge ist der Rechenaufwand geringer als der des extendet Kalmanfilters, die genauigkeit jedoch besser. Ein echtes Wunderkind also :-) Die Implementierung der Modellgleichungen ist natürlich genau so prima einfach wie bei den anderen Partikelfilter-Varianten. Kein Jakobimatrix ausrechnen notwendig. Wie der Rechenaufwand in unserem Fall ausschaut hängt sicher von mehreren Faktoren ab. > Hauptnachteil ist jedoch dass sie nur mit additiver Noise umgehen können. Ich glaube da liegst du nicht ganz richtig. Wie ich z.B. "The square-root spherical simplex unscented Kalman filter for state and parameter estimation (Xiaojun Tang; Xiaobei Zhao; Xubin Zhang; in Signal Processing, 2008. ICSP 2008. 9th International Conference...) entnehme, ist auch die Erweiterung des Zustandsvektors möglich. Jedoch vervielfacht sich dadurch natürlich die Länge des Zustandsvektors und der Rechenaufwand nimmt entsprechend zu. In einem Punkt kann ich noch etwas Unterstützung gebrauchen: Ich bin bisher noch auf der Suche nach einem geeigneten C/C++ äquivalent für die Matlab-Funktion "cholupdate" damit es dann später auch mit der Implementierung klappt. In Sachen QR-Zerlegung (Householdertransformation) und Least-Mean-Square mit Pivotisierung sieht die Verfügbarkeit glaub ich besser aus. Haldir, wie hast du das damals gelöst? Ich hab bisher "CHOLMOD: a sparse Cholesky factorization and modification package (http://www.cise.ufl.edu/research/sparse/cholmod/)"; gefunden. und davon speziell die funktion "ldlupdate" aber bisher konnte ich noch nicht so recht das verhalten von "cholupdate" nachbilden. Vielleicht muss ich mich da auch nur noch mal besser rein fuxen. Wie schauts bei euch denn so aus? Gibts was neues? Liebe Grüße, jetzt grad von DTU/Lyngby (Kopenhagen) Tobias
Hallo Tobias, bzgl. additives Rauschen bei SRSSKF (Square-Root-Spherical-Simplex Kalman Filter), schau dir mal Gleichung 2 im Paper, dass du zitierst hast, an: w_k = w_k-1 + v_k-1 d_k = g(x_k, w_k) + n_k in beiden Fällen hast du additives Rauschen. Ich hab zumindest keine Formulierung für den allgemeinen Fall gefunden, für SR-UKF existiert der im Originalpaper von van der Merwe. Für den üblichen INS Fall ist das auch egal, da wir da nur additives Rauschen haben, den einzigen Fall den ich mit nicht-additiven Rauschen kenne ist die Kombination mit GPS inkl. Zeitkorrektur (GPS Signalverarbeitung), das lässt sich aber dann durch tightly-coupled GPS Integration lösen (also einen großen Zustandsvektor mit den Daten der einzelnen GPS-Satelliten). Das wäre die ultimative Lösung, wir reden dann aber von 40+ Zuständen und da bekommt sogar nen moderner PC seine Probleme.. Wegen Cholupdate: die Eigenlib hat mittlerweile Funktionen dafür. Inwiefern ein choldowndate (vgl Aufruf von cholupdate mit letzten Parameter == -1) geht weiß ich nicht, ich hab die SR-Versionen nur tlw. angeschaut, einfach weil Square-Root gescheit nur mit FPU möglich ist. Ansonsten gibts nen C++ port der cholupdate Routine im SR-UKF Quelltext von david sachs, mußt ggf. mal googlen.
> Kein Jakobimatrix ausrechnen notwendig.
Was aber auch nicht so aufwändig ist.
Dieter schrieb: > Was aber auch nicht so aufwändig ist. Aufwändig vielleicht nicht, aber numerisch ziemlich kostenintensitiv und von der numerischen Stabilität problematisch. Gerade auf Prozessoren auf denen mit fixed-point oder mit abgespeckter FP-Genauigkeit das ganze berechnet werden soll, will man das soweit wie möglich vermeiden. Die unscented Varianten will man ja auch weil er weit besser mit nicht-linearen Zustandsübergangsfunktionen umgehen kann als EKF.
Mal meinen aktuellen Wissensstand zusammengefasst: 1. Welche Sensoren sind interessant - 3 Gyros, 3 Accelerometer, 3 Magnetometer, 1 Barometer 2. Kein GPS? - Doch GPS für die eigentlichen absoluten Messwerte, 10Hz+ Rate 3. Brauch man wirklich alle Sensoren? - Je nach welchem Paper man glaubt, braucht man das Barometer nur beim Start, mittlerweile gibt es aber Barometer mit einer relativen Auflösung von 15cm, also mindestens fürs Höhehalten und Landen auch ganz ok - Bei Magnetometern das gleiche, je nach wem man glaubt gibts Annahmen von komplett nutzlos bis perfekt, kommt auch auf die GPS-Updaterte an 4. Wie kommt man auf 20+ Zustände für Zustandsvektor? - Position, Geschwindigkeit, Quaternion, ein Bias pro Achse pro Sensor Vergleichsweise einfach beschrieben wird das hier: http://www.iasi.cnr.it/reports/R8008/R8008.pdf (ohne Barometer) 5. Wie häufig muß man das ganze machen? - Für einen Quadkopter mindestens 400 Schätzschritte pro Sekunde und 10Hz Messschritte über GPS 6. Kann man das ganze nicht abkürzen? - In http://robolab.cse.unsw.edu.au/conferences/ICRA-2011/data/papers/0288.pdf hat das nen Chinese gemacht, m.M.n kompletter Unfug die Biase wegzulassen, genau dass ist eigentlich der interessante Teil, die ändern sich während der Laufzeit und die kann man gut schätzen. 7. Wie lang dauert das nun wirklich? - Im Paper vom Chinesen hat der für SR-UKF (== 2n+1 Zustände, also 21 Zustände) 6 Sekunden für eine Messwertberechnung auf nem Standard Cortex-M3 72Mhz gebraucht. Nehmen wir mal an seine Werte sind einigermaßen korrekt, der Rest vom Paper ist wie gesagt ziemlicher Müll. - Ich habs selber mit einem 20 Zustands SOUKF (kein SqRoot) pro Runde auf nem 120Mhz Cortex-M3 rund 10 Sekunde gebraucht (nicht optimiert, nur zum Testen), seine Werte sind wohl einigermaßen OK. - Auf einem E8500 braucht man für einen 20 Zustands SOUKF rund 0.15s für 1000 Durchläufe, der schafft rund 12 GFLOPS. 8. Wieso ist das so langsam? - Ein Großteil der Operationen sind Floating Point und die Cortex-M3 haben keine HW-FPU - Wenn man http://www.nxp.com/documents/application_note/AN10902.pdf glauben schenkt liefert eine FPU einen Speedup bei einem ähnlichen ARM-Prozessor von Faktor 5 - Wenn man wirklich Ahnung hat kann man die Berechnungen auch auf fixed-point umstellen, wie schnell dass dann wird kann ich nicht wirklich sagen. Annahmen zur Anzahl der Operationen befinden sich hier: http://www.hindawi.com/journals/mpe/2009/507370/ (Tabelle 3 weiter unten) - Der geht von rund 6000 Mult/Add Operationen für einen Länge 4 Vektor aus. Grob geschätzt bewegen wir uns also bei 1 Mio für einen Länge 20 Vektor. Selbst in der Theorie kommen wir damit nicht auf 400Hz auf einem z.B. Cortex-M4f mit 160Mhz. 9. Fazit - Selbst mit einem Cortex-M4F glaube ich nicht, dass wir mit SR-UKF und dem 20 Zustandsvektor eine Updaterate von 400Hz erreichen werden. Gibt aktuell auch keinen aufm Markt. - Ich denke so 50Hz sind vielleicht mit FPU und ggf. Fixed-Point möglich für jemanden der sich gut mit der Mathe und der Plattform auskennt. - Wenn man solch komplexe Algorithmen einsetzen will, muß man sich im Bereich Cortex-A9/15 umsehen oder noch eher im Bereich der Intel Atom Prozessoren
Dieter schrieb: >> Kein Jakobimatrix ausrechnen notwendig. > Was aber auch nicht so aufwändig ist. Das kannst du so pauschal sagen, für beliebige Modellgleichungen?? Meinen Respekt!! Hätte mich ja schon mal interessiert, mit welchen Tricksereien du das für komplizierte und eigentlich nicht ableitbare Funktionen hin bekommst. Haldir schrieb: > Hallo Tobias, > bzgl. additives Rauschen bei SRSSKF (Square-Root-Spherical-Simplex > Kalman Filter), schau dir mal Gleichung 2 im Paper, dass du zitierst > hast, an: > > w_k = w_k-1 + v_k-1 > d_k = g(x_k, w_k) + n_k > Hallo Haldir, da hast du Gleichung (2) aus Xiaojun Tang, Xiaobei Zhao, Xubin Zhang: The Square-Root Spherical Simplex Unscented Kalman Filter for State and Parameter Estimation zitiert. Das ist aber doch nur eine spezielle Variante zur Parameterschätzung (so etwa von der Art konstanter Vergessensfaktor). Die allgemeine Modellgleichung ist Gleichung (1) x=f(x,u,v) y=h(x,u,n) womit doch ein beliebiges Rauschmodell möglich ist. Ich habe jetzt in Matlab genau einen solchen square root spherical simplex augmented state covariance unscented Kalmanfilter in einer Version 0.0.1 zum laufen bekommen. > auch egal, da wir da nur additives Rauschen haben das denk ich auch, deshalb werd ich jetzt noch eine additive noise Version bauen. Das verkürzt den Zustandsvektor ja um einiges und könnte noch etwas schneller sein. Danke für die Infos zur Implementierung. Da werd ich demnächst noch mal einen Anlauf starten. Liebe Grüße aus Dänemark Tobias
Hallo Tobias, ok, kann sein das dort auch der allgemeine Fall besprochen wird, ich hab soviele Paper zu dem Thema gelesen und irgendwann wirds wirr ;) Beim Design in Matlab ggf. schon gedanken über den Einsatz auf Fixed-Point oder Floating-Point machen. Nachträglich ist das ggf. etwas komplex. Ich hab leider keine aktuelle Matlabversion mit den ganzen Tools zur fixed-point Konvertierung.
Hallo in die Runde, ich möchte euch meine ersten Testergebnisse nicht vorenthalten... aber dazu gleich vorweg sagen: sie sind sicher nicht sonderlich aussagekräftig und es ist wenig sinvoll darauf eine Diskussion aufzubauen. und ich werde mich zu diesem Zeitpunkt auch nicht mit der Erzeugung aussagekräftiger Daten zur Codegeschwindigkeit bemühen sondern erst mal überhaupt klar kommen, also hier bitte erst mal keine Verbesserungsvorschläge dazu sondern für später merken, wenn ich darauf zurück komme. Eine Aussage ist aber evtl über das Verhältnis der Aufwendigkeit der Berechnung möglich. Warum das srukf (square-root implementierung des unscented Kalmanfilters) langsamer ist als das normale ukf weiß ich grad nicht. Bei den letzten beiden in der Liste hab ich die Implementierung etwas geändert. Statt einen Functionhandle zu übergeben, hab ich da die Modellfunktion mit in die Filtergleichungen geschrieben. Das scheint irgendwie schneller zu sein. Ist dann aber Matlab-spezifisch. Auf jeden Fall sind dann die letzen beiden aber wieder vergleichbar. Das ist einmal die augmented version des square root spherical simplex unscented kalmanfilters (mit erweiterter Kovarianzmatrix der Zustandsschätzung) und als letztes das square root spherical simplex unscented kalmanfilters mit additivem Rauschen. ekf ist das extendet Kalmanfilter, das hier ungerechter weise bevorteiligt antritt, da ich dummerweise ein lineares modell zum testen genommen habe und deshalb gar keine ableitung jakobimäßig berechnet werden muss. srukf 2.736 s ukf 2.701 s srssukfaug 1.757 s ekf 0.699 s srssukfaugreduc 0.646 s srssukfad 0.402 s Liebe Grüße aus Lyngby Tobias
Interessant wäre trotzdem eine Aussage zur Anzahl der Sigmapunkte bzw. Anzahl der Zustände. Bei mir war btw der UKF auch schneller als der SR-UKF. In der Literatur ist das auch so dokumentiert.
Das hier ist ja vllt. ein wilder Haufen Philosophierer !! Jakobi, CortexM4, FPGA, Messreihen die sekundenlang dauern ... alles lachhaft, was ihr hier schreibt und umzusetzen versucht. Der Original Mikrokopter läuft ja bekanntlich mit dem ATmega644 und das bei gerademal 20Mhz und setzt doppelt so viele Funktionen aus zig verschiedenen Sensoren um, als ihr hier geplant habt, unter anderem den Kalman Filter. Der Sorcecode dazu ist auch noch komplett offen und gut lesbar. Naja, aber hauptsache mal dumm geredet, nichts geschafft !!
Witzbold, die Mikrocopter Jungs haben nur n Arm9 für ihre Navigation drauf nur so nebenbei, zum anderen gehts ums prinzip aktuelle Regelungtechnik umzusetzen. Die MK Leute setzen das alles recht simpel um, klar es fliegt. Aber darum geht es hier nicht. MfG Tec
Der Chef schrieb: > Das hier ist ja vllt. ein wilder Haufen Philosophierer !! > [...] > Naja, aber hauptsache mal dumm geredet, nichts geschafft !! Ich denke ich spreche da auch im Namen der anderen Diskussionsteilnehmer: Derartige überhebliche und herablassende Beiträge sind hier nicht erwünscht! Wir haben diesen Tread eröffnet, mit dem Ziel, hier voneinander zu lernen. Wenn du das auch tun möchtest kannst du gerne mitmachen, aber nicht so. @Tec Da stimme ich überein. Meine Anerkennung, da noch mit aller Ruhe sachlich drauf zu antworten. Ich hoffe wir werden in Zukunft keine Energie in die Beantwortung derartig provozierender Beiträge stecken müssen, die kann an anderer Stelle bestimmt sinnvoller genutzt werden ;-) MfG Tobi
Naja Tobi, wenn man sachlich bleibt, machts dem anderen meist keinen Spaß mehr zu stänkern. Und ich kenne die Sprüche von wegen "das reicht doch", das höre ich immer wieder, wenn einer hört das ich mit feldorientierer Regelung meine Motoren steuern möchte. Das geht einfach nur darum weil michs interessiert ob das was bringt, wenn nicht hab ich immer noch was gelernt, und dafür ist das nun mal Hobby. MfG Tec
Tec Nologic schrieb: > wenn man sachlich bleibt, machts dem anderen meist keinen Spaß mehr zu stänkern. Heehee, haste auch Recht, etwas Gestänker treibt die Diskussion an, wie man hiermit prima feststellen kann.
Hallo Zusammen, waere bereit ein Mezzanine-board mit der genannten Sensorik fuer das STM32F4-Discovery Board zu realisieren. Das Ganze kann dann unter einer 'Creative Commons License' jedem verfuegbar gemacht werden. Als EDN Tool wuerde ich gerne Eagle von CADSOFT verwenden. Bei der Implementierung der SW kann ich auch gerne helfen. Passend zum F4 schlagen ich den LSM330DL Gyro- und Accel-Sensor vor. Ein Vorschlag fuer passendes Magnetometer fehlt mir noch. GPS koennte man integrieren, aehnlich http://www.sparkfun.com/products/9133 Aber welche HW nun zur Anwendung kommt koennen wir diskutieren. Ich kann alle Design-steps vom der Idee zum Schaltplan bis zur finalen HW in Prototypen Stueckzahl realisieren. Die Kosten fuer die initiale HW muesten wir uns teilen (i.W. Sensor chips, PCB, etc). Was haltet Ihr davon? Gruss Bodo
Moin Bodo, Klingt grundsätzlich interessat. Bei mir liegt das Projekt wegen Zeitmangel aber erst mal brach, aber was sich einrichten lässt steuere ich gern bei. An die F4 dachte ich auch schon als ich das Eval gesehen habe. Als Lagesensoren würde ich noch die MPU6000, ITG3200 in den raum werfen. Als Magnetometer tots ein 3d Kompass von Honeywell HMC6352 oder ähnlich. Interesse besteht von meiner Seite. MfG Tec
Vorschlag: o LSM330DL Beschleunigung, Winkelbeschleunigung o LSM303DLM Beschleunigung, Richtung Um bei ST zu bleiben. Fehlt noch Temperatur und Luftdruck, MicroSDCard Slot via SDIO und Temperatur zwecks Kompensation. Gruss Bodo
Moin Bodo, Hab gerade mal die Datenblätter der Sensoren Überflogen sieht super aus. Ich muss sagen ST hat da einiges gemacht auf dem Mems Sektor. Um bei der Temperatur bei ST und digital zu bleiben sage ich mal STDS75. Mir stellt sich dabei aber die Frage welche Genauigkeit wir in der Temperatur benötigen? Beim Luftdruck hat ST ja nix, auch da stellt sich mir die Frage welche Genauigkeit benötigt man? Höhe auf 10cm auf lösen? Wenn man bei den µKopter Leuten guckt machen die das mit dem MPX4115A 0 m | 1013,25hPa | 4.08V 500 m | 954,61hPa | 3.82V 0,2V Differenz bei 500m, geschätzt komst du damit bei einem 10Bit ADC auf ca. 0,5m pro LSB. Mit 12Bit bist du dann bei 0,125m pro LSB das wäre schon brauchbar, aber du musst die 12Bit auch messen können. Hier im Forum wird der SCP1000 angepriesen, mit 8cm Auflösung was schon super wäre. Noch besser wäre der EPSON XP-6000CA der soll auf 3cm Auflösen und ist speziell für Navigationsanwendungen gedacht. Problem wird dabei wohl eher die Beschaffung.Digi-Key hat den z.B. nicht. µSD ist klar für Logs und Einstellungen usw. Die Möglichkeit der Drahtlosen Datenübertragung wäre noch interessat. WLAN scheidet für mich aus auch wenn der F4 ne MAC usw hat, n HTTP Server mit SSI und CGI kostet unnötig rechenleistung, das könnte hößstens ein Weiterer F2 oder so über nehmen. Also würde ich sagen, sollten wir eine Leistungsfähige Schnittstelle zu ein Eränzungs Board vorsehen. SPI/CAN oder ähnliches. Schnittstelle für die Motortreiber, wäre TurboPPM da gibts viele Regler für, I2C, oder für Später CAN. Nur mal so einweinig Morgendliches Brainstorming. MfG Tec
Koennen wir den stm32f4 (Discovery Board) als Platform fuer die ersten Schritte voraussetzen ? ... dann waere vielleicht folgende Vorgehensweise angebracht ... Ich fertige ein PCB-Nutzen mit meinetwegen 3x4 Breakout-Modulen an. Darauf sollen all jene Sensoren realisiert sein die in Frage kommen, manche mehrfach, manche einzeln. Ich setze hier voraus das Sensor Pretest abseits des Labordesktops notwendig sind. Die Module werden notwendigerweise den mechanischen Erfordernissen angepasst, d.h. klein, meinetwegen quadratisch mit jeweils drei M2.5 Bohrungen fuer die mechanische (justierbare) Fixierung. Accel, Gyro und Magnetometer sitzen immer im Zentrum des PCB's. Da es (fast) alles Sensoren mit digitalem Interface sind (TWI/I2C und SPI) koennten sie stapelbar ausgelegt sein. Ist bei I2C kein Problem, bei SPI gibts etwas Einschraenkung. Jedes Modul hat einen Temperatursensor und jedes Modul kann zusaetzlich durch eine leicht herstellbare Blechkappe (Kupferfolie) gegen elekrische (E) Felder geschirmt werden (H-Felder lassen sich davon nicht beeindrucken). Jedes Modul hat seinen eigenen LDO, um eine LowNoise Entkoppelung zu realisieren. (z.B. MIC53x9, >70dB PSSR@1KHz). Jedes Modul kann einzeln an jedem Micro betrieben werden der SPI oder I2C bereitstellt. I2C wird fuer die erforderliche Samplerate bei Accel und Gyro zu langsam sein, vermute ich. Hier sollten die Kalman Physik Experten sich aeussern, bzw. die Kopter Experten mit Flugerfahrung. Mit den Modulen kann dann gruendlich experimentiert werden. Aus den Resultaten wird spaeter die Essenz gebildet und danach kann in einem weiteren Schritt ein AHRS auf Basis des STM32F4xx realisiert werden. Als Rueckgrad (Nexus) des Systems wuerde ich den CAN Bus vorschlagen. Zusaetzliche Motorregler koennten per CAN adaptiert werden. Das macht das System skalierbar und flexibel variierbar. Mein Vorschlag. Also welche Sensoren finden Platz auf dem 1. 12'er Sensor-Modul-Nutzen ? LSM330DLTR Accel, Gyro LSM303DLHTR Accel, Compass/Magnetometer SCP1000 Pressure LPS001WP MEMS Pressure TMP105YZCR Temperature STDS75 Temperature ... Gruss bodo
Moin Bodo, Das Klingt nach einem sehr guten Plan das Ganze Modular zu halten finde ich super, für CAN bin ich auch. Auch wenn 1Mbit manchmal knapp werden können. Was die Sample Rate an geht ist alles über 50Hz ok, denn es fliegen genug mit reiner Modelbautechnik. Und die Arbeitet mit 50Hz Zyklus. Sample raten über 1kHz sind meiner Meinung nach Unnötig da das Trägheitsmoment des Kopters schnellere Änderungen verhindert. 1kHZ schaffen die Sensoren(MEMS) aber noch gut. Die Sache ist da her wie die Daten über einen Bus schnell weg zu bekommen. Und der Prozessor muss die Regelung in einem adequaten Zeitraum durch rechnen können. Diese Zeit ist aber sehr skalierbar. Wenn man bedenkt das eine einfache PID-Lageregelung in einem ATmega mit 20MHz laufen kann, dann können wir mit 170MHz und FPU wesendlich mehr machen. Ich wäre im Sinne der Modulatität für eine parametrierbare samplerate von 100Hz-500Hz oder vllt 1kHz. Dann wird das system für mehr Leute interessant, denn die Leute die sauber schweben wollen drehen den Regelzyklus etwas runter und aktivieren komplexere Regeler, die die 3D Kunstflug machen wollen, schalten einpaar Zustände an dem Regler weg und damit schnelleren Regelzyklus. Da sollte die HW nicht einschränken. MfG Tec
Moin, versuche gerade die Verfuegbarkeit der Sensoren zu klaeren. Dne SCP1000 schau ich mir gerade an. Der CAN Bus wird in professionalen, kommerziellen Systemen schon lange verwendet. Siehe stockflightsystems.com. Michael Stock hat einige Lagen Protokoll auf Basis des CAN realisiert. Sogar die NASA nutzt es. gruss bodo
Moin An das Protokoll von dehnen wird man wohl nicht kommen. Unsere FUs hier laufen auch alle mit einem Realtime Can im 1ms Zyklus also geeignet ist Can in jedem Fall. http://www.sparkfun.com/products/8161 das ist der SCP auf einem Breakout. Scheint aber abgekündigt zu sein. Der BMP180 ist aber interessant und digikey hat den auch. http://parts.digikey.com/1/parts/2461714-sensor-pressure-abs-bmp180.html Hab das DB mal angehängt. MfG Tec
Angehängte Dateien:
-
adxl345.jpg
170 KB
moin, der bmp180 ist interessant. Gyro/Accel Der L3G4200D ist bei Mouser direkt verfuegbar (>4900 Stk. ca. 7.70/1 €) -Three selectable full scales (250/500/2000 dps) -I2C/SPI digital output interface -16 bit-rate value data output -8-bit temperature data output -Package LGA-16 (4x4x1.1 mm) -Two digital output lines (interrupt and data ready) -Integrated low- and high-pass filters with user selectable bandwidth -Ultra-stable over temperature and time -Wide supply voltage: 2.4 V to 3.6 V Welche Drehraten sind beim Copter realistisch? Hier ein Bild von einem ADXL345 Accel Modul, welches ich vor kurzem fuer eine andere Anwendung realsiert habe. Nur um zu zeigen was moeglich ist. Gruss Bodo
MOin Bodo, das sieht doch gut aus. Bei den Drehraten kommt das ganz auf die Anwendung an. Schweben für Film und Foto, <45°/s für Kunstflug oder einfach schnelles Fliegen würde ich sagen so 300°/s, sobald es extremer wird Hängt das stark vom Kopter ab. (Schub zu Trägheitsmoment) Ich glaube aber nicht das ein "normaler" Kopter den Gyro auslastet. Nur wenn der Kopter gezielt auf Agilität getrimmt ist vom Aufbau her. (kurze Ausleger, und sehr viel Schub) Wenn der Sensor 200 - 2000 kann ist das also ok. Man kann ja Wählen wie beim Auto: gleiten - 200, sport - 500, kunstflug - 2000. Auf Grund des größeren Fehlers der höheren Messbereiche wird der Kopter nicht so ruhig liegen wie mit 200°/s aber das kann man auch als Vorteil sehen. Wenn man in der SW gezielt diese Modi vorsieht und die vllt später sogar automatisch je nach Flug input verändert. (automatische Bahnplanung mit plötzlichem Ausweichen) oder so was. Die Möglichkeit sollten wir auf jeden Fall lassen. Die billigen Standard Gyros die verscheiden Kopter Projekte so verwenden sind die Murata ENC-03 die machen 300°/s max. Wenn man sich ansieht was sich mit dehnen noch so alles messen lässt dann würde ich den 2000er Bereich so gar streicehn, bzw erst mal ver nach lässigen. Aber empfindlichere Gyros habe ich auch früher nicht gefunden. 200 ist da schon gut. MfG Tec
moin tec, wie koennen wir zusammen arbeiten, gib mir bitte mal deine email. bo-dot-gravert-at-gmail-dot-com mfg bodo
Moin Bodo, Ist die mail angekommen? MfG Tec
Super Sache, wenn das mit dem Daten loggen klappt. Danke für die Eckdaten, da kann man ja schon ganz gut was mit anfangen. Bin grad auf Linux umgestiegen und hab deshalb kein CAC-Programm mehr am Start um den Trägheitstensor näherungsweise zu berechnen. Kann das jemand anders grad aus dem Ärmel zaubern? http://www.idresshop.com/img/direction-cosine-matrix-imu.pdf Welchen Abstand haben die Sensoren eigentlich vom Masse-Schwerpunkt, kannst du das etwa abschätzen?
moin, das kommt ganz klar auf deinen Aufbau an. Die Vectoren vom Masseschwerpkt zu deinen Sensoren kann dir ohne Kenntnis des mechanischen Aufbaus niemand sagen. MfG Tec
Hallo an das Projektteam... Ich beschäftige mich auch schon seit einiger Zeit mit dem Gedanken sowas zusammen zu bauen, und hab' auch schon weiß Gott was alles im Web recherchiert. Was ich in der HW Ecke gefunden habe, ist folgendes: http://www.virtualrobotix.com/page/multipilot32f4-v3-0 http://www.virtualrobotix.com/page/vr-imu-10 U.U. findet sich dort das eine oder andere was ihr gebrauchen könnt, auch wenn es nur Anregungen sind... Die Gruppe um Roberto Navoni ist gerade dabei den bestehenden Source Code auf CHIBI OS (italienischen Real Time OS) zu portieren. Soweit ich mir den Source angesehen habe, verwenden die für die Navigation / Steuerung keinen Kalman Filter, geschweige denn einen UKF. Ich habe auch so den blöden Verdacht, dass wenn die mit der Portierung auf CIBI OS fertig sind, das Teil dann zwar noch fliegt aber keine Performance mehr für einen UKF übrig sein wird - aber das sagt mir nur mein Bauchgefühl ... Mein Posting erscheint auch erst jetzt, da ich Euch einfach nicht eher gefunden habe, und soll auch so verstanden werden, dass ich Eure geleitete Arbeit sehr schätze und mich auch darüber freue, dass andere in gleichen / ähnlichen Bahnen nach Lösungen suchen... LG Robert
Moin Robert, Der Multipilot32F4 ist interessant für uns, aber auf der F4 Schiene sind z.b. auch die Leute hinter http://www.xkopter.de/de-de/entwicklung/xkflightcontrol.aspx her. Deren IMU Board ist über teuert. Die Pololu IMU ist günstiger bei gleicher Leistung. Mit den F4 tut sich auf jeden fall einiges in dem Sektor. Wir werden mal sehen was da so kommt. MfG Tec
Hallo, bei mir geht es endlich weiter. Wer ist noch dabei? Ich habe in den letzten Wochen schon mit den Messdatenverarbeitung angefangen und könnte etwas Rückmeldung gebrauchen. Ich denke um etwas Ordnung zu haben und mit den Themen nicht durcheinander zu kommen werde ich gesonderte Threads auf machen und hier verlinken. Los geht es mit dem Magnetometer: Beitrag "Magnetometer kalibrieren"
Hallo Tobias, schön von dir zu lesen, ich bin auf jedenfall dabei! Meine Messdaten hast du bereits ausgewertet, ich bin beeindruckt, auch wenn ich noch lange nicht alles verstehe. Aber das wird schon, hoffe ich. :-) Holger
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.