Der WII-Copter ( Selbstbau-Projekt )

[dynai]

Hi, hier kurz meine Kern-komponenten liste

• Arduino Mini Pro
  WMP (Original Nintendo)
  BMA 020
  
  Software: Multiwii 1.6

Ich kann eigentlich nur zur 1.6er raten da nicht nur mehr sensoren unterstütz werden sondern auch der Kalman filter integriert wurde, dieser sorgt dafür das die Kurven wesentlich sauberer sind.
Ausserdem ist die Cycle-Time mit 1.6 ein ganzes stück nach unten gegangen. Hier hab ich bei 100kHz gerade mal 3850 (WMP + BMA020)

Achjo der BMA 020 kommt parallel zur WMP an den I2C-Bus

@günti: Prinzipiell geb ich dir recht, wer den isp-programmer gleich griffbereit hat wie nen FTDI-Adapter kann das machen, ich finds trotzdem bequemer den Arduino-Boatloader drauf zu haben und mir wenn nen neue version rauskommt die ratz fatz drauf zu spielen oder bei änderungen im code (minthrottle,...) da nicht den umweg über den flasher machen zu müssen. Speziell bei einer Software die so schnell wächst wie die des Wii-Copters.


Gruß Chris

[detlef]

Mal noch eine Frage zur GUI
Wie zuverlässig/aussagekräftig sind die "Motor" Anzeigen der GUI. Obwohl ich die Platine nach dem Einschalten nicht mehr berühre, verliert ein Motor (d.h. die Anzeige des Motoer in der GUI) ständig an Wert. Gegensteuern oder Trimmen bringt nichts. Ausprobieren (im Flug) kann ich nicht, da meine Regler noch nicht da sind.
Auch werden oft 2 gegenüberligende Motoren wesentlich stärker angesteuert als die andere Achse (das würde beim realen Copter doch zum Drehen um die Hochachse führen, oder?).

mfg
Robert

Hi,

sieht das etwa so aus?


Gruss
Detlef

[dynai]

@R2D2 Bastler:
das in der GUI ist, wenns langsam passiert, ganz normal ist minimaler drift der dir in der luft nicht oder nur kaum auffallen wird.

gruß Chris

[Mataschke]

Zumindest für die 820er trifft Deine Aussage nicht zu!

Dann müssen die "Dragonsky 20A" Regler eine andere Firmware als die ROXXY haben weil bei mir tut es tadellos. Ich werd die nicht flashen und bin sehr Glücklich mit meinem Copter....

[yacco]

Done compiling.

Binary sketch size: 14094 bytes (of a 30720 byte maximum) AtMega328 ausgewählt
Binary sketch size: 14140 bytes (of a 14336 byte maximum) AtMega168 ausgewählt KP warum der sktech da größer wird?

Ist mit V1.6 und WM+ ohne Sonderfälle und LCD-Conf aus (sorry Jacco ) sollte also auch in den 168 passen. Wer einen kaufen möchte/muß wird aber wohl zum 328 greifen?

Mit der LCD-Conf in der MWC-Software hab ich nichts zu tun. Hast du mal probiert, ob die 14140 Bytes wirklich mit dem Bootloader in den ATMega168 geflasht werden? Bei meinem Uno liegt die maximale Größe des hex-Files, die ich so aufspielen kann, bei ~28650 Bytes, darüber bekomm ich Fehlermeldungen von avrdude. (30720 byte maximum... my ass. )

Wie zuverlässig/aussagekräftig sind die "Motor" Anzeigen der GUI. Obwohl ich die Platine nach dem Einschalten nicht mehr berühre, verliert ein Motor (d.h. die Anzeige des Motoer in der GUI) ständig an Wert. Gegensteuern oder Trimmen bringt nichts. Ausprobieren (im Flug) kann ich nicht, da meine Regler noch nicht da sind.
Auch werden oft 2 gegenüberligende Motoren wesentlich stärker angesteuert als die andere Achse (das würde beim realen Copter doch zum Drehen um die Hochachse führen, oder?).

Den Effekt hatte ich auch, verursacht wurde das wohl durch Störungen auf meinem Board, die die Kalibrierung der Sensoren durcheinander gebracht haben. Dadurch hatte ich keine korrekte Neutralstellung nach dem Kalibrieren, was dann wohl zu diesem Driften führte. Welche Werte siehst du bei dir auf den Gyro/Acc-Kanälen (oder den Neigungswinkeln, falls mit Nunchuk/Acc) in der MultiWiiConf?

[calli]

Wie zuverlässig/aussagekräftig sind die "Motor" Anzeigen der GUI. Obwohl ich die Platine nach dem Einschalten nicht mehr berühre, verliert ein Motor (d.h. die Anzeige des Motoer in der GUI) ständig an Wert. Gegensteuern oder Trimmen bringt nichts.

Ich habe es schon ein paar Mal erwähnt. Das ist NORMAL. Die Regelung versucht am Boden zu regeln, d.h. es stellt aber es passiert nix (wie auch ohne Steuerglied) und dann driftet es wegen I Anteil weg.

Carsten

[guro]

Wie zuverlässig/aussagekräftig sind die "Motor" Anzeigen der GUI. Obwohl ich die Platine nach dem Einschalten nicht mehr berühre, verliert ein Motor (d.h. die Anzeige des Motoer in der GUI) ständig an Wert. Gegensteuern oder Trimmen bringt nichts.

Ich habe es schon ein paar Mal erwähnt. Das ist NORMAL. Die Regelung versucht am Boden zu regeln, d.h. es stellt aber es passiert nix (wie auch ohne Steuerglied) und dann driftet es wegen I Anteil weg.

Carsten

genau, wollt ich auch gerade schreiben. Dadurch das durch die ersten eingriffe nix passiert (da ja keine motoren echt drehen und das ufo in der luft ist) versucht die regelung immer stärker gegenzuregeln in der hoffnung den fehler zu reduzieren. wenn das allerdings sehr flott geht solltest du nochmal die werte prüfen...

[yacco]

Calli, schon, wenn denn die Sensoren auch richtig kalibriert sind. Wenn z.B. die Neutralwerte des Gyros nicht stimmen, versucht die Software permanent, die vermeintliche Beschleunigung auszugleichen, wie in meinem Fall - der vordere rechte Motor wurde permanent ~25% weniger angesteuert als die beiden anderen. Ich hatte meinen Tri zum Testen im Schwerpunkt aufgehängt, beim Gasgeben kippte der ständig nach vorne rechts weg.

[marix]

Guten Tag Herrschaften,

versuche seit 2 Tagen die 1.6 drauf zu machen, habe mir bereits von Didi (danke nochmals) seinen Sketch schicken lassen, da ich mit den Einstellungen nicht klar gekommen bin.

Folgende Fragen/Hinweise/Probleme:

Nachdem ich die 1.6 aufgespielt habe, zeigt die GUI mal keine Gyrowerte und nach erneutem Aufspielen immer noch keine Gyrowerte aber zumindest die gelbe (ja nur die gelbe) Linie, die Cycletime liegt zwischen.....ACHTUNG.....-10000 und -16000.
Mal blinkt die grüne LED am Arduino gleichmäßig schnell, machmal, nach erneutem Auspielen, scheint eine Kalibrierung durchgeführt zu werden (LED blinkt wie bei der 1.5 rhythmisch).

Wenn ich unten stehende Parameter nicht einstelle, wird beim Compilieren gemeckert, obwohl diese Werte als Fortgeschrittene-Einstellung definiert sind.

Yaw Direction (mußte bei der 1.5 nicht definiert werden)
Interleaving-Delay (meine Einstellung: 3000)
Neutralize-Delay (meine Einstellung: 100000)
Force-Level
VBAT-Level (hier habe ich die Standardwerte belassen)

Folgende weitere Einstellungen sind mir auch nicht klar:
def. interne Pullups
def. Gyroscope (meine Einstellung: ITG 3200)
(meine Config Arduino promini, nur m+ (Original))

Ich möchte nochmal ausdrücklich erwähnen, dass, wenn ich die 1.5 wieder einspiele, alles sauber funktioniert, gleiche Verkabelung.
Mir ist beim Compilieren aufgefallen, dass der Sketch mit 1.6ccp oder cpp ? angegeben ist, ist das vielleicht der Fehler?
Aber, bei Didi scheint es zu funktionieren (gleicher Aufbau, außer, dass ich X und Didi + fliegt, und ich einen orig m+ habe, somit 100Mhz einstelle im Sketch).

Help, hilfe....

Danke
Marco

[MatthiasW]

Hallo,
nun möchte ich auch mal meinen WiiCopter vorstellen. Ohne Eure Hilfe (immer fleißig gelesen) wäre ich bestimmt nicht soweit. Der Rahmen ist selbstgefräst (dxf von flugwiese.de - Herzlichen Dank). Verbaut ist aber kein Arduino-Board, sondern eine kleine Platine mit einen Mega328. Die Vorlage hatte ich mal bei rcgroups gefunden. Einfach die compilierte hex drauf, Fuse eingestellt und fertig. Nix Bootloader!
Nächste Woche ist anfliegen (darf in die Sporthalle), ich freu mich drauf!

Also viele Grüße
Matthias

1.JPG (118.65 KiB) 1490 mal betrachtet

2.JPG (100.39 KiB) 1490 mal betrachtet

[speedy]

def. interne Pullups

Wenn ich das richtig mitbekommen habe, dann kann man damit bei den Sensoren intern eine Art Logic Level Converter einschalten - dadurch benötigt man keinen externen Logic Level Converter für den I2C Bus. Also nicht die Betriebsspannung von 3,3V, sondern nur für das Signal. Ich weiß aber nicht, ob das nur zusammen mit den separaten Sensoren (ITG3200, BMA180 etc.) funktioniert oder ne Sache von Arduino ist. Stand da zwar auch im Thread, aber habs nicht mehr im Kopf. Ich weiß nur, daß der Entwickler vom FreeFlight IMU deswegen sich weigert auf dem Board auch einen I2C Logic Level Converter mit raufzubringen - weils ja Software-seitig möglich ist. Problem ist natürlich, wenn man das nicht angeschaltet hat und nur ne Testsoftware verwendet, die das nicht kann, daß man dann seine Sensoren brutzelt.

def. Gyroscope (meine Einstellung: ITG 3200)

Das ist nen "anderer" Gyro und normalerweise nicht der WMP - da solltest du den WMP auswählen, falls der nicht Standard ist, wenn kein anderer ausgewählt ist.


MFG
speedy

[calli]

Wenn ich das richtig mitbekommen habe, dann kann man damit bei den Sensoren intern eine Art Logic Level Converter einschalten - dadurch benötigt man keinen externen Logic Level Converter für den I2C Bus.

Das ist Quatsch

Pullups sind nur Widerstände die eine Signalleitung auf definierten Pegel halten. Entweder gegen Vcc oder GND je nachdem.

Carsten

[Günti]

einige WM+ haben keine eigenen PULLUPS

deshalb

Code: Alles auswählen

//****** advanced users settings   *************

//enable internal I2C pull ups
#define INTERNAL_I2C_PULLUPS

bei verwendung u.a. BMA020 würde es ebenfalls entfallen. (es sind welche enthalten)

[speedy]

Das ist Quatsch

Lies mal mein "Edit" - hab den Text grad noch erweitert. Diese Einstellung wurde für den FreeFlight IMU reingenommen. Ist mir klar, daß das normalerweise nur Widerstände sind - aber wenn der Signalpegel dadurch auch auf 3,3V gehalten wird hat es ja das gleiche gewollte Ergebnis. Aber ich weiß wie gesagt nicht, ob das ne Sache von den Sensoren oder vom Arduino ist.


MFG
speedy

[Günti]

Pullups sind nur Widerstände die eine Signalleitung auf definierten Pegel halten. Entweder gegen Vcc oder GND je nachdem.

auch nicht ganz richtig.

Widerstände die eine Signalleitung auf definierten Pegel halten,,
auf GND sind Pulldown