Guten Tag miteinander, aufgrund meiner mangelnden Kenntnisse in Sachen Mikrocontroller bräuchte ich eure Meinung zu folgendem Problem: Ich möchte für meine Bachelorarbeit einen Mikrocontroller zwischen einen Empfänger eines funkferngesteuerten Modellbauflugzeuges und dessen Servos schalten. Die Signale des Empfängers, welcher 8 Servos ansteuert, habe ich ausgewertet (PWM von 1,2 – 1,8 ms). Nach meiner Recherche kann angeblich jeder I/O Port eines µC‘s solch ein Signal empfangen/ausgeben (mit entsprechender Programmierung). Ich habe deshalb an einen ATmega gedacht. Die Frage ist wie groß die C-Programme werden, um PWM-Signale aufzunehmen, zu bearbeiten und an die Servos auszugeben (danach richtet sich ja die Speichergröße des µC‘s)? Es sollte auch noch entsprechend Platz nach oben hin offen sein, um eventuell einen Bahnregler umzusetzen (Träheitsnavigationssystem, Potis an den Servos, Fahrtmesser sind vorhanden). Weiterhin würde ich gerne wissen, welches Entwicklungsboard ihr empfehlen könntet (muss lediglich die Anschlüsse bereitstellen und eine Schnittstelle zwecks Programmierens zum PC haben)? Vielen Dank im Voraus
32kB reichen mit viiiiiiel Reserve. Georg B. schrieb: > Weiterhin würde ich gerne wissen, welches Entwicklungsboard ihr > empfehlen könntet Da darfst du selber suchen, es gibt hunderte Boards. Ich hatte damals mit diesem hier angefangen: http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=64&products_id=10 Allerdings direkt in C programmiert, mit Bascom habe ich mich nie anfreunden können.
ich hab zwar noch nicht verstanden was du damit machen willst, aber: wenn schon dann das Summensignal nehmen. Die meisten (modernen) Empfänger sind in der Lage an einem Servo-Kanal alle Kanäle auszugeben.
Georg B. schrieb: > Die Frage ist wie groß die C-Programme werden, um PWM-Signale > aufzunehmen, zu bearbeiten und an die Servos auszugeben (danach richtet > sich ja die Speichergröße des µC‘s)? Das wird nicht ganz unwesentlich davon abhängen, was du bei der Bearbeitung alles vor hast und welchen Aufwand man bei der optimalen Implementierung der Algorithmen treibt. Neben der Speichergröße brauchst du auch noch Rechenleistung ;-)
Georg B. schrieb: > Die Frage ist wie groß die C-Programme werden, um PWM-Signale > aufzunehmen, zu bearbeiten und an die Servos auszugeben (danach richtet > sich ja die Speichergröße des µC‘s)? Servosignale aufnehmen, also von der Erfassung der Pegel am Port bis man den Auslenkungswert in einer Variable hat, dürfte in wenigen hundert Bytes zu schaffen sein. Stellt sich also die Frage, was "bearbeiten" für dich heisst. Und nicht vergessen: Meist hat man gerne noch Debug-Routinen drin, beispielsweise UART-Terminal oder LEDs. Die nehmen schnell einiges an Platz. Allgemein lohnt es sich bei Einzelanfertigungen oder kleinen Serien sowieso nicht, am Controller zu sparen. Wenn's ein 8-Bitter sein soll, so würde ich mindestens einen Atmega32 in Betracht ziehen. Allgemein sehe ich dein Projekt aber skeptisch, wenn du noch nie etwas mit Mikrocontrollern gemacht hast. Gehe das Projekt auf jeden Fall in kleinen Schritten an. Zuerst einfachste Funktionen der Hardware im Mikrocontroller umsetzen (LED blinken), dann einfache Messwert- und Debug-Ausgabe (UART), dann mal ein einzelnes Servo messen und ausgeben, dann ein Servo anhand UART-Eingabe steuern usw. Erst wenn diese Einzelteile einwandfrei funktionieren, würde ich mich überhaupt Gedanken über die ursprüngliche Idee machen. (Entweder du machst es von Anfang an so, oder du stellst ein komplettes Programm auf und nimmst es dann Stück für Stück auseinander, weil's nicht funktioniert ;-) )
Georg B. schrieb: > PWM von 1,2 – 1,8 ms Nebenbei bemerkt, stimmt das so nicht: es sind 1.0 - 2.0 ms Hast du zumindest etwas Ahnung von Modellflug?
> Das wird nicht ganz unwesentlich davon abhängen, was du bei der > Bearbeitung alles vor hast und welchen Aufwand man bei der optimalen > Implementierung der Algorithmen treibt. Neben der Speichergröße brauchst > du auch noch Rechenleistung ;-) zunächst soll das PWM Signal mittels Integrator einfach "gehalten" werden, also ein PWM Signal muss aufgenommen, dann mit einer Gleichung (Polynom dritten Grades) multipliziert, integriert, wieder umgewandelt und ausgegeben werden. Viel Code ist das zunächst nicht.
Soll der µC dann das Modell ähnlich wie ein Kreisel auf einer fest definierten Bahn halten?
> Nebenbei bemerkt, stimmt das so nicht: es sind 1.0 - 2.0 ms
das ist je nach Kanal des Empfängers unterschiedlich. Hab für jeden eine
Kurve mit Oszi aufgenommen.
Georg B. schrieb: >> Nebenbei bemerkt, stimmt das so nicht: es sind 1.0 - 2.0 ms > > das ist je nach Kanal des Empfängers unterschiedlich. Hab für jeden eine > Kurve mit Oszi aufgenommen. nochmal die Frage: hast du Ahnung von modellflug, bzw. von RC? Sagt dir trimmung, Limit, Expo, Dualrate, irgendwas? > das ist je nach Kanal des Empfängers unterschiedlich. Hab für jeden eine > Kurve mit Oszi aufgenommen. Ja eben: Wegen Trimmung, Limit, Dualrate, Expo, ...
> Allgemein sehe ich dein Projekt aber skeptisch, wenn du noch nie etwas > mit Mikrocontrollern gemacht hast Es ist auch nicht nötig, dass ale Punkte abgearbeitet werden, es werden sicherlich noch viele Bachelorarbeiten über das Thema laufen. Wichtig wäre zumindest, dass es ein System gibt auf dem man aufbauen kann.
Wegen Trimmung, Limit, Dualrate, Expo, ... Darüber weiß ich bescheid. Haben auch sehr erfahrene Modellbauflieger im Team. Modell ist übrigens eine Sebart Katana S120.
Georg B. schrieb: > Wegen Trimmung, Limit, Dualrate, Expo, ... > > Darüber weiß ich bescheid. Haben auch sehr erfahrene Modellbauflieger im > Team. Modell ist übrigens eine Sebart Katana S120. Dann ist ja gut. Stell dich trotzdem auf die 1.0 - 2.0 msec ein (glaubs mir einfach), schau ob du ein Summensignal bekommen kannst (erleichtert sowohl hardware als auch software). Das alles sollte mit einem ATmega problemlos machbar sein. http://mikrokopter.de könnte für das Projekt auch noch recht interessant sein.
Georg B. schrieb: > was ist denn mit Summensignal gemeint? Ist dein google kaputt? Der erste Treffer bringt dir die Antwort.
Was nützt mir das Summensignal wenn ich die einzelnen Signale bearbeiten will? Kann mir als Vorteil nur die Reduktion der benötigten Ports vorstellen. Aber dann müsste ich programmtechnisch das Empfängersignal zerpflücken und neu zuordnen.
Georg B. schrieb: > Was nützt mir das Summensignal wenn ich die einzelnen Signale bearbeiten > will? Kann mir als Vorteil nur die Reduktion der benötigten Ports > vorstellen. Aber dann müsste ich programmtechnisch das Empfängersignal > zerpflücken und neu zuordnen. Erstmal werden die Ports reduziert. Und auch die SW wird dadurch einfacher. "Zerpflücken" musst du das Signal so oder so. Ein Summensignal ist nicht komplexer auszuwerten als 4 einzelne. gruß cyblord
Ich will dann bitte ein Foto von der (netten!) Katana in der Humusphäre sehen! (achtung Wortwitz)
Georg B. schrieb: > Die Frage ist wie groß die C-Programme werden, um PWM-Signale > aufzunehmen, zu bearbeiten und an die Servos auszugeben (danach richtet > sich ja die Speichergröße des µC‘s)? Im Zweifelsfall lieber zu viel als zu wenig. Meine ganz persönliche Bewertung zu Programmgrößen in AVRs: 2KB: Fast immer zu wenig 4KB: Für einfache Sachen genug 8KB: Reicht für viele kleinere Projekte aus 16KB: Reicht für sehr viele Projekte aus 32KB: Bis die voll sind programmiert man schon recht lange (würde ich für dein Projekt -soweit ich es kenne - nehmen) 128KB: Entweder man verwendet größtenteils fertigen Code oder man kann in seiner Freizeit das ein oder andere Jahr programmieren bis die zu wenig sind. Anders sieht es natürlich aus, wenn man Kilobyte Weise Tabellen/Bitmaps o.ä. im Code unterbringt.
Georg B. schrieb: > Was nützt mir das Summensignal wenn ich die einzelnen Signale bearbeiten > will? Kann mir als Vorteil nur die Reduktion der benötigten Ports > vorstellen. Aber dann müsste ich programmtechnisch das Empfängersignal > zerpflücken und neu zuordnen. Nunja, im Summensignal sind einfach alle Servosignale drinnen, die dann programmtechnisch zu zerpflücken ist einfacher als sie hardwareseitig jeweils einzeln zu erfassen. Du hast 8 Servosignale angeegeben, das sind dann für ideale technische Umsetzung 8 Interrupteingänge, die Dein µC haben sollte, fürs Summensignal brauchts nur einen. Ist mehr Verkabelungsaufwand, komplexere Leiterplatte, mehr Stecker und Buchsen, mehr Gewicht, kürzere Akkulaufzeit etc.. Einen Beispielcode für die Auswertung des Summensignals in Bascom und C gibts z.B. da: http://www.rn-wissen.de/index.php/RC-Empf%C3%A4nger_auswerten nicht wirklich viel Programmaufwand zum zerlegen, oder?
Also Summensignal vereinfacht natürlich das Gesamtsystem. Des weiteren solltest du dir einen uC mit genügend Hardware PWM Kanälen aussuchen. Bedenke auch, dass die mathematischen Operationen wie z.B. Divisionen, wenn sie vom uC nicht Hardwareseitig unterstützt werden, Zeit kosten. Spontan fallen mir Atmega 640/1280/2560 mit viel Pheripherie ein, jedoch bekommt man da 32 Bit uC schon günstiger.
Georg B. schrieb: > zunächst soll das PWM Signal mittels Integrator einfach "gehalten" > werden Das funktioniert mit den Signalen, die aus dem Empfänger kommen, nicht unbedingt. Die Information ist nicht im Tastverhältnis enthalten, sondern wird in der Dauer des High-Pegels übertragen.
Georg B. schrieb: > zunächst soll das PWM Signal mittels Integrator einfach "gehalten" > werden, also ein PWM Signal muss aufgenommen, dann mit einer Gleichung > (Polynom dritten Grades) multipliziert, integriert, wieder umgewandelt > und ausgegeben werden. Machst du das in Integer (16 oder 32 Bit) oder in float? Wenn float, ist dann einfache Genauigkeit gut genug? Kommen da auch noch Divisionen dazu? Dann bist du mit deinem 'nur' ganz schnell am Ende der 8 Bit Rechenleistung. Sobald du mit floating point liebäugelst und das Ganze eine dauerhafte Plattform für mehrere Arbeiten sein soll (mit evt. komplexeren Reglern (Beobachter etc.)) dann solltest du UNBEDINGT über den Einsatz von 16/32 Bit Controllern nachdenken.
16 Bit sind wahrscheinlich unumgänglich. Wäre das dann ein ATxmega32? Was kann man denn da empfehlen?
@ Georg: Du bist aber auch einer, der gerne selber sucht, oder? Bevor du dich auf den AtXmega losstürzt, nimm was gescheites. Cortex-M3 wäre da zu nennen, von diversen Herstellern.
Storm schrieb: > @ Georg: Du bist aber auch einer, der gerne selber sucht, oder? > > Bevor du dich auf den AtXmega losstürzt, nimm was gescheites. Cortex-M3 > wäre da zu nennen, von diversen Herstellern. also wenn schon, denn schon, 64 bit ist angesagt, wer wird sich denn mit popeligen 32 Bit herumplagen wollen ... ersetzt Hirnschmalz beim Proggen durch MHz und Bits ... Glückwunsch. Ach ja, hab da noch was ganz heißes ... dividieren kann man auch indem man mit dem Kehrwert multipliziert, aber verratets nicht weiter, nicht dass das jetzt jemand verwenden sollte. Auch shiften ist eine gerne verwendete Methode zur Division ... aber nur zu, installiert auch gleich W8 auf dem Starrflügler.
Um die Sache nicht noch komplizierter zu machen als sie schon ist, bleib ich bei Atmel. Ich hab hier ein Board rausgesucht, welches meiner Meinung nach folgende Anforderungen erfüllen sollte: http://re.reworld.eu/de/produkte/index.htm und da der X4DIL für den ATxmega32 - Aufnahme und Ausgabe der PWM Signale , egal ob Summensignal oder auch einzeln - Controller bietet genug Speicher (32 kb) und Rechenleistung (16Bit) - per USB Anschluss programmierbar Ich würde gern euro Meinung dazu hören.
Georg B. schrieb: > Ich würde gern euro Meinung dazu hören. Nimm kein fertiges Board. Das wird doch viel zu groß. Entwerf ein eigenes Board mit allen Komponenten drauf die du für die Aufgabe brauchst. So ein Board eignet sich vielleicht zum basteln aufm Tisch, aber bestimmt nicht im produktiven Einsatz in einem Modellflugzeug, wo es auch noch auf die Größe ankommt. Und was soll dir da USB bringen? Führe einen kleinen ISP Stecker raus um das Ding zu programmieren. gruß cyblord
ATxmega sind 8-Bit-µC (und laufen nur mit bis zu 3.6V Versorgung). Das ist jetzt aber nichts Schlimmes, man muss es nur wissen.
Konrad S. schrieb: > ATxmega sind 8-Bit-µC (und laufen nur mit bis zu 3.6V Versorgung). stimmt. verdammt.
cyblord ---- schrieb: > 3,3 V ist sowieso State-of-the-art. Im Prinzip:ja. Aber reichen 3.3V zur Ansteuerung eines Modellbau-Servos?
Konrad S. schrieb: > cyblord ---- schrieb: >> 3,3 V ist sowieso State-of-the-art. > > Im Prinzip:ja. Aber reichen 3.3V zur Ansteuerung eines Modellbau-Servos? Für das Signal natürlich. Die meisten modernen Empfänger machen es ebenso. z.B. alle Multiplex M-Link Empfänger. Dort hat der Signalausgang immer 3,3V als Amplitude. Nur die Versorgung muss natürlich höher sein. gruß cyblord
cyblord ---- schrieb: > Für das Signal natürlich. Die meisten modernen Empfänger machen es > ebenso. z.B. alle Multiplex M-Link Empfänger. Dort hat der Signalausgang > immer 3,3V als Amplitude. Gut zu wissen, danke!
Fhutdhb Ufzjjuz schrieb: > rsetzt Hirnschmalz beim Proggen durch MHz und Bits ... Glückwunsch. Vieleicht denkst du mal darüber nach daß es hier darum gehen könnte regelungstechnische Probleme zu lösen und nicht möglicht effektiv Bits zu schubsen nur um einen 8 Bitter nehmen zu können. Wahrscheinlich ist für dich auch ein Assembler schon neumodisches Zeugs und du programmierst deinen µC indem du mit 8 (oder auch 12 oder 16, ...) Schalterchen den OpCode setzt und dann den Übernahmeknopf drückst. Fhutdhb Ufzjjuz schrieb: > dividieren kann man auch indem > man mit dem Kehrwert multipliziert, > ... > Auch shiften ist eine gerne verwendete Methode zur Division ... Prima, erleuchte uns doch mal indem du kurz hier aufschreibst wie das aussieht für 0,13452 / 0,775. Falls du das nicht gelesen hast, ich habe gefragt ob er float braucht oder gar double. Aber wahrscheinlich weisst du das besser als er :-)
Udo Schmitt schrieb: > Vieleicht denkst du mal darüber nach daß es hier darum gehen könnte > regelungstechnische Probleme zu lösen und nicht möglicht effektiv Bits > zu schubsen nur um einen 8 Bitter nehmen zu können. mitnichten, stellt sich die Frage des Einstiegs für den Herren, wie mir scheint hat da noch keine LED geblinkt an nem µC, der Fragestellungen nach, und dann gleich 32Biter ARM ... Respekt, wenn das Ganze in nem Jahr läuft. Der Einstieg in die 8-Bit AVR ist wesentlich einfacher und dank DIL kann man die Dinger mal auf n Steckbrett pinnen und seine Schaltung testen, mit nem Devboard kann er das zwar im Prinzip auch, ist aber wesentlich unflexibler. Er wird sowieso nicht ums Designen einer eigenen Leiterplatte herum kommen, die dann aber von Null aus aus dem Boden zu stampfen wird ne harte Nuss. 0,13452 * 1,2903225806451612903225806451613 und? Davon abgesehen fliegen genügend Quadrocopter mit 8 Bit AVRs, die pfeifen nebenher noch "La Paloma" und lassen LED-Muster blinken ... komisch
Fhutdhb Ufzjjuz schrieb: > mitnichten, stellt sich die Frage des Einstiegs für den Herren, wie mir > scheint hat da noch keine LED geblinkt an nem µC, der Fragestellungen > nach, und dann gleich 32Biter ARM ... Respekt, wenn das Ganze in nem > Jahr läuft. Das ist sehr richtig und hier müsste man sich eigentlich fragen ob eine Art von "Autopilot" dann überhaupt mit den vorhandenen Vorkentnissen machbar ist, egal mit welchem Controller. Aber diese Frage stellt sich eigentlich dauernd. Von dem her lassen wir das einfach mal beiseite. Und ja ich würde auch sagen ein ATMega reicht. gruß cyblord
von einem Flugregler oder Autopilot sind wir im gesamten Projekt noch sehr weit enfernt. Wir haben in der Katana eine sbRIO sitzen mit FPGA, aber LabView ist der größte Mist und von NI abhängig zu sein ist teuer. Damit wurde auch nur das Eigenverhalten des Modells erfasst. Ich habe beschlossen die Sache mit einem Mikrocontroller anzugehen und ich bin bestrebt zumindest 2 Servos ein PWM Signal vorzugeben. Wenn dabei rauskommt, dass die Sache machbar und erweiterbar ist, dann hat sich das alles schon gelohnt.
Ich bau auch immer Ethernet in mein Modellflugzeug ein^^
Georg B. schrieb: > Ich habe beschlossen die Sache mit einem Mikrocontroller anzugehen und > ich bin bestrebt zumindest 2 Servos ein PWM Signal vorzugeben. > Wenn dabei rauskommt, dass die Sache machbar und erweiterbar ist, dann > hat sich das alles schon gelohnt. Kannst du nochmal kurz erläutern was du eigentlich tun willst? Ich glaub ich hab das immer noch nicht verstanden. Du willst einen Controller zwischen RX und Servo schalten, ok. Aber was genau soll der tun? Wofür ist das gedacht?
Er soll ein PWM Signal aufnehmen. der Verlauf dieses Signals ist bekannt und wird dementsprechend in einen Wert von -1 bis +1 umgerechnet (durch ein Polynom dritten grades). Danach folgt eine Integration des Signals, quasi nur das Halten des aktuellen Wertes. Schließlich muss dieser Wert wieder in das PWM Signal umgewandelt werden und an die Servos ausgegeben. Dadurch kann z.B. ein Command Roll/Attitude Hold ermöglicht werden. Das Modell hält beim Kurvenflug nach losgelassenem Knüppel die Lage.
Also wir haben in unseren Fliegern an der Uni einen selbstentwickelten Bordrechner mit einem Gumstix (Cortex A8 720MHz, Angstom Linux) und einem FPGA Modul (Spartan 3 bzw. 6). Das ist sowohl in Bezug auf die Rechenleistung als auch leider im Preis eine etwas andere Kategorie als ein einzelner 8/16-Bit Mikrocontroller. Der Vorteil ist, dass man auch anspruchsvolle Filter und Regler in Echtzeit onboard laufen lassen kann. Zusätzlich gibt es noch ein Testbed (Flugsimulation in Matlab/Simulink), um "im Trockenen" zu testen, ohne den echten Flieger zu gefährden. .... schrieb: > Ich bau auch immer Ethernet in mein Modellflugzeug ein^^ Am Flieger ist ein Kabel wenig sinnvoll, deshalb hat der Gumstix WLAN ;-) Darf man fragen, was ihr langfristig damit vor habt? In der Katana scheint ja genug Platz zu sein, von daher wäre ein fertiges Board a la raspberry pi/Beagleboard etc. oder "nur" eins mit einem kleineren Prozessor auch keine schlechte Wahl. Eine eigene Platine, die Anschlüsse für die Sensoren, Aktuatoren, Debugging... bereit stellt braucht's aber trotzdem noch. Inspirationen kann man sich z.B. bei Paparazzi und Konsorten holen, es gibt ja inzwischen genügend Systeme für Modellflieger: http://paparazzi.enac.fr/wiki/Lisa/L https://pixhawk.ethz.ch/ Alternativ könnte man auch direkt einen solchen Rechner einsetzen, das spart Entwicklungsaufwand (im 1. Anlauf geht garantiert immer was schief). Und noch ein ganz allgemeiner Tipp: Bau eine Schaltung ein, die den Regler überbrücken kann und die Signale der Funke direkt an die Servos weiterleitet. Falls der Regler mal spinnt/ausfällt kann man dann den Flieger noch manuell retten. Idealerweise ist diese Schaltung komplett unabhängig vom Rest und so simpel wie möglich, um Designfehler auszuschließen. Früher hatten wir separate Logikchips dafür, inzwischen ist das in den FPGA gewandert. Als "Entscheidungsgrundlage" wird ein Kanal der Funke verwendet (auf einen Kippschalter legen). Georg B. schrieb: > Dadurch kann z.B. ein Command Roll/Attitude Hold ermöglicht werden. Das > Modell hält beim Kurvenflug nach losgelassenem Knüppel die Lage. Zum Halten der Rate/Lage muss man auch messen. Also hier z.B. die aktuelle Drehrate per Gyro messen, vom Sollwert (linear aus dem PWM Signal berechnet) abziehen und in einen Regler (PID oder was auch immer) geben. Was du mit deinem Polynom 3. Grades vor hast, erschließt sich mir noch nicht so ganz.
Georg B. schrieb: > Er soll ein PWM Signal aufnehmen. der Verlauf dieses Signals ist bekannt > und wird dementsprechend in einen Wert von -1 bis +1 umgerechnet (durch > ein Polynom dritten grades). Danach folgt eine Integration des Signals, > quasi nur das Halten des aktuellen Wertes. Schließlich muss dieser Wert > wieder in das PWM Signal umgewandelt werden und an die Servos > ausgegeben. > > Dadurch kann z.B. ein Command Roll/Attitude Hold ermöglicht werden. Das > Modell hält beim Kurvenflug nach losgelassenem Knüppel die Lage. Und dafür habt ihr dann noch alle möglichen Sensoren verbaut, Gyros usw.?
erstmal vielen Dank für die vielen ausführlichen Antworten aller Beteiligten hier ! _________________________________________________________________ Michael Frangenberg schrieb: > Darf man fragen, was ihr langfristig damit vor habt? irgendwann soll die Sache schon Richtung autonomes Fliegen gehen, aber zunächst möchte ich die "Machbarkeit" der Ansteuerung mittels Mikrokontroller darstellen > > Und noch ein ganz allgemeiner Tipp: > Bau eine Schaltung ein, die den Regler überbrücken kann und die Signale > der Funke direkt an die Servos weiterleitet. Falls der Regler mal > spinnt/ausfällt kann man dann den Flieger noch manuell retten. > Idealerweise ist diese Schaltung komplett unabhängig vom Rest und so > simpel wie möglich, um Designfehler auszuschließen. Früher hatten wir > separate Logikchips dafür, inzwischen ist das in den FPGA gewandert. Als > "Entscheidungsgrundlage" wird ein Kanal der Funke verwendet (auf einen > Kippschalter legen). > genauso wird das bereits gemacht. Mittels Schalter am Steuergerät kann der Pilot die alleinige Kontrolle erlangen > > Georg B. schrieb: >> Dadurch kann z.B. ein Command Roll/Attitude Hold ermöglicht werden. Das >> Modell hält beim Kurvenflug nach losgelassenem Knüppel die Lage. > Zum Halten der Rate/Lage muss man auch messen. Also hier z.B. die > aktuelle Drehrate per Gyro messen, vom Sollwert (linear aus dem PWM > Signal berechnet) abziehen und in einen Regler (PID oder was auch immer) > geben. Was du mit deinem Polynom 3. Grades vor hast, erschließt sich mir > noch nicht so ganz. der Regler wäre der 2te Schritt. Aber ein komplettes Trägheitsnavigationssystem ist schon an Bord.
Georg B. schrieb: > Modell hält beim Kurvenflug nach losgelassenem Knüppel die Lage Wie kann man den losgelassenen Knüppel von einer gewollten Ansteuerung (in die Ruhelage) unterscheiden?
Konrad S. schrieb: > Wie kann man den losgelassenen Knüppel von einer gewollten Ansteuerung > (in die Ruhelage) unterscheiden? Ratenvorgabe: Gar nicht, wozu auch. Wenn man die Lage ändern will, muss man den Knüppel auslenken. Null (also losgelassen, ist ja eine Feder drin) am Knüppel bedeutet einfach, dass keine Lageänderung erfolgen soll. Lagevorgabe (sinnvoll für Quadrocopter): Der Flieger hängt direkt am Knüppel, sobald du loslässt, dreht er wieder in die Nulllage.
Michael Frangenberg schrieb: > Ratenvorgabe: > Gar nicht, wozu auch. Wenn man die Lage ändern will, muss man den > Knüppel auslenken. Null (also losgelassen, ist ja eine Feder drin) am > Knüppel bedeutet einfach, dass keine Lageänderung erfolgen soll. Ich kann dir nicht folgen. Also: Zunächst habe ich die Rate "75% nach links" vorgegeben. Dann lasse ich den Knüppel los und der Knüppel springt in Null-Stellung. Jetzt möchte ich die Rate "Null" vorgeben. Was muss ich tun?
> Also: Zunächst habe ich die Rate "75% nach links" vorgegeben. Dann lasse > ich den Knüppel los und der Knüppel springt in Null-Stellung. Jetzt > möchte ich die Rate "Null" vorgeben. Was muss ich tun? Du musst den Knüppel nach rechts einschlagen (wieviel Prozent ist vom Flugregler abhängig). Die Nulllage kontrolliert man per Anzeige oder Sicht. Gibt ein angenehmes Fluggefühl. Ist übrigens bei jedem neuen Airbus oder Boeing so.
Ah! Also könnte man sagen, der Knüppel steuert nicht die Geschwindigkeit, sondern die Beschleunigung. Richtig?
Angehängte Dateien:
-
signal.png
21 KB
Der Knüppel steuert eigentlich nur den prozentualen Ruderauschlag. Dieser wird anhand einer "Signalkurve" in ein Steuersignal für die Ruder umgesetzt. Also ein kleiner Ausschlag erzeugt beispielsweiße nur ein geringes Signal (eher die Energiemenge), damit ein versehentliches Berühren keine große Bewegung des Flugzeuges bewirkt. Ein weiterer Knüppelausschlag erzeugt dann ein expotenziell wachsendes Steuersignal.Die Geschwindigkeit oder die Beschleunigung wird vom Flugregler gedeckelt, damit die Struktur des Flugzeuges keinen Schaden nimmt.
Georg B. schrieb: > Also ein kleiner Ausschlag erzeugt beispielsweiße nur ein > geringes Signal (eher die Energiemenge), damit ein versehentliches > Berühren keine große Bewegung des Flugzeuges bewirkt. Dann muß deine Steuerkurve aber mit Steigung Null durch den Ursprung gehen, damit dir der Ruderausschlag nicht wegdriftet :-)
der Regler hat meistens eine Totzone von +/- 2% um den Nullpunkt wo nichts passiert. Natürlich sieht die Kurve auch etwas anders aus, war nur ne schnelle Zeichnung in Paint.
nochmal kurz zu meiner Problemstellung. Ich wollte mir jetzt den X4DIl mit dem Atxmega128A4U von http://re.reworld.eu/de/produkte/index.htm bestellen mit einem ISP Programmer AVRISP mkII. Damit bin ich doch von der Hardwareseite aus komplett ausgerüstet um mit C den Controller zu programmieren, damit er PWM Signale erfasst und wieder ausgibt? Meine Recherche ergab zumindest, dass 8 Bit ausreichen, bei angemessener Geschwindigkeit die Signale auch zu bearbeiten.(Multiplikationen von ganzzahligen Werten)
>aufgrund meiner mangelnden Kenntnisse in Sachen Mikrocontroller >Bachelorarbeit >Luft- und Raumfahrttechnik Ich hol mal die Çhips und das Bier. Das wird ein Spass. Fuer uns. Das Projekt hat leider Null Chancen. Ein durchgeknallter Prof moechte seinen Kollegen gegenueber protzen, wie er die Studis aufreibt. Sorry, aber so ein Projekt ist auch Fachleute mit Jahren Erfahrung anspruchsvoll. Wenn man denn den passenden controller kann, sinds doch noch anspruchsvolle Differentialgleichungen
Ist wirklich spannend. Besorgt Euch mal aus der Bib den Brockhaus - Flugregelung und dann lest mindestens Kapitel 2. Danach, wenn könnt ihr mit Kapitel 14 weiter machen ... da gehts um die von Dir angestrebte Lageregelung. Ist aber alles andere als trivial ... vor allem die ganzen Koordinatensysteme haben es in sich! Mal abgesehen von den ganzen Kopplungen zwischen Längs- und Seitenbewegung ... Viel Erfolg! Michael
Konrad S. schrieb: > Der X4DIl und der AVRISP mkII passen zusammen. ja, aber davon ausgehend fehlt dann doch noch n bisschen Werkzeug für die Veranstaltung ... Netzteil, Multimeter, Lötkolben, Oszilloskop, Breadboard, Punkt- oder Streifenrasterplatinen, diverse Kleinteile, Transistoren, Elkos, Kerkos, Widerstände, LEDs, Spannungsregler etc. etc. Diverse Sensoren würde ich auch auf die Einkaufsliste nehmen, z.B. Luftdruck um ggf. die Flughöhe zu regeln, Kompassmodul für die Richtung, 3-Achs Beschleunigungssensoren auch ... Das Wichtigste ... viel Stehvermögen und Sitzfleisch
ецтаьэр schrieb: > Sorry, aber so ein Projekt ist auch Fachleute mit Jahren Erfahrung > anspruchsvoll. Wenn man denn den passenden controller kann, sinds doch > noch anspruchsvolle Differentialgleichungen Kein Ing. rechnet in der Regelungstechnik mit DGLs, höchstens Physiker. Wozu gibts die Laplace bzw. für digitale Systeme die Z Transformation. Und das gibt nicht ein Projekt für eine Abschlussarbeit, sondern ist wohl eher dazu gedacht als Basis für eine ganze Reihe von Arbeiten zu dienen, die aufeinader aufbauen. Deshalb auch mein Einwand weiter oben bei der Rechenpower nicht zu sparen. Wie Michael ja geschrieben hat gibt es solche Projekte öfter. Ich habe meine Studienarbeit vor über 20 Jahren mit dem Aufbau einer Hardware zur Steuerung von Helis gemacht. Damals noch mit 68000er.
Hallo, Wenn die Zwischenplatine selbst Reglung durchführen soll und der Komlexitätsgrad nach oben offen ist, so würde ich keinen Atmega nehmen. Ich habe mal einen Quadrokopter mit einem gebaut. Funktionierte auch, ist aber recht limitiert. Um eine Regelschleifenfrequenz von 500 - 1000 Hz zu erreichen muss man schon recht genau hingucken was man macht. Mit herkömmlichen Divisionen ist sofort ende im Gelände. Ich habe alles mit Bitshift-Divisionen gelöst. Nimm doch ein stm32F4 Discovery. Ist nicht schwerer zu handhaben als ein Atmega und man kann sich austoben :-) PS: Ich würde auch das Summensignal nutzen. Spart jede Menge Leitungen und ist dadurch sicher auch robuster.Ich habe das jedenfalls so gemacht. In der Funke konnte ich das entpsrechend einstellen. lg jo
Jo discovery schrieb: > Um eine Regelschleifenfrequenz von 500 - 1000 > Hz zu erreichen Zwischen RC-Empfänger und Servo? Wozu?
Konrad S. schrieb: > Jo discovery schrieb: >> Um eine Regelschleifenfrequenz von 500 - 1000 >> Hz zu erreichen > > Zwischen RC-Empfänger und Servo? Wozu? In der Annahme, dass er dazwischen noch eine Reglung implementieren will und der RC-Empfänger nur die Soll-Werte vorgibt. Wenn er nicht regeln möchte, könnte er doch sonst den Empfänger direkt an die Servos anschließen. Oder habe ich da was falsch verstanden? :-) PS: Die 500-1000Hz bezogen sich auf den Quadrokopter (ein Beispiel). lg jo
hier schon einmal geschaut?: http://www.multiwii.com/ Es gibt für alle Flugmodelle Konfigurationsmöglichkeiten. Verschiedenste Sensoren bis hin zu GPS können einfach implementiert werden. gruss min
Jo discovery schrieb: > In der Annahme, dass er dazwischen noch eine Reglung implementieren will Ja, schön. Aber auch eine Million Berechnungen pro Sekunde machen das Servo, das es tun muss, nicht schneller. Also wozu? Übersehe ich etwas wesentliches?
Ja, schön. Aber auch eine Million Berechnungen pro Sekunde machen das Servo, das es tun muss, nicht schneller. ------------------------------------------- Das ist natürlich richtig. Die maximale Refreshrate des Servos lässt sich nicht vergrößern. Meine Antwort zielte in eine andere Richtung. Es ging mir darum für Entwicklungsoptionen den nötigen Raum nach oben hin offen zu halten. Er will ja noch Informationen in die RC-Empfängersignale einfließen lassen bevor er sie dann an die Servos weitergibt (sonst könnte er die Leiterplatte ja auch weglassen). Diese Black Box dazwischen kann beliebig kompliziert werden. Bei einem Atmega sind die Grenzen schnell ausgeschöpft und dann wird die Regelschleifenfrequenz schnell zu klein (kleiner als die Refreshrate der Servos.) Denken wir nur mal an diverse Filteralgorithmen um Sensordaten gescheit auszuwerten. Das wird mit einem Atmega unter Umständen ein Krampf. :-) Georg schreibt ja selbst, dass noch Platz nach oben hin offen sein soll. Diesen Platz hat er mit einem modernen CortexM4 (der keine Nachteile gegenüber einem Atmega hat - weder preislich noch sonstwie).
Konrad und Jo: Ihr vergleicht Birnen und Äpfel ... die Bandbreite eine Quadcopters ist ein Vielfaches der eines Flugzeugs! Beim Quad gehts nicht um Servogeschwindigkeiten, sondern um die Regler-Totzeiten ... Ich habs bei meinem Quad mal probiert: 400Hz -- ok 200Hz -- ok 100Hz -- Reglerparameter * 0.8 50Hz -- Reglerparameter * 0.4 Bei nem Flugzeug sind 50Hz mehr als genug ... da reichen auch schon mal 20Hz. Grüße, Michael
Wie aufwendig die Berechnungen auch immer sein mögen: Zu Beginn des PWM-Impulses an das Servo muss sich der Controller entschieden haben, wie lange der Puls dauern soll, sonst setzt die Regelung eine Runde aus. Üblicherweise so um die fünfzig mal pro Sekunde. Bei gegebenem Controller - welcher sei dahingestellt - ist also die verfügbare Rechenleistung bekannt. Wie hoch ist die benötigte Rechenleistung? Ist eigentlich noch nicht bekannt. Also für ein eher unbekanntes Ziel eine Kanone oder eine Steinschleuder kaufen? Ich bevorzuge dabei meist die Kanone. ;-)
>Kein Ing. rechnet in der Regelungstechnik mit DGLs, höchstens Physiker.
Wozu gibts die Laplace bzw. für digitale Systeme die Z Transformation.
Das ist ja grossartig. Ihr werdet fuer die Modellierung aber nicht um
einen Physiker heumkommen, denn da geht um sich bewegende und
beschleunigte Koordinatensysteme in 3D.
Ich kann das beurteilen, denn ich bin Ing. & Physiker.
Konrad S. schrieb: > Wie aufwendig die Berechnungen auch immer sein mögen: Zu Beginn des > PWM-Impulses an das Servo muss sich der Controller entschieden haben, > wie lange der Puls dauern soll, sonst setzt die Regelung eine Runde aus. > Üblicherweise so um die fünfzig mal pro Sekunde. Bei gegebenem > Controller - welcher sei dahingestellt - ist also die verfügbare > Rechenleistung bekannt. Wie hoch ist die benötigte Rechenleistung? Ist > eigentlich noch nicht bekannt. Also für ein eher unbekanntes Ziel eine > Kanone oder eine Steinschleuder kaufen? Ich bevorzuge dabei meist die > Kanone. ;-) Das ist schon richtig, aber der Regler kann asynchron zu den Eingaben laufen! Die Dämpfung bzw. Regelung der Lage eines Quadcopters kann problemlos mit 400Hz laufen und die kommandierten Lagewinkel über die PWM-Signale von der Fernsteuerung kommen halt einfach mit 50Hz ... das ist kein Widerspruch ... Grüße, Michael
ецтаьэр schrieb: > Ihr werdet fuer die Modellierung aber nicht um einen Physiker heumkommen, Nix gegen Physiker, aber träum weiter :-)
Michael K. schrieb: > PWM-Signale von der Fernsteuerung kommen halt einfach mit 50Hz ... das Aber die gehen doch auch mit 50Hz (zum Servo)?!? (amkopfkratz)
ецтаьэр schrieb: > Ihr werdet fuer die Modellierung aber nicht um > einen Physiker heumkommen, denn da geht um sich bewegende und > beschleunigte Koordinatensysteme in 3D. > Ich kann das beurteilen, denn ich bin Ing. & Physiker. Süss... Ich bin "nur" Ing. aber was denkst du, wie man den TCP von Roboterarmen berechnet???
Roboterarme arbeiten irgendwo festgeschraubt, und koennen dort auch Kraft ausueben. Bezuegl. den Roboterarmen. Ich war mal an einer Fuehrung durch ein Mercedes Benz Werk. Alles fast maximal roboterisiert. Mir fiel auf, die Roboterarme bewegten in der Regel Werkzeugplattformen, die so montiert waren, dass das maximale Traegheitsmoment resultierte... ja...
also wie sich mir das hier gerade darstellt brauchts eher nen Theologen ... gutes Gelingen.
> Mir fiel auf, die Roboterarme bewegten in der Regel > Werkzeugplattformen, die so montiert waren, dass das maximale > Traegheitsmoment resultierte... ja... Was bedeutet das?
Konrad S. schrieb: > Michael K. schrieb: >> PWM-Signale von der Fernsteuerung kommen halt einfach mit 50Hz ... das > > Aber die gehen doch auch mit 50Hz (zum Servo)?!? (amkopfkratz) Die Regler bei meinem Quad hängen direkt am Controller, der die PWM Frequenz (bei mir 400Hz) vorgibt und das sind andere Ports als die PWM Eingänge (wobei ich ein Summensignal auswerte -- braucht nur einen Pin). Die PWM Werte steuern dann nicht mehr direkt die Regler, sondern werden als Eingabewerte bzw. als Sollwerte verarbeitet. So steuer ich beispielsweise mit einem Knüppel die Roll-Lage des Kopters (Knüppel in der Mitte: 0°, Knüppel ganz links: -30°, Knüppel ganz rechts: 30°). Der "Autopilot" hat dann die Aufgabe meine vorgegebenen Sollwerte der Knüppel am Copter umzusetzen und das kann ja schneller passieren als mit der Frequenz der Eingangssignale ... Beste Grüße, Mike
Michael K. schrieb: > Die Regler bei meinem Quad hängen direkt am Controller Jetzt hab ich's geschnallt, danke!
>> Mir fiel auf, die Roboterarme bewegten in der Regel >> Werkzeugplattformen, die so montiert waren, dass das maximale >> Traegheitsmoment resultierte... ja... > >Was bedeutet das? Das man zur Bewewgung maximale Leistung benoetigt. Quasi die maximal schlechte Loesung. Von Pfeifen, die schnell eine Loesung haben mussten und keine Ahnung hatten.
ецтаьэр schrieb: >>> Mir fiel auf, die Roboterarme bewegten in der Regel >>> Werkzeugplattformen, die so montiert waren, dass das maximale >>> Traegheitsmoment resultierte... ja... >> >>Was bedeutet das? > > Das man zur Bewewgung maximale Leistung benoetigt. Quasi die maximal > schlechte Loesung. Von Pfeifen, die schnell eine Loesung haben mussten > und keine Ahnung hatten. Es muss schwer sein wenn man als einziger Ahnung hat und alle andere nur Pfeifen sind.
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.