Der WII-Copter ( Selbstbau-Projekt )

[r0sewhite]

hab am we den headfree mode mit nem copter von nem kolleg ausprobiert. total verwirrend

Hab ich auch schon hinter mir. Ging ordentlich in die Hose, hatte nach kurzer Zeit nen Knoten im Kopf.

[Crizz]

>ISt wohl eher was für Leute, die die Birne "offline" haben - wir alen Säcke fangen dabei an zu denken, das scheint nicht kompatibel zu sein

[segelpeter63]

Jetzt bin ich ein bissel verwirrt: Ich benutze die MPU6050-Invensense von Drotek und aktiviere im Code die Drotek_6doF_MPU6050. Dort steht als I2C Adresse die 0xD2. Auf der Homepage und in der Anleitung zur MPU6050 steht die binäre Adresse 1101000 was dem Hex Wert von 68 entspricht (für Logisch Null Level) und 1101001 für Logisch High Level, also Hex die 69, bzw. in der Beschreibung zur MPU6050- Invensense die 0x69. Eigentlich sollte die MPU also gar nicht angesprochen werden können. Wieso geht es aber trotzdem?

Der Einfachheit halber die hier: http://www.drotek.fr/shop/en/42-mpu6050 ... meter.html

Danke und Gruß

Peter

[Crizz]

Weil die Drotek 6-DoF doppelt vorhanden ist´, bzw. die defines sich mit der 10-DoF überschneiden.

Wenn du Probs oder I2C-Fehler hast, bzw, keine sichtbaren Aussschläge in der GUi, mußt du dran arbeiten - i.-d.r durch etnfernen der Adressierung , denn die ist aúch 2xfach drinnen, sieht du wen du die Sensors.h und die Def.h durchblätterst. Wenn als IMU die 6-DoF verwednet wird nimm den Adress-Sulms raus, die wird über die Def.h dann angesteuert,

Ist leider noch nicht ganz perfekt, mittlerweile ist auch schon die zweite Dev-Version ach der 2.0 draußen, überschneidet sich halt auch mal...

[segelpeter63]

Weil die Drotek 6-DoF doppelt vorhanden ist´, bzw. die defines sich mit der 10-DoF überschneiden.

Wenn du Probs oder I2C-Fehler hast, bzw, keine sichtbaren Aussschläge in der GUi, mußt du dran arbeiten - i.-d.r durch etnfernen der Adressierung , denn die ist aúch 2xfach drinnen, sieht du wen du die Sensors.h und die Def.h durchblätterst. Wenn als IMU die 6-DoF verwednet wird nimm den Adress-Sulms raus, die wird über die Def.h dann angesteuert,

Ist leider noch nicht ganz perfekt, mittlerweile ist auch schon die zweite Dev-Version ach der 2.0 draußen, überschneidet sich halt auch mal...

Also ich habe keine I2C Fehler oder irgentwelche Probleme, ausser das ich den ACC Mode immer noch nicht stabil habe.

Ein Auszug aus der Sensor.ino sagt was anderes: #if !defined(MPU6050_ADDRESS)
#define MPU6050_ADDRESS 0xD0 // address pin AD0 low (GND), default for FreeIMU v0.4 and InvenSense evaluation board

In der Anleitung zur MPU6050 steht aber für AD0 low die Adresse 0x68 bzw. für High die Adresse 0x69.

Und die Adressen der ITG3200 überschneiden sich zwar mit der 0xD0 bzw. 0xD2, aber es gibt keine Adressangabe für die MPU6050 von 0x69 bzw. 0x68.

Verwirrter Gruß

Peter

[r0sewhite]

Peter, auf der Drotek-Seite ist die Adresse als 7bit benannt, in der MultiWii werden aber 8bittige notiert. Häng einfach mal ne Null hinten dran, das ist das ganze Geheimnis.

[segelpeter63]

Peter, auf der Drotek-Seite ist die Adresse als 7bit benannt, in der MultiWii werden aber 8bittige notiert. Häng einfach mal ne Null hinten dran, das ist das ganze Geheimnis.

Ha, und wie lautet dann das 8. Bit? 0 oder 1 mom, ich rechne mal nach, Danke für den Tipp

Peter

[r0sewhite]

Weil die Drotek 6-DoF doppelt vorhanden ist´, bzw. die defines sich mit der 10-DoF überschneiden.

Was willst Du uns denn damit sagen?

[segelpeter63]

Peter, auf der Drotek-Seite ist die Adresse als 7bit benannt, in der MultiWii werden aber 8bittige notiert. Häng einfach mal ne Null hinten dran, das ist das ganze Geheimnis.

Ha, und wie lautet dann das 8. Bit? 0 oder 1 mom, ich rechne mal nach, Danke für den Tipp

Peter

Zitiere mich selbst, es ist nicht das 8. Bit sondern das erste Bit, was ergänzt wird, halt mit 0, wie Du schon sagst.

Darauf muss man erst mal kommen. Und das die IMUs mehrfach mit der gleichen Adresse genannt sind, macht gar nix, man schliesst ja nur eine davon an den I2C Bus an. Dem Code ist es egal.
Paar wenige Byte kann man sicherlich sparen, wenn man alles auskommentiert und aus dem Code rausnimmt, was man nicht braucht, aber mit compiliert wird.

Aber lohnt sich die Mühe wirklich?

Gruß an diejenigen, die um die Zeit, immer noch aktiv sind...

Peter

[r0sewhite]

Und das die IMUs mehrfach mit der gleichen Adresse genannt sind, macht gar nix, man schliesst ja nur eine davon an den I2C Bus an.

Eine IMU kriegt doch gar keine I²C-Adresse, sondern nur ihre Sensoren. Und die haben typischerweise feste Adressen. ITG3200 und MPU6050 haben üblicherweise immer die Adresse 0xD0, also den Adresspin AD0 auf low gezogen. Drotek ist hier die einzige mir bekannte Ausnahme. Jerome zieht seine Gyro-Adressen immer auf high, respektive eben 0xD2.

[segelpeter63]

Und das die IMUs mehrfach mit der gleichen Adresse genannt sind, macht gar nix, man schliesst ja nur eine davon an den I2C Bus an.

Eine IMU kriegt doch gar keine I²C-Adresse, sondern nur ihre Sensoren. Und die haben typischerweise feste Adressen. ITG3200 und MPU6050 haben üblicherweise immer die Adresse 0xD0, also den Adresspin AD0 auf low gezogen. Drotek ist hier die einzige mir bekannte Ausnahme. Jerome zieht seine Gyro-Adressen immer auf high, respektive eben 0xD2.

Ja, die Sensoren auf der IMU, das meinte ich auch. OK Ich sags halt im Volksmund..

[ronco]

Felix, nicht sauer sein - ist alles gut . Siehe oben. Denke es hat jetzt jeder begriffen.

keine sorge

ihr tragt einen grossen teil zur entwicklung bei! ohne leute die alles testen würde es nicht gehen..

alex (in paris) scheint im moment nicht sonderlich viel zeit zu haben .. und im moment wird versucht das ganze erstmal was aufzureumen und zu optimieren .. es wurde halt lange nur neues dran gebaut.
ist halt immer aufregender neue features zu machen ..

ich bin im moment an dem servo code.bisher laufen ja alle servos immer mit 50hz. ändere das grade das sie wenn man es aktiviert auch mit bis zu 300Hz laufen können .. also wird dann immer noch langsamer jeh mer servos man braucht .. aber selbst mit 8 wäre es dann noch bei ~100hz

noch dazu wird das "jitter" dadurch etwas reduziert.

hättet ihr lust das zu testen ? (im multiwii forum hält sich die begeisterung in grenzen )

gruß

felix

[r0sewhite]

ich bin im moment an dem servo code.bisher laufen ja alle servos immer mit 50hz. ändere das grade das sie wenn man es aktiviert auch mit bis zu 300Hz laufen können .. also wird dann immer noch langsamer jeh mer servos man braucht .. aber selbst mit 8 wäre es dann noch bei ~100hz

noch dazu wird das "jitter" dadurch etwas reduziert.

hättet ihr lust das zu testen ?

Felix, sobald in den kommenden Wochen hoffentlich endlich auch der Gimbal für meinen Rahmen (http://www.microcopters.de/artikel/r0sewhite-tamara) fertig ist, bin ich für alles offen, was auch nur im Entferntesten eine saubere Gimbal-Steuerung bringt. Bislang war das so ein trauriges Gezappel, dass es eigentlich völlig egal war, ob man einen Gimbal für 50 Euro oder für 800 Euro drunter gehängt hat.

[ronco]

ja dann bin ich doch mal gespannt ob das hilft

habe es jetzt auch für den mega und den 32u4 auf 11-bit PWM gestellt (also jetzt auch für die servos)

wer testen will hier ist die aktuelle revision 670 mit meinem servo code drinn
http://www.filefactory.com/file/4v6pg16 ... Fservo_zip

das "SERVO_FAST_PWM" is an, kann aber in der config.h zimmlich oben auskommentiert werden .. dann sinds wieder 50Hz

gruß

Felix

[ronco]

.. zu spät zum editieren

was noch gesagt werden sollte .. ich habe gehört das analog servos mit frequenzen über ~60hz probleme haben können .. nicht gehen, warm werden, summen, oder sogar kaputt gehen können .. also bitte nur mit digital servos SERVO_FAST_PWM an lassen!

(oder eben versuchen .. habe hier 8 € noname analog servos die dammt gehen)

gruß

Felix