Der WII-Copter ( Selbstbau-Projekt )

[marix]

hatte leider nurnoch gleb/transparend und ein paar fetzen organe .. aber das kann man ja nochmal umziehn

Ui,

was hast Du dem denn eingesetzt und wo bekommt man die Organe???

[Jingej]

hatte leider nurnoch gleb/transparend und ein paar fetzen organe .. aber das kann man ja nochmal umziehn

Ui,

was hast Du dem denn eingesetzt und wo bekommt man die Organe???

...ich denk mal, er arbeitet darauf hin: http://www.perrypedia.proc.org/wiki/Org ... Raumschiff

[ronco]

hatte leider nurnoch gleb/transparend und ein paar fetzen organe .. aber das kann man ja nochmal umziehn

Ui,

was hast Du dem denn eingesetzt und wo bekommt man die Organe???

...ich denk mal, er arbeitet darauf hin: http://www.perrypedia.proc.org/wiki/Org ... Raumschiff

ich hab natürlich mein herzblut verbaut!

.. etwas mehr konzentrat beim tippen würde mir bestimmt nicht schaden

gruß

Felix

[Jingej]

mal was andres, ronco... also eigentlich nix andres sondern zum thema:...
wie hast du das mit dem gier gelöst bei den unterschiedlichen motor/propeller-größen, ich hab da auch "so'n ding" gebaut mit 2 kleinen und 2 großen propellern, nur wenn ich gieren will, kippt mir "das ding" eben (logischerweise) immer weg...

http://www.youtube.com/watch?v=vTmrJ_hTclM

[marix]

Ja bestimmt, und mir würde Dein Konzentrat sicher beim Fliegen helfen.
Habe meinen "Großen" gestern ausgeführt, als ich glaubte, einen Baum stutzen zu müssen, quittierten die Rotoren diese Idee mit einer Selbstzerlegung.
Hatte die Teile von HK, die haben aktuell eine recht große Auswahl, als ich diese jedoch ausgepackt habe, viel mir gleich der enorme Qualitätsunterschied zu den hiesigen auf, sind sehr zerbrechlich und schlecht verarbeitet.
Ich denke, dem einen oder anderen würden die beim Motoranlaufen schon zerbröseln, mir reichen diese zunächst, wenn ich dann materialschonender und vor allem eindrucksvoller Fliegen kann, werde ich wieder umsatteln.

Siehe Foto (mit den Resten der Props)

[ronco]

mal was andres, ronco... also eigentlich nix andres sondern zum thema:...
wie hast du das mit dem gier gelöst bei den unterschiedlichen motor/propeller-größen, ich hab da auch "so'n ding" gebaut mit 2 kleinen und 2 großen propellern, nur wenn ich gieren will, kippt mir "das ding" eben (logischerweise) immer weg...

http://www.youtube.com/watch?v=vTmrJ_hTclM

das kann so ja auch nicht gehn um per drehmoment zu gieren müssen so ja 2 motoren an einer seite stärker werden .. ich hatte dir doch mal (vor gefühlten 1000 posts) einen sketch schnipsel gemacht der das mit nem servo lösen würde. weil ich denke 2 groß, 2 klein geht nur wenn zum gieren ein großer und ein kleiner schneller wird. bei meinem setup hatte sich ja auch gezeigt das es beim rollen etwas zur seite zieht weil hier ja auch der große mehr drehmoment veruhrsacht. habe das jetzt aber mit nem anderen mixtable setup gelößst..

die 2 großen bekommen nur 2/3 roll, sommit gleicht sich das was aus .. und den rest regelt er dann mim yaw gyro nach.

Code: Alles auswählen

  #ifdef QUADX
    motor[0] = PIDMIX(-1,+1,-1); //REAR_R
    motor[1] = PIDMIX(-2/3,-1,+1); //FRONT_R
    motor[2] = PIDMIX(+1,+1,+1); //REAR_L
    motor[3] = PIDMIX(+2/3,-1,-1); //FRONT_L
  #endif

du köntest noch versuchen die 2 kleinen nach "hinten" zu legen und die dann nach aussen anwinkeln .. also ala vtail .. so würden die großen nur noch roll machen (und da muss halt dann das yaw gyro stabilisieren) und die kleinen quasi nurnoch yaw.

also nicht beide auf eine seite sondern rechts und links vom hinteren großen..

[edit] -.- das geht natürlich auch nicht .. weil so ja roll fehlt ... also würde ich mal behaupten .. keine chance ohne servo mit sonem setup[/edit]

gruß

felix

[Jingej]

mal was andres, ronco... also eigentlich nix andres sondern zum thema:...
wie hast du das mit dem gier gelöst bei den unterschiedlichen motor/propeller-größen, ich hab da auch "so'n ding" gebaut mit 2 kleinen und 2 großen propellern, nur wenn ich gieren will, kippt mir "das ding" eben (logischerweise) immer weg...

http://www.youtube.com/watch?v=vTmrJ_hTclM

das kann so ja auch nicht gehn um per drehmoment zu gieren müssen so ja 2 motoren an einer seite stärker werden .. ich hatte dir doch mal (vor gefühlten 1000 posts) einen sketch schnipsel gemacht der das mit nem servo lösen würde. weil ich denke 2 groß, 2 klein geht nur wenn zum gieren ein großer und ein kleiner schneller wird. bei meinem setup hatte sich ja auch gezeigt das es beim rollen etwas zur seite zieht weil hier ja auch der große mehr drehmoment veruhrsacht. habe das jetzt aber mit nem anderen mixtable setup gelößst..

die 2 großen bekommen nur 2/3 roll, sommit gleicht sich das was aus .. und den rest regelt er dann mim yaw gyro nach.

Code: Alles auswählen

  #ifdef QUADX
    motor[0] = PIDMIX(-1,+1,-1); //REAR_R
    motor[1] = PIDMIX(-2/3,-1,+1); //FRONT_R
    motor[2] = PIDMIX(+1,+1,+1); //REAR_L
    motor[3] = PIDMIX(+2/3,-1,-1); //FRONT_L
  #endif

du köntest noch versuchen die 2 kleinen nach "hinten" zu legen und die dann nach aussen anwinkeln .. also ala vtail .. so würden die großen nur noch roll machen (und da muss halt dann das yaw gyro stabilisieren) und die kleinen quasi nurnoch yaw.

also nicht beide auf eine seite sondern rechts und links vom hinteren großen..

[edit] -.- das geht natürlich auch nicht .. weil so ja roll fehlt ... also würde ich mal behaupten .. keine chance ohne servo mit sonem setup[/edit]

gruß

felix

also ich habs schon so geändert, dass die beiden großen und die beiden kleinen jeweils gegensätzlich laufen und auch entsprechend dadurch gieren "könnten" aber - durch die dadurch entstehende unterschiedliche drehzahl und daher auch tragkraft, sackt halt immer vorn oder hinten durch wenn man giert...
servos wollt ich eben grade nich verbaun, weils mir mechanisch zu elend ist... aber es wird mir wohl nix andres übrig bleiben, naja, liegt eh erstmal halb ausgeschlachtet zugunsten des tri in der ecke... war halt nur mal wieder so ne doofe idee....

[ronco]

also ich habs schon so geändert, dass die beiden großen und die beiden kleinen jeweils gegensätzlich laufen und auch entsprechend dadurch gieren "könnten" ...

hehe ne! die, die gegenleufig laufen können, wenn sie als paar angesprochen werden nicht gieren .. weil sich ihr drehmoment ja aufhebt. da es aber anderstrum darin enden würde das die 2 kleinen immer auf 100% laufen müssten um das drehmoment der großen auszugleichen, bleibt dir sogesehen nix anderes übrig. nur so kannst du halt nur gieren wenn ein großer und ein kleiner schneller wird .. und die befinden sich halt beide an einer seite und dann kippts halt wech.

gruß

felix

[Jingej]

nur so kannst du halt nur gieren wenn ein großer und ein kleiner schneller wird .. und die befinden sich halt beide an einer seite und dann kippts halt wech.

genauso ists momentan auch... egal... tonne ...

[ronco]

aus dem FPV forum von Tilman.. wollte mich nicht für ein psot anmelden .. wo ich doch gar kein FPV betreibe..
http://fpv-community.de/showthread.php? ... post133033

So Jungs, erstaunliches Resultat: Ich bin mit meinem X8 natürlich völlig in die falsche Richtung gegangen. Anstatt Gyro I zu verringern, um den X8 weniger zappelig zu machen, muss Gyro P hoch, um empfindlicher auf Lageabweichungen zu reagieren. Ich bin mittlerweile bei P 9.0, I 0,04 und D 40 und habe immer noch Luft nach oben. Und oh Wunder: Der TBE im ACC ist wie weggezaubert. Darauf hätte ich eigentlich früher kommen können: Der ACC wird dem Gyro ja nur hinzugeschaltet und wenn der Gyro schon nicht richtig stabilisiert, wird das Ganze mit dem ACC eine schwammige Angelegenheit.

hast du da einen mega drauf? wenn ja sind die hohen P werte "ganz normal" durch das 16-bit PWM.

vllt ist das schon die erklärung für den TBE.. mit dem 16-bit PWM und reglern die das auch wahrnehmen ist eine Standard einstellung von p=4 oder so einfach zu wenig.. ich würde mir das so erklären das eine von aussen herbeigefürhrte bewegung ja solange weiter geht bis die motoren reagieren.. und bei 8 bit pwm dauert es ja nunmal länger bis die im code errechnete korrektur an den motor kommt .. wenn z.b. nur eine gas korrektur von 5us notig ist, passiert bei 8bit ja nochnix weils nur in 8er schitten rechnet.

gruß

felix

[Jingej]

aus dem FPV forum von Tilman.. wollte mich nicht für ein psot anmelden .. wo ich doch gar kein FPV betreibe..
http://fpv-community.de/showthread.php? ... post133033

So Jungs, erstaunliches Resultat: Ich bin mit meinem X8 natürlich völlig in die falsche Richtung gegangen. Anstatt Gyro I zu verringern, um den X8 weniger zappelig zu machen, muss Gyro P hoch, um empfindlicher auf Lageabweichungen zu reagieren. Ich bin mittlerweile bei P 9.0, I 0,04 und D 40 und habe immer noch Luft nach oben. Und oh Wunder: Der TBE im ACC ist wie weggezaubert. Darauf hätte ich eigentlich früher kommen können: Der ACC wird dem Gyro ja nur hinzugeschaltet und wenn der Gyro schon nicht richtig stabilisiert, wird das Ganze mit dem ACC eine schwammige Angelegenheit.

hast du da einen mega drauf? wenn ja sind die hohen P werte "ganz normal" durch das 16-bit PWM.

vllt ist das schon die erklärung für den TBE.. mit dem 16-bit PWM und reglern die das auch wahrnehmen ist eine Standard einstellung von p=4 oder so einfach zu wenig.. ich würde mir das so erklären das eine von aussen herbeigefürhrte bewegung ja solange weiter geht bis die motoren reagieren.. und bei 8 bit pwm dauert es ja nunmal länger bis die im code errechnete korrektur an den motor kommt .. wenn z.b. nur eine gas korrektur von 5us notig ist, passiert bei 8bit ja nochnix weils nur in 8er schitten rechnet.

gruß

felix

also, heißt das jetzt, dass wenn man eine "normale, alte IMU 0.3.5" hat mit itg und bma180, und einem "normalen" ardu promini, der copter eigentlich mit der SW2.0 und den dort eingesetzten default werten wie vorher auch mit den default werten fliegen sollte...?

irgendwie verhält sich mein gelber aber trotzdem nicht wie vorher oder ist das ein placebo-effekt?

[frankyfly]

Ich hätte da gerne mal eine Frage

Ich habe ich 'meinem Flydumini einen MPU6050 (der auf dem Flyduino-BOB) Spendiert.
Alles in allem keine große Sache, anlöten, festkleben, ein paar Zeilen in der Config ändern/hinzufügen ... Fazit: fliegt

... bis auf eine Kleinigkeit, die mir aufgefallen ist, und Zwar kenne ich bisher nur den BMA020 als ACC der ja eine Auflösung von ca. 255 bit/g hat,
mein MPU6050 hat aber das doppelte, also ca. 512bit/g. eigentlich ganz schön , aber wenn ich ihn auf den Tisch stelle und den ACC Kalibriere setzt die SW ja die Roll und Pitch-achse auf 0 und die Z-Achse auf 255 was zur Folge hat das zwar Roll und Pitch Symetrisch werte von ca. 512 bis -512 anzeigen, aber die Z-Achse werte von 255 bis ca -768 anzeigt.

Ich kann mir sehr gut vorstellen das dass einen nicht unerheblichen Einfluss auf den Level-mode hat. gibt es dazu Erfahrungen?

[frankyfly]

*gefunden*

In Multiwii 2.0 Sensors Zeile 1120

Code: Alles auswählen

void ACC_init () {
  i2c_writeReg(MPU6050_ADDRESS, 0x1C, 0x10);             //ACCEL_CONFIG  -- AFS_SEL=2 (Full Scale = +/-8G)  ; ACCELL_HPF=0   //note something is wrong in the spec.
  //note: something seems to be wrong in the spec here. With AFS=2 1G = 4096 but according to my measurement: 1G=2048 (and 2048/8 = 256)
  //confirmed here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1080&start=10#p7480
  #if defined(FREEIMUv043)
    acc_1G = 512;
  #else
    acc_1G = 255;
  #endif

Code: Alles auswählen

void ACC_init () {
  i2c_writeReg(MPU6050_ADDRESS, 0x1C, 0x10);             //ACCEL_CONFIG  -- AFS_SEL=2 (Full Scale = +/-8G)  ; ACCELL_HPF=0   //note something is wrong in the spec.
  //note: something seems to be wrong in the spec here. With AFS=2 1G = 4096 but according to my measurement: 1G=2048 (and 2048/8 = 256)
  //confirmed here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1080&start=10#p7480
  #if defined(FREEIMUv043)
    acc_1G = 512;
  #else
  // acc_1G = 255;
       acc_1G = 512;
  #endif

Nicht sauber programmiert, aber sieht für meinen Geschmack besser aus, mal schauen wie es sich damit fliegt.

[ronco]

aus dem FPV forum von Tilman.. wollte mich nicht für ein psot anmelden .. wo ich doch gar kein FPV betreibe..
http://fpv-community.de/showthread.php? ... post133033

So Jungs, erstaunliches Resultat: Ich bin mit meinem X8 natürlich völlig in die falsche Richtung gegangen. Anstatt Gyro I zu verringern, um den X8 weniger zappelig zu machen, muss Gyro P hoch, um empfindlicher auf Lageabweichungen zu reagieren. Ich bin mittlerweile bei P 9.0, I 0,04 und D 40 und habe immer noch Luft nach oben. Und oh Wunder: Der TBE im ACC ist wie weggezaubert. Darauf hätte ich eigentlich früher kommen können: Der ACC wird dem Gyro ja nur hinzugeschaltet und wenn der Gyro schon nicht richtig stabilisiert, wird das Ganze mit dem ACC eine schwammige Angelegenheit.

hast du da einen mega drauf? wenn ja sind die hohen P werte "ganz normal" durch das 16-bit PWM.

vllt ist das schon die erklärung für den TBE.. mit dem 16-bit PWM und reglern die das auch wahrnehmen ist eine Standard einstellung von p=4 oder so einfach zu wenig.. ich würde mir das so erklären das eine von aussen herbeigefürhrte bewegung ja solange weiter geht bis die motoren reagieren.. und bei 8 bit pwm dauert es ja nunmal länger bis die im code errechnete korrektur an den motor kommt .. wenn z.b. nur eine gas korrektur von 5us notig ist, passiert bei 8bit ja nochnix weils nur in 8er schitten rechnet.

gruß

felix

also, heißt das jetzt, dass wenn man eine "normale, alte IMU 0.3.5" hat mit itg und bma180, und einem "normalen" ardu promini, der copter eigentlich mit der SW2.0 und den dort eingesetzten default werten wie vorher auch mit den default werten fliegen sollte...?

irgendwie verhält sich mein gelber aber trotzdem nicht wie vorher oder ist das ein placebo-effekt?

Hi,

also von der PWM frequenz und auflösung hat sich für den promini nix geändert. was genau sich genau an der gyro und acc datenverarbeitung geändert hat weis ich nicht.

[edit]hol dir doch einen promicro! der hat auch 16-bit PWM.. oder du wartest auf das vom jörg ..[/edit]

@frankyfly

deine code änderung ist so richtig. aber das ist nicht wirklich ein bug.. als die version2.0 rauskahm hatten die meissten noch die MPU-6050ES (so eine vorversion) die hatte einen acc bug und deshalb nur eine auflösung von 256. in den neuen dev versionen ist die MPU-6050 standartmässig auf 512 gestellt .. nur für die freeIMU 4.0 stehts dann noch auf 256.

gruß

felix

[frankyfly]

deine code änderung ist so richtig.

So Fliegt er sich auch, noch alles recht Schwammig,weil noch nichts an den Parametern Optimiert wurde, aber Kontrollierbar

in den neuen dev versionen ist die MPU-6050 standartmässig auf 512 gestellt .. nur für die freeIMU 4.0 stehts dann noch auf 256

Ok. um um "dev" und "0.X" Versionen mache ich in der Regel einen Bogen, vor allem auf Produktivsystemen wie dem Flydumini

Ich weiß ja nicht wie lange es noch bis zur 2.1 dauert, aber wenn das länger wird finde ich das es Zeit wird für eine "2.0patch1" denn ich denke es werden schon nicht wenige damit unterwegs sein seit Paul den Im Shop hat