Community Flight Control
- Themenstarter Kayle
- Beginndatum
- Status
Hi,
hab da auch schon das eine oder andere mal drüber nach gedacht.. und ich finde auch das die 8 bitter durchaus gut sind um die basis zu bilden. mein gedanke war mal .. einen 8 bitter für motor PWM, empfänger lesen und mit ner 6050 auch für die basis flugeigenschaften zu nehmen .. und dann eben noch irgentein 32bitter mit nochmal MPU6050+mag oder 9150 im DMP mode mit nem GPS drann für die "höheren" aufganben..
der DMP bietet meines wissens die genausten lagedaten .. nur das eben leider nur mit 200Hz .. aber da GPS ja eh net so flott ist, und so der 8 bitter das gyro der ersten MPU6050 mit ~1kHz auslesen kann, sollte das dennoch stabiel fliegen.
ich denke eh das man, wenn man mit sowas anfangen mag erstmal einen guten gyro mode als basis haben sollte.. bei manchen stimmt der noch nicht mal und dann wundert man sich warum die dinger nicht ruhig fliegen..
also um das nochmal anderst dar zu stellen .. man hat einen 8 bitter (egal ob ATX oder nur ATmega) der mit der MPU, dem RX und den motoren schon mal gut fliegt.. der 32bitter hat seine eigene imu und GPS und steuert bei bedarf einfach nur mit..
auch wenn ich flyduino "gehöre"
hätte ich dennoch spass an sowas mit zu machen
gruß
Felix
hab da auch schon das eine oder andere mal drüber nach gedacht.. und ich finde auch das die 8 bitter durchaus gut sind um die basis zu bilden. mein gedanke war mal .. einen 8 bitter für motor PWM, empfänger lesen und mit ner 6050 auch für die basis flugeigenschaften zu nehmen .. und dann eben noch irgentein 32bitter mit nochmal MPU6050+mag oder 9150 im DMP mode mit nem GPS drann für die "höheren" aufganben..
der DMP bietet meines wissens die genausten lagedaten .. nur das eben leider nur mit 200Hz .. aber da GPS ja eh net so flott ist, und so der 8 bitter das gyro der ersten MPU6050 mit ~1kHz auslesen kann, sollte das dennoch stabiel fliegen.
ich denke eh das man, wenn man mit sowas anfangen mag erstmal einen guten gyro mode als basis haben sollte.. bei manchen stimmt der noch nicht mal und dann wundert man sich warum die dinger nicht ruhig fliegen..
also um das nochmal anderst dar zu stellen .. man hat einen 8 bitter (egal ob ATX oder nur ATmega) der mit der MPU, dem RX und den motoren schon mal gut fliegt.. der 32bitter hat seine eigene imu und GPS und steuert bei bedarf einfach nur mit..
auch wenn ich flyduino "gehöre"
hätte ich dennoch spass an sowas mit zu machen gruß
Felix
Hi,
hab da auch schon das eine oder andere mal drüber nach gedacht.. und ich finde auch das die 8 bitter durchaus gut sind um die basis zu bilden. mein gedanke war mal .. einen 8 bitter für motor PWM, empfänger lesen und mit ner 6050 auch für die basis flugeigenschaften zu nehmen .. und dann eben noch irgentein 32bitter mit nochmal MPU6050+mag oder 9150 im DMP mode mit nem GPS drann für die "höheren" aufganben..
der DMP bietet meines wissens die genausten lagedaten .. nur das eben leider nur mit 200Hz .. aber da GPS ja eh net so flott ist, und so der 8 bitter das gyro der ersten MPU6050 mit ~1kHz auslesen kann, sollte das dennoch stabiel fliegen.
ich denke eh das man, wenn man mit sowas anfangen mag erstmal einen guten gyro mode als basis haben sollte.. bei manchen stimmt der noch nicht mal und dann wundert man sich warum die dinger nicht ruhig fliegen..
also um das nochmal anderst dar zu stellen .. man hat einen 8 bitter (egal ob ATX oder nur ATmega) der mit der MPU, dem RX und den motoren schon mal gut fliegt.. der 32bitter hat seine eigene imu und GPS und steuert bei bedarf einfach nur mit..
auch wenn ich flyduino "gehöre" hätte ich dennoch spass an sowas mit zu machen
gruß
Felix
hab da auch schon das eine oder andere mal drüber nach gedacht.. und ich finde auch das die 8 bitter durchaus gut sind um die basis zu bilden. mein gedanke war mal .. einen 8 bitter für motor PWM, empfänger lesen und mit ner 6050 auch für die basis flugeigenschaften zu nehmen .. und dann eben noch irgentein 32bitter mit nochmal MPU6050+mag oder 9150 im DMP mode mit nem GPS drann für die "höheren" aufganben..
der DMP bietet meines wissens die genausten lagedaten .. nur das eben leider nur mit 200Hz .. aber da GPS ja eh net so flott ist, und so der 8 bitter das gyro der ersten MPU6050 mit ~1kHz auslesen kann, sollte das dennoch stabiel fliegen.
ich denke eh das man, wenn man mit sowas anfangen mag erstmal einen guten gyro mode als basis haben sollte.. bei manchen stimmt der noch nicht mal und dann wundert man sich warum die dinger nicht ruhig fliegen..
also um das nochmal anderst dar zu stellen .. man hat einen 8 bitter (egal ob ATX oder nur ATmega) der mit der MPU, dem RX und den motoren schon mal gut fliegt.. der 32bitter hat seine eigene imu und GPS und steuert bei bedarf einfach nur mit..
auch wenn ich flyduino "gehöre"
hätte ich dennoch spass an sowas mit zu machen gruß
Felix
Freut mich das du mitmachen würdest. Ich denke das wird auch so werden. 8bit FC ( wobei ja nicht nur fliegende Objekte unterstützt werden sollen sondern auch schiffe ) und wenn mehr gewünscht dann mit einem 32bit Controller als Zusatz. Ich würde das Projekt gerne "XStabi" taufen. X wegen dem xmega und stabi weil es alles und nicht nur fliegendes stabilisieren können sollte.
Gruß Kayle
Genau da liegt das Problem - Du siehst für ein bestimmtes Feature nur bestimmte (begrenzte) Möglichkeiten, jemand anderes sieht da wieder ganz andere bzw. mehr Möglichkeiten und wieder andere werden die entsprechenden Möglichkeiten viel später entdecken, nachdem sich erst die entsprechenden Grundvoraussetzungen etabliert haben. Das kann Heute noch niemand genau sagen. Mir geht es weniger um den persönlichen Horizont eines jeden - auch meiner ist da nur begrenzt. Sondern um eine fruchtbare und universell einsetzbare Grundlage in Hardware und Software, die auch eine brauchbare Basis für zukünftige Features bietet. Das Internet hat am Anfang auch noch nicht den Sinn gemacht genau wie die ersten PCs.
Gerade das Thema GPS ist anspruchsvoll, wenn man präzise arbeiten will: Die Daten vom GPS-Sensor sind an sich recht grob, aber dennoch aufwändig in der Verarbeitung. Will man dann die Flugpräzision erhöhen, müssen noch weitere Sensordaten (Baro, Acc, etc.) einfließen. Eine einzelne 8 Bit CPU mit den typischen Eigenschaften ist hier ziemlich schnell am Limit. Typische 32-Bit CPUs haben hier deutlich mehr Spielraum. Allerdings haben diese nicht nur Vorteile, z.B. sei die Sprachhürde und die Komplexität der notwendigen Toolchains genannt. Auch muss man sich beim Thema Pinning einigen.
Meine (persönliche) Meinung ist, dass ein Team von Leuten, die sich Gedanken um ein solch modulares System macht, ein echter Gewinn wäre. Austauschbare Komponenten, verbunden über standardisierte Protokolle. Zum Fliegen eine 8 oder 32 Bit CPU, verbunden mit einem oder mehreren 8 oder 32 Bit CPUs die sich um alles andere kümmern. Gemeinsamer Nenner ist das standardisierte Protokoll, welches unabhängig von der verwendeten Sprache ist. Dazu noch die Spezifikationen zu Lochkreis, physikalische Position der Kontaktleisten und Art der Bussysteme (SPI, I²C, CAN, etc). Fertig. Dann kann jeder sich seine CPU-Boards mit eigenem Pinning zusammenfriemeln. Idealer Weise bietet die Spezifikation die Möglichkeit einen 8 Bit Atmel mit den üblichen Sensoren auf einer Platine unterzubringen aber auch einen Stapel aus verschiedenen CPUs und Sensoren zu stapeln.
Erschwerend kommt noch hinzu, dass für eine ausgereifte FC eine möglichst große Verbreitung zwingend notwendig ist. Die Art und Weise, wie das mit 8 Bit MultiWii als OS-System geschah, ist Heute nicht mehr reproduzierbar. Das Design sollte dies berücksichtigen, damit meine ich vor allem die Eigenschaft in großer Stückzahl herstellbar und/ oder ohne E-Technik-Studium nachbaubar zu sein. Es gibt eine Menge Projekte, die zwar technisch teilweise extrem sexy sind, aber wo die Entwickler genau diese Dinge aus den unterschiedlichsten Gründen nicht berücksichtigen und somit niemals eine Chance haben, aus ihrer Nische herauszukommen. Und wer hat schon Lust, seine mehr oder weniger wertvoll Freizeit etwas zu widmen, dass nur von einigen, wenigen abhängt und jederzeit eingestellt werden kann? Ich nicht. Wenn man gleich zu Anfang darauf achtet, mindestens einen - oder besser gleich mehrere - kommerzielle Partner - ins Boot zu holen, sind einige Hürden deutlich niedriger.
Just my 2 Cents...
Gerade das Thema GPS ist anspruchsvoll, wenn man präzise arbeiten will: Die Daten vom GPS-Sensor sind an sich recht grob, aber dennoch aufwändig in der Verarbeitung. Will man dann die Flugpräzision erhöhen, müssen noch weitere Sensordaten (Baro, Acc, etc.) einfließen. Eine einzelne 8 Bit CPU mit den typischen Eigenschaften ist hier ziemlich schnell am Limit. Typische 32-Bit CPUs haben hier deutlich mehr Spielraum. Allerdings haben diese nicht nur Vorteile, z.B. sei die Sprachhürde und die Komplexität der notwendigen Toolchains genannt. Auch muss man sich beim Thema Pinning einigen.
Meine (persönliche) Meinung ist, dass ein Team von Leuten, die sich Gedanken um ein solch modulares System macht, ein echter Gewinn wäre. Austauschbare Komponenten, verbunden über standardisierte Protokolle. Zum Fliegen eine 8 oder 32 Bit CPU, verbunden mit einem oder mehreren 8 oder 32 Bit CPUs die sich um alles andere kümmern. Gemeinsamer Nenner ist das standardisierte Protokoll, welches unabhängig von der verwendeten Sprache ist. Dazu noch die Spezifikationen zu Lochkreis, physikalische Position der Kontaktleisten und Art der Bussysteme (SPI, I²C, CAN, etc). Fertig. Dann kann jeder sich seine CPU-Boards mit eigenem Pinning zusammenfriemeln. Idealer Weise bietet die Spezifikation die Möglichkeit einen 8 Bit Atmel mit den üblichen Sensoren auf einer Platine unterzubringen aber auch einen Stapel aus verschiedenen CPUs und Sensoren zu stapeln.
Erschwerend kommt noch hinzu, dass für eine ausgereifte FC eine möglichst große Verbreitung zwingend notwendig ist. Die Art und Weise, wie das mit 8 Bit MultiWii als OS-System geschah, ist Heute nicht mehr reproduzierbar. Das Design sollte dies berücksichtigen, damit meine ich vor allem die Eigenschaft in großer Stückzahl herstellbar und/ oder ohne E-Technik-Studium nachbaubar zu sein. Es gibt eine Menge Projekte, die zwar technisch teilweise extrem sexy sind, aber wo die Entwickler genau diese Dinge aus den unterschiedlichsten Gründen nicht berücksichtigen und somit niemals eine Chance haben, aus ihrer Nische herauszukommen. Und wer hat schon Lust, seine mehr oder weniger wertvoll Freizeit etwas zu widmen, dass nur von einigen, wenigen abhängt und jederzeit eingestellt werden kann? Ich nicht. Wenn man gleich zu Anfang darauf achtet, mindestens einen - oder besser gleich mehrere - kommerzielle Partner - ins Boot zu holen, sind einige Hürden deutlich niedriger.
Just my 2 Cents...
@Zerosight
Wenn Du so denkst ist das ok. Mir geht es bei diesem Projekt nicht darum aus irgendeiner Nische herauszukommen oder Geld damit zu machen. Mich interessiert einfach Regelungstechnik und das was passiert wenn man was programmiert. Es geht darum Dinge besser zu verstehen ... mehr nicht. Dann kommt noch hinzu das ich für die nächste Flugsaison eine Stabilisierung für meinen Nuri benötige und ich nichts gekauftes verwenden will. Dementsprechend wird die erste Firmware wahrscheinlich auch eine Stabilisierung für ein Flächenmodell mit RTH werden.
Gruß Kayle
Wenn Du so denkst ist das ok. Mir geht es bei diesem Projekt nicht darum aus irgendeiner Nische herauszukommen oder Geld damit zu machen. Mich interessiert einfach Regelungstechnik und das was passiert wenn man was programmiert. Es geht darum Dinge besser zu verstehen ... mehr nicht. Dann kommt noch hinzu das ich für die nächste Flugsaison eine Stabilisierung für meinen Nuri benötige und ich nichts gekauftes verwenden will. Dementsprechend wird die erste Firmware wahrscheinlich auch eine Stabilisierung für ein Flächenmodell mit RTH werden.
Gruß Kayle
hi,
also man könnte ja auch die leute selbst in der gui "mixen" lassen .. wenns ein stabi für "alles" werden soll, kann man ja neben vorgefärtigten setups auch jeden ausgang selbst belegbar machen ..
ich dachte da an flexible dropdowns mit zb:
oder auch:
.. alles in [] sind dropdowns die sich dynamisch ergeben jeh nach dem was man im vorigen ausgewählt hat ..
so könnte man dam mit auch all die heim bastelleien stabilisieren
gruß
Felix
also man könnte ja auch die leute selbst in der gui "mixen" lassen .. wenns ein stabi für "alles" werden soll, kann man ja neben vorgefärtigten setups auch jeden ausgang selbst belegbar machen ..
ich dachte da an flexible dropdowns mit zb:
Code:
ex 1: [50%] [GyroPID X] [+] [50%] [AnglePID X] [-] [100%] [RX ROLL] [Fertig]
Code:
[wenn] [RX AUX1] [<] [1500]
ex 1: [100%] [GyroPID X] [+] [100%] [RX ROLL] [Fertig]
[sonnst]
ex 1: [100%] [AnglePID X] [+] [100%] [RX ROLL] [Fertig]so könnte man dam mit auch all die heim bastelleien stabilisieren
gruß
Felix
Willste dann komplett neu entwickeln, oder Protokolle wie zb Mavlink nutzen? Ich mein, man muss ja das Rad nicht neu erfinden.
hi,
also man könnte ja auch die leute selbst in der gui "mixen" lassen .. wenns ein stabi für "alles" werden soll, kann man ja neben vorgefärtigten setups auch jeden ausgang selbst belegbar machen ..
ich dachte da an flexible dropdowns mit zb:
oder auch:
.. alles in [] sind dropdowns die sich dynamisch ergeben jeh nach dem was man im vorigen ausgewählt hat ..
so könnte man dam mit auch all die heim bastelleien stabilisieren
gruß
Felix
also man könnte ja auch die leute selbst in der gui "mixen" lassen .. wenns ein stabi für "alles" werden soll, kann man ja neben vorgefärtigten setups auch jeden ausgang selbst belegbar machen ..
ich dachte da an flexible dropdowns mit zb:
Code:
ex 1: [50%] [GyroPID X] [+] [50%] [AnglePID X] [-] [100%] [RX ROLL] [Fertig]
Code:
[wenn] [RX AUX1] [<] [1500]
ex 1: [100%] [GyroPID X] [+] [100%] [RX ROLL] [Fertig]
[sonnst]
ex 1: [100%] [AnglePID X] [+] [100%] [RX ROLL] [Fertig]so könnte man dam mit auch all die heim bastelleien stabilisieren
gruß
Felix
Also ich verstehe die fixierung auf den Atmega irgendwie nicht. Alle moderneren Prozessoren wie z.B. der STM32 kann genau das was ein Atmega kann auch und ist dabei wesentlich schneller, hat wesentlich mehr Speicher und vorallem auch wesentlich mehr Timer.
Und ich finde irgendwie auch, dass es mal Zeit für was neues wird. Wenn man einfach wiedr nur das selbe verbaut wie alle anderen haben ist das doch total uninteressant. Zumal man dann auch echt keine neue Hardware entwickeln muss sondern einfach eine der inzwischen 1000 verschiedenen FCs nehmen kann und dafür die Firmware schreiben kann. Wäre jedenfalls billiger als eine Eigenentwicklung.
Und ich finde irgendwie auch, dass es mal Zeit für was neues wird. Wenn man einfach wiedr nur das selbe verbaut wie alle anderen haben ist das doch total uninteressant. Zumal man dann auch echt keine neue Hardware entwickeln muss sondern einfach eine der inzwischen 1000 verschiedenen FCs nehmen kann und dafür die Firmware schreiben kann. Wäre jedenfalls billiger als eine Eigenentwicklung.
Ja genau. Irgendwie wird es Zeit für was "anderes". Dieser STM32 sitzt schon auf mehreren FC´s. Den Xmega findet man nicht so häufig als Controller ( kenne nur 1 OpenSource und 1 komerzielles mit Atxmega ). Und dann kommt noch für mich ein sehr wichtiger Punkt. Ich kann und werde keinen STM32 einsetzen weil ich kein C kann. So einfach ist das manchmal Ich kann BASCOM und das ist nur für Atmel Controller verfügbar.
Gruß Kayle
PS: Der Atxmega ist auch ein moderner Controller
Ich kann BASCOM und das ist nur für Atmel Controller verfügbar.Gruß Kayle
PS: Der Atxmega ist auch ein moderner Controller
SD Karte würde ich eher nicht verwenden...durch die Vibrationen kanns dir schnell passieren dass die aus dem halter rutscht. Ist mir damals schon beim APM2 mit dem EEprom passiert
Gruß Kayle
- Status
