Alex K. hat geschrieben:...
passt alles zusammen Man müsste nur noch die Servowege begrenzen und die Servomittenstellung implementieren... und dann halt das Schwenken entsprechend einbinden, dass im nach vorne geschwenkten Zustand nur noch Pitch gesteuert wird... aber im Grund ist das schon alles soweit da was man bräuchte...

abgesehen davon, das beim schwenken auch die zugvektoren von ROLL auf GIER wechseln.

Günti hat geschrieben:abgesehen davon, das beim schwenken auch die zugvektoren von ROLL auf GIER wechseln.

Moin Günti,

das ist aber egal, wenn man im Flächenmodus Pitch nur noch gemeinsam ansteuert...
Der Funktions-Kanal-Mischer der an Board kommt, wird deutlich mehr machen als nur dies...
Wir überlegen auch einen Fluggeschwindigkeitssensor wie z.B. diesen http://www.sm-modellbau.de/shop/product ... 6&cPath=11 von dem Mischer auswerten zu lassen und in Abhängigkeit dessen (bzw. des Rotorgondel-Kippwinkels) die dann benötigten Mischfunktionen hoch- bzw. runterregeln...

Viele Grüße
Mirko

Na - irgendwann wird auch bei der MultiWii Software ne GPS Unterstützung kommen - da kann man ja dann auch die Geschwindigkeit ermitteln.


MFG
speedy

Das wär auch ne Idee

Erst mal muss aber der 450er mit dem 3-Blatt und dem MultiWii-FBL fliegen, dann müssen die Rotorköpfe fertig konstruiert werden, dann das Flugzeug ausgelegt und konstruiert werden, dann muss noch alles gefertigt und gebaut werden... und einen Rumpf brauchen wir auch noch... wer weiss was es bis dahin noch alles geben wird für das MultiWii-Projekt

Gruß, Alex

GPS ist zur Geschwindigkeitsermittlung völlig ungeeignet. Zum einen können Windeinflüsse nicht berücksichtigt werden und zum anderen beruht die Geschwindigkeitsberechnung auf der Standortermittlung in der ersten Ableitung nach der Zeit. Das Verfahren funktioniert nur bei größeren Zeitintervallen hinreichend genau. Der Nachteil bei der Staudruckmethode ist wiederum, dass nur die Geschwindigkeit in der Längsrichtung halbwegs sauber ermittelt werden kann. Seitliches Schieben oder eine Rückwärtsbewegung kann man so nicht messen.

Alex K. hat geschrieben:Erst mal muss ...

Eben deswegen. Die ersten GPS Platinen sind ja schon in der Testanfertigung für Testprogrammierungsspielchen ... und bis ihr das alles gebaut habt, funktioniert das Zeug dann auch.

echo.zulu hat geschrieben:GPS ist zur Geschwindigkeitsermittlung völlig ungeeignet. Zum einen können Windeinflüsse nicht berücksichtigt werden und zum anderen beruht die Geschwindigkeitsberechnung auf der Standortermittlung in der ersten Ableitung nach der Zeit. Das Verfahren funktioniert nur bei größeren Zeitintervallen hinreichend genau.

Na - für Windeinflüsse hat man doch den Beschleunigungssensor. Und - was heißt "größere Zeitintervalle" ? - man ist ja nun auch nicht nur ne Sekunde in der Luft, wenn alles planmäßig funktioniert.


MFG
speedy

Alex K. hat geschrieben:...
Erst mal muss aber der 450er mit dem 3-Blatt und dem MultiWii-FBL fliegen,

dann soll ich also mit dem GyroBot 700 für meinen 500er heli noch warten

Günti hat geschrieben:

Alex K. hat geschrieben:...
Erst mal muss aber der 450er mit dem 3-Blatt und dem MultiWii-FBL fliegen,

dann soll ich also mit dem GyroBot 700 für meinen 500er heli noch warten

Wenn Du mit ner nur marginal getesteten Beta-Version die sicherlich noch einige Bugs hat und von der noch keiner weiss ob sie wirklich funktioniert fliegen willst, ja

Ich hab da noch so viele offene Punkte und Dinge denen ich noch auf den Grund gehen will weil ich sie noch nocht verstehe, dass das sicherlich noch ne Weile dauert bis das alles mal flugfähig ist...

Gruß, Alex

Moin moin,

nachdem ich in den letzten Tagen mich mit Ellipsen und den Eilinien beschäftigt habe, läuft mein Progamm zur Erstellung dieser jetzt.

Da der Rumpfquerschnitt nicht überall eine Ellipse ist, sondern u.a. in dem Cockpit-Bereich unten etwas "ausgebeult" ist, wollte ich diese Form automatisiert erstellen können. Mein Wunsch ist es im AutoCAD einfach nur die drei Kontur-Linien (Ober- und Unterkannte der Seitenansicht, bzw. Breite in der Draufsicht) bzw. die Linie der größten Breite (Verbindungs-Linie der Ellipsen-Achsen) und die beiden "Ausbeullinien" anzuklicken und es wird mir automatisch ein 3D Rumpf incl. aller benötigten Spannten errechnet und gezeichnet.

Der erste Part des Programms (Erzeugung der Ellipsen bzw. ausgebeulten Ellipsen = Eilinien) ist fertig. Hier die ersten Bilder was ich überhaupt meine bzw. mache... Ich habe einen "Kontrollpunkt bei 75% der einen Ellipsen-Halbachse festgelegt. Bei einer normal-Ellipse (hier dick und rot gezeichnet) ist dieser (in meiner Definition) 100% hoch. In Bezug auf die Halbachse ergibt sich eine Höhe von ca. 66%
Je nach Anforderung schiebe ich diesen Punkt rauf, oder runter. Die jetzt gezeichnete Eilinie soll die Koordinaten und Tangenten der Halbachsenpunkte übernehmen, jedoch auch noch durch den verschobenen Kontrollpunkt laufen. Viele Grüße
Mirko

Hallo Husi

So einfach wie du dir das vorstellst in Autocad geht das nicht. Ich zeichne selber seit Jahren mit Acad und habe damit meine ORION und meine Excelsior konstruiert.
Bist du Acad Spezialist?? Machbar ist das in Acad, aber du brauchst dafür viel Zeit.

Grüsse

Alf-1234

Moin Alf,

die "viele Zeit" stecke ich in die Programme, die ich schreibe. Die zeichnen mir dann die Dinge im AutoCAD. Sprich ich nutzte AutoCAD als Programmierumgebung...

Viele Grüße
Mirko

Hi,

ich will hier auch mal ein bisschen berichten was ich so mache in dem Projekt... im WiiCopter-Riesen-Thread hab ich ja immer wieder mal ein bisschen was geschrieben...

Ich habe mir ein Arduino Pro Mini, einen Wii Motion + und einen Nunchuck gekauft und die Software dafür ein bisschen umgeschrieben. Mit einem kleinen Lochraster-Breakout-Board habe ich 4 Servos angeschlossen, um die Taumelscheibe und das Heck entsprechend anzusteuern. Das alles hängt an meinem 450er Sonix, auf dem ein 3-Blatt-Kopf von Mirko drauf ist und mit dem das alles erst mal ausprobiert werden soll ob die "MultiWii"-Technik für unser Projekt umgestrickt werden kann...

Dabei habe ich folgende Dinge am Code geändert:

• Regelung ist sofort nach dem Einschalten aktiv
• Servos werden in Mittelstellung gefahren nach dem Einschalten
• Servos werden mit einem Offset belegt um die Mittelstellung einzustellen und die TS 90° ausrichten zu können
• Wirkrichtung für Pitch, Roll, und Nick kann verändert werden
• Min- und Max-Pitchwerte werden über einen Faktor eingestellt
• "MinThrottle" eingeführt, damit Regelungverhalten wie bei "MaxThrottle" funktioniert
• "Mittelstellung ohne Regelung" eingebaut damit man die Rotorblätter einstellen kann

Nachdem ich die Servos ne ganze Weile mit 488Hz angesteuert habe (danke Arnd für den Hinweis... ) habe ich erst die ISR Routine geändert, sodass die Servos mit 50Hz angesteuert werden. Das hatte allerdings den unerwünschten Nebeneffekt, dass beim Initialisieren alle Servos in eine Endstellung gefahren sind, wo blöderweise was im Weg war und so alle Servos auf "Block" liefen... nun habe ich die servo.h Library eingebunden und steuere die Servos so an, die Cycletime ging so von 3000 auf 6000 hoch, ich denke aber nicht dass das ein Problem werden wird da beim FBL-System die Regelung eh nicht so schnell und feinfühlig sein muss wie beim Multicopter... jedenfalls bleiben die Servos nun in der Mittelstellung beim Einschalten, was erst mal wichtiger war... Die Regelparameter P, I und D müssen drastisch verkleinert werden, damit die Taumelscheibe nicht zu hektisch auf Bewegungen reagiert. Ich habe hierbei ein bisschen bei meinem 500er mit Microbeast abgeschaut, sodass sich die TS nun ungefähr so "träge" bewegt wie bei diesem Heli.

Und weil mir Programmieren inzwischen so viel Spaß macht hab ich den Code jetzt "bereinigt", d.h. "TRI" wurde zu "FBL" und "QUADX" wurde zu "TILTROTOR", und alles andere ist rausgeflogen (auch alles was mit GIMBAL, SERVO-TILT, FLYING-WING und CAMTRIG zu tun hat) um den Code übersichtlicher zu machen... Leider habe ich dabei immer ein wenig zu viel rausgeworfen, jedenfalls haben danach einige Dinge nicht mehr funktioniert, hier bin ich noch dabei damit ich einen übersichtlicheren Code habe, der auch die Heli-spezifischen, korrekten Bezeichnungen für Roll, Nick, Pitch und Yaw hat... gestern Abend lief jedenfalls schon mal die erste Vorab-Version des "Kurz-Codes"

Und nebenher habe ich auch noch den Flieger mit einem NACA2412 und hinten einem NACA0010 ausgelegt, ich arbeite immer wieder mal ein bisschen am Rotorkopf und an der Schwenkmechanik und am Riementrieb... allerdings fesselt mich die Programmiererei doch sehr, sodass ich zum konstruieren momentan nicht viel Zeit habe... aber die Elektronik muss für das Projekt funktionieren, sonst haben wir einen Tilt-Rotor der sich nicht steuern lässt...

Gruß, Alex

Alex K. hat geschrieben:dass beim Initialisieren alle Servos in eine Endstellung gefahren sind, wo blöderweise was im Weg war und so alle Servos auf "Block" liefen... nun habe ich die servo.h Library eingebunden und steuere die Servos so an

Hmm ... na ob das der richtige Weg ist, in einem Code Servos etc. mit zwei unterschiedlichen Varianten anzusteuern.

Alex K. hat geschrieben: hab ich den Code jetzt "bereinigt"

Soviel zu "ich möchte die Updates von Alex auch immer mitmachen können".


MFG
speedy

speedy hat geschrieben:

Alex K. hat geschrieben:dass beim Initialisieren alle Servos in eine Endstellung gefahren sind, wo blöderweise was im Weg war und so alle Servos auf "Block" liefen... nun habe ich die servo.h Library eingebunden und steuere die Servos so an

Hmm ... na ob das der richtige Weg ist, in einem Code Servos etc. mit zwei unterschiedlichen Varianten anzusteuern.

Nee, wird jetzt nur noch über die servo.h library angesteuert, sonst ist nix anderes mehr da.

speedy hat geschrieben:

Alex K. hat geschrieben: hab ich den Code jetzt "bereinigt"

Soviel zu "ich möchte die Updates von Alex auch immer mitmachen können".

Ja... so dachte ich mal... Aber die Anforderungen an den Heli sind so unterschiedlich zu denen des MultiWiiCopters, dass es einfach blödsinn gewesen wäre den Schritt nicht zu tun... die MultiWii-Software ist inzwischen dermaßen komplex, dass es jedesmal ein rumgesuche nach der richtigen Stelle im Code war... jetzt ist es schön übersichtlich und es kommt auch nicht mehr zu Verwechslungen... wenn sich am MutliWii-Code was ändert, kann ich die entsprechenden Stellen ja auch wieder einfügen... Habe gerade die neueste Version mit allen Änderungen aufgespielt die ich noch vorhatte, jetzt fällt mir nix mehr ein was ich noch ändern wollte... dann kann's bald mal los gehen ans Testen...

Ich will allerdings den alten Gyro noch verwenden... das Heckservo läuft irgendwie nicht so wie ich es gerne hätte... wahrscheinlich muss ich da an den Einstellungen noch ein bisschen rumspielen...

Ich muss mir jetzt nur noch überlegen wie ich die Daten im Flug mitloggen kann... ich habe ein BTM-222 am Arduino hängen, mit dem ich die Daten zum Laptop senden kann, nur kann ich da beim Fliegen ja nicht ständig drauf gucken... ich hab schon überlegt das MultiWiiConf auch umzuprogrammieren, dass ich die Heli-spezifischen Einstellungen (Wirkrichtungen, Servo-Mittelstellungen) auch in einer GUI vornehmen kann und nicht jedes Mal den Source-Code neu flashen muss... mal sehen was mir dazu noch einfällt...

Gruß, Alex

Hi Alex,

ich denke auch nicht, dass sich an den Routinen, die die Regelung betreffen, im MWC-Code noch viel ändern wird, in den letzten Versionen hat sich da wenig getan (im Moment geht die Entwicklung wohl eher in Richtung Einbinden anderer Sensoren). Ausserdem geht nichts über überschaubaren Code.

Dass die Cycle Time sich durch die servo.h Lib verdoppelt, wundert mich etwas. Ich könnte mir schon vorstellen, dass sich das negativ auf die Empfindlichkeit der PID-Regelung auswirkt, auch wenn die angesteuerten Servos sowieso etwas träger sind. (Irgendwie hab ich da ständig das Abtasttheorem im Hinterkopf, kann es aber noch nicht richtig ausformulieren... ist alles zu lange her...)

Mitloggen der Daten im Flug... klingt nach einem Job für mein Konfigurationsprogramm. Dazu bräuchtest du an sich nur ein zweites Mini Pro, ein Keypad Shield und ein MicroSD Breakout (das Keypad Shield braucht man nur zur Einstellung, im Betrieb kann das abgezogen werden).