"QUANTON FLIGHT CONTRO rev. 1" , ein interessantes Teil?
- Themenstarter JUERGEN_
- Beginndatum
Hey jungs,
ich wollte mein quanton heute mal richtig einstellen, dabei geht es mir darum das er nicht nur gut fliegt(ihn an die stelle zu bekommen ist kein problem), sondern auch darrum das ich weiß was ich tue und einstelle.
Wäre nett wenn mir helfen könnte der von sich sagt das er sich damit gut auskennt
ich wollte mein quanton heute mal richtig einstellen, dabei geht es mir darum das er nicht nur gut fliegt(ihn an die stelle zu bekommen ist kein problem), sondern auch darrum das ich weiß was ich tue und einstelle.
Wäre nett wenn mir helfen könnte der von sich sagt das er sich damit gut auskennt
Und weitergekommen scheinen die auch nicht zu sein. Das hätte aber sicherlich eine gewissen Reiz, wenn das für CF umgesetzt werden würde.
Aber diese sind nicht ganz ohne Fehler, bzw. fehlen bei einigen Bauteilen die Bezeichnungen (Werte), weiterhin lässt sich das Boardlayout mit der neuen EAGLE-Version nicht ohne weiteres so einfach bearbeiten, weil teilweise die lib's aktualisiert worden und beim Verschieben von Bauteilen Fehler/Ungereimtheiten auftreten.
Schöne Sache, aber scheinbar noch nicht ganz zuende gebracht oder extra einige Stellen "optimiert".
Aber diese sind nicht ganz ohne Fehler, bzw. fehlen bei einigen Bauteilen die Bezeichnungen (Werte), weiterhin lässt sich das Boardlayout mit der neuen EAGLE-Version nicht ohne weiteres so einfach bearbeiten, weil teilweise die lib's aktualisiert worden und beim Verschieben von Bauteilen Fehler/Ungereimtheiten auftreten.
Schöne Sache, aber scheinbar noch nicht ganz zuende gebracht oder extra einige Stellen "optimiert".
Wenn Du mit einem originalen Quanton vergleichst, sind an den freien Stellen keine Bauelemente. Das hat andere Gründe. Die beiden sind fertig. Ich kann ja mal meinen HHn für ein Photoshooting auseinanderbauen.
Was CF angeht habe ich eine eigene Meinung. Ich kann nicht verstehen, was das weglassen von irgendwelchen erklärenden Kommentaren für besseren Code erzeugen soll. Das direkte Schreiben in Hardwareregister ohne HAL ist zwar schneller und sorgt wirklich für kleineren Code, aber die Timer sind bei F3/F4 32 statt 16 bit gross. Will man CF darauf anpassen muss man sich spätestens jetzt Gedanken darüber machen. Ich selbst habe mal vor einer Weile angefangen TL für Raspberry lauffähig zu machen. Das Projekt ruht derzeit (jetzt nicht gleich motzen), aber grundsätzlich würde es gehen.
PS: Habe im HHn Thread mal ein paar Fotos hochgeladen. Das gezeigte Quanton ist eines von den weiter oben.
Was CF angeht habe ich eine eigene Meinung. Ich kann nicht verstehen, was das weglassen von irgendwelchen erklärenden Kommentaren für besseren Code erzeugen soll. Das direkte Schreiben in Hardwareregister ohne HAL ist zwar schneller und sorgt wirklich für kleineren Code, aber die Timer sind bei F3/F4 32 statt 16 bit gross. Will man CF darauf anpassen muss man sich spätestens jetzt Gedanken darüber machen. Ich selbst habe mal vor einer Weile angefangen TL für Raspberry lauffähig zu machen. Das Projekt ruht derzeit (jetzt nicht gleich motzen), aber grundsätzlich würde es gehen.
PS: Habe im HHn Thread mal ein paar Fotos hochgeladen. Das gezeigte Quanton ist eines von den weiter oben.
Zuletzt bearbeitet:
Stimmt, ist mir auf den ersten Blick nicht so aufgefallen.
Sicherlich hat jede SW für FC's ihre Daseinberechtigung und Vor-/Nachteile. Ich bin durch das stöbern im www auf CF aufmerksam geworden und fand sie eigentlich nicht so schlecht, auch weil dort nach meinem Erachten etwas Bewegung drin ist. Dies kann man ja nicht bei jedem OpenSource feststellen. Mit TauLabs habe ich mich bisher noch nicht eingehend beschäffigt, aber werde das wohl mal tun müssen, um mir einen tieferen Überblick zu verschaffen.
Ich bin halt auf der Suhe nach einer FC mit mehreren Anschlußmöglichkeiten, wie man hier so liest bin ich sicherlich nicht der einzige, der auf der Suche ist.
Tja und das mit dem Umschreiben von den Codes ist nicht so mein Ding, weil ich darin nicht die tiefgehende Erfahrung habe , um mich da mal eben ranzusetzen.
Also bleibt zum Schluss nur, testen, Erfahrungen sammeln und ggf. weitersuchen.
Sicherlich hat jede SW für FC's ihre Daseinberechtigung und Vor-/Nachteile. Ich bin durch das stöbern im www auf CF aufmerksam geworden und fand sie eigentlich nicht so schlecht, auch weil dort nach meinem Erachten etwas Bewegung drin ist. Dies kann man ja nicht bei jedem OpenSource feststellen. Mit TauLabs habe ich mich bisher noch nicht eingehend beschäffigt, aber werde das wohl mal tun müssen, um mir einen tieferen Überblick zu verschaffen.
Ich bin halt auf der Suhe nach einer FC mit mehreren Anschlußmöglichkeiten, wie man hier so liest bin ich sicherlich nicht der einzige, der auf der Suche ist.
Tja und das mit dem Umschreiben von den Codes ist nicht so mein Ding, weil ich darin nicht die tiefgehende Erfahrung habe , um mich da mal eben ranzusetzen.
Also bleibt zum Schluss nur, testen, Erfahrungen sammeln und ggf. weitersuchen.
Wenn es Dir um eine Plattform mit Entwicklung geht, kannst Du auch TL nehmen.
* Achtung Werbung*
Das Quanton kann IMO alles, was man sich wünschen kann. Serielle Ports ohne Ende und damit digitale Empfangsprotokolle und Telemetrie, GPS, Waypoints, Steuerung über Android-Tablet und nicht zu vergessen Userscripte auf der FC über picoC.
James macht gerade der Logfilesystem auf der FC fit und ich bin gerade mit der Implementierung von OneShot fertig die sollte auch bald dabei sein.
* Werbung aus *
Also es passiert schon eine Menge.
* Achtung Werbung*
Das Quanton kann IMO alles, was man sich wünschen kann. Serielle Ports ohne Ende und damit digitale Empfangsprotokolle und Telemetrie, GPS, Waypoints, Steuerung über Android-Tablet und nicht zu vergessen Userscripte auf der FC über picoC.
James macht gerade der Logfilesystem auf der FC fit und ich bin gerade mit der Implementierung von OneShot fertig die sollte auch bald dabei sein.
* Werbung aus *
Also es passiert schon eine Menge.
Dann gebe ich auch noch meinen Senf dazu: Ich habe den Quanton gekauft, als dieser Thread hier erst wenige Seiten hatte, da ich das Gefühl hatte, es wäre etwas Gutes und der Preis war auch wirklich unschlagbar, wenn man es mit der Konkurrenz aus Amerika vergleicht. Ich muss sagen, ich bin Begeistert. Das Setup und die Konfiguration war einfach, nachdem ich ein bisschen herumprobiert hatte. Der erste Flug lief problemlos. Als dann PicoC mehr und mehr Funktionen bekam, habe ich auch damit herumgespielt, es ist wirklich genial. Ich bin noch sehr unerfahren, was Softwareentwicklung angeht, habe es aber trotzden gut hingekriegt, die neusten Features im Repo von ernieift herunterzuladen und zu kompilieren. Die Weiterentwicklung geht wirklich rasant, es kommen gefühlt jede Stunde neue Funktionen hinzu.
Was ich hingegen schwierig finde, ist die Implementierung meines eigenen Codes direkt in die Firmware. Das liegt sicher Teilweise an der mangelnden Erfahrung und daran, dass ich mich noch nicht lange genug in das Projekt eingearbeitet habe, jedoch fände ich es auch schön, ein bisschen mehr Dokumentation zu finden, besonders um Anfängern den Einstieg in die Entwicklung zu erleichtern. Naja, wenn ich so ein Projekt unentgeltlich machen würde, hätte ich sicher auch keine Lust Bücher zu schreiben und n00bs auf die Sprünge zu helfen.
Nochmal ein gosses Lob an das TauLabs Team!
Was ich hingegen schwierig finde, ist die Implementierung meines eigenen Codes direkt in die Firmware. Das liegt sicher Teilweise an der mangelnden Erfahrung und daran, dass ich mich noch nicht lange genug in das Projekt eingearbeitet habe, jedoch fände ich es auch schön, ein bisschen mehr Dokumentation zu finden, besonders um Anfängern den Einstieg in die Entwicklung zu erleichtern. Naja, wenn ich so ein Projekt unentgeltlich machen würde, hätte ich sicher auch keine Lust Bücher zu schreiben und n00bs auf die Sprünge zu helfen.
Nochmal ein gosses Lob an das TauLabs Team!
Ich finde, das WIKI gibt schon eine Menge her.
ich bin da stets bemüht.
Leider steht mir mein mangelndes Englisch im weg, sonst wäre da mehr.
Aber Abhilfe ist in Sicht. Ich schreibe in Deutsch und ein Kollege macht das dann ins Englische fertig.
Wenn Dir speziell was fehlt, gebe bitte einen Hinweis, dann habe ich was, wo ich bevorzugt dran gehen kann, wenn ich das nötige Wissen überhaupt habe!
Im übrigen kann jeder am Wiki arbeiten, der angemeldet bei GitHub ist!
ich bin da stets bemüht.
Leider steht mir mein mangelndes Englisch im weg, sonst wäre da mehr.
Aber Abhilfe ist in Sicht. Ich schreibe in Deutsch und ein Kollege macht das dann ins Englische fertig.
Wenn Dir speziell was fehlt, gebe bitte einen Hinweis, dann habe ich was, wo ich bevorzugt dran gehen kann, wenn ich das nötige Wissen überhaupt habe!
Im übrigen kann jeder am Wiki arbeiten, der angemeldet bei GitHub ist!
Das könnte Dir ronco aka Felix von flyduino sicher besser erklären. Aber ich versuch's mal.
Normalerweise funktioniert die Regelschleife im Copter so, dass die Sensoren gelesen, der PID gerechnet und die Servo-/Motor-PWM-Werte geschrieben werden.
Leider ist die Rate mit der die Sensoren gelesen werden normalerweise nicht synchron zur PWM-Frequenz. Das bedeutet, dass im schlechtesten Fall (nach Shannon) 2/PWM-Frequenz an Zeit vergeht bevor die neuen Reglersteuerwerte am ESC ankommen. Das bedeutet eine Totzeit in der Regelung und kann Schwingungen verursachen.
Diesen Teufelskreis versucht OneShot dadurch zu durchbrechen, dass es keine feste PWM-Frequenz gibt, sondern die Steuerimpulse direkt nach Berechnung der PIDs ausgegeben werden. Damit hängt der Motorupdate an der Sensorrate. Die MPU (Sensorrate) kann man im Hardware-Widget einstellen. Je höherer, desto öfter wird der PID gerechnet. Das hilft bei 400Hz PWM-Frequenz leider nicht viel.
Bei OneShot sind z.Z. max. 2000Hz sicher zugelassen (ich habe es bis 39xxHz im Versuchsaufbau getestet). Die Impulse werden nicht im 1µs-Raster sondern im 1/12µs-Raster übertragen um nicht die Auflösung zu verlieren. Der Regler tastet die Pulse mit 8MHz ab.
OneShot geht derzeit mit flyduino-Reglern (UltraESC und KISS). Für BLHeli ist der Code im Betastadium.
Ich kriege im Januar meine neuen Regler und habe mir noch eine Leora bestellt. Sobald das alles angekommen ist, mache ich OutDoor-Tests.
Normalerweise funktioniert die Regelschleife im Copter so, dass die Sensoren gelesen, der PID gerechnet und die Servo-/Motor-PWM-Werte geschrieben werden.
Leider ist die Rate mit der die Sensoren gelesen werden normalerweise nicht synchron zur PWM-Frequenz. Das bedeutet, dass im schlechtesten Fall (nach Shannon) 2/PWM-Frequenz an Zeit vergeht bevor die neuen Reglersteuerwerte am ESC ankommen. Das bedeutet eine Totzeit in der Regelung und kann Schwingungen verursachen.
Diesen Teufelskreis versucht OneShot dadurch zu durchbrechen, dass es keine feste PWM-Frequenz gibt, sondern die Steuerimpulse direkt nach Berechnung der PIDs ausgegeben werden. Damit hängt der Motorupdate an der Sensorrate. Die MPU (Sensorrate) kann man im Hardware-Widget einstellen. Je höherer, desto öfter wird der PID gerechnet. Das hilft bei 400Hz PWM-Frequenz leider nicht viel.
Bei OneShot sind z.Z. max. 2000Hz sicher zugelassen (ich habe es bis 39xxHz im Versuchsaufbau getestet). Die Impulse werden nicht im 1µs-Raster sondern im 1/12µs-Raster übertragen um nicht die Auflösung zu verlieren. Der Regler tastet die Pulse mit 8MHz ab.
OneShot geht derzeit mit flyduino-Reglern (UltraESC und KISS). Für BLHeli ist der Code im Betastadium.
Ich kriege im Januar meine neuen Regler und habe mir noch eine Leora bestellt. Sobald das alles angekommen ist, mache ich OutDoor-Tests.
Du kannst die Verstärkung viel höher nehmen als sonst. Damit reagiert der Copter besser.
Zur Totzeit:
Stell Dir ein Förderband vor. Du willst eine entsprechende Fördermenge (bei uns Schub) haben. Der Regler merkt: Es ist zu wenig. Er legt 'ne Schippe drauf. Da das Förderband zunächst die Schippe nur "speichert" und erst später abgibt, legt der Regler beim nächsten Durchlauf eine noch größere Schippe drauf. Das erste Mal war ja zu wenig. Später kommt eine zu hohe Solldrehzahl bei den Motoren an. So kommt das ganze System ins Schwingen. Damit das nicht passiert, müssen P und I runtergenommen werden. Damit wird der Regelkreis aber schwammiger.
Zur Totzeit:
Stell Dir ein Förderband vor. Du willst eine entsprechende Fördermenge (bei uns Schub) haben. Der Regler merkt: Es ist zu wenig. Er legt 'ne Schippe drauf. Da das Förderband zunächst die Schippe nur "speichert" und erst später abgibt, legt der Regler beim nächsten Durchlauf eine noch größere Schippe drauf. Das erste Mal war ja zu wenig. Später kommt eine zu hohe Solldrehzahl bei den Motoren an. So kommt das ganze System ins Schwingen. Damit das nicht passiert, müssen P und I runtergenommen werden. Damit wird der Regelkreis aber schwammiger.
So der letzte Post für dieses Jahr. Habe eben mal probiert auf meinem Sparky was mit OneShot zu machen.
Normalerweise habe ich MIN/NEUTRAL/MAX auf 1000/1050/2000 und 400Hz PWM-Frequenz.
Mit aktivertem OneShot sind es (mal 12) 12000/12600/24000. Die Updaterate liegt dann bei ca. 2ms. Ich bin nur kurz abgehoben um zu testen, ob alles funktioniert. Fliegen tut er noch.
Nächstes Jahr kann ich mal vergleichen, ob sich etwas beim Autotune verändert. Übrigens sind es keine KISS ESC sondern BLHeli mit normaler Firmware.
Also dann… guten Rutsch
jörg
Normalerweise habe ich MIN/NEUTRAL/MAX auf 1000/1050/2000 und 400Hz PWM-Frequenz.
Mit aktivertem OneShot sind es (mal 12) 12000/12600/24000. Die Updaterate liegt dann bei ca. 2ms. Ich bin nur kurz abgehoben um zu testen, ob alles funktioniert. Fliegen tut er noch
.Nächstes Jahr kann ich mal vergleichen, ob sich etwas beim Autotune verändert. Übrigens sind es keine KISS ESC sondern BLHeli mit normaler Firmware.
Also dann… guten Rutsch
jörg
