Willas Shrediquette Tricopter / Quadrocopter / Hexacopter

[Willa]

Wie schnell kommen da neue Werte raus?

Im datenblatt des MPU600 lese ich beim Gyro:
OUTPUT DATA RATE Programmable 4 - 8000 Hz

und beim ACC:
OUTPUT DATA RATE Programmable Range 4 - 1000 Hz

The Sample Rate is generated by dividing the gyroscope output rate by SMPLRT_DIV:
Sample Rate = Gyroscope Output Rate / (1 + SMPLRT_DIV)
where Gyroscope Output Rate = 8kHz when the DLPF is disabled (DLPF_CFG = 0 or 7), and 1kHz when the DLPF is enabled (see Register 26).
Note: The accelerometer output rate is 1kHz. This means that for a Sample Rate greater than 1kHz, the same accelerometer sample may be output to the FIFO, DMP, and sensor registers more than once.

Was habt ihr da in euren fliegenden Coptern eingestellt?

[bendh]

Noch etwas kleiner

[Willa]

Noch etwas kleiner

Sieht echt super aus, richtig kompakt. Harald muss sich dann noch mal äußern ob Pin12 der IMU wirklich gebraucht wird, oder ob man vieleicht die Refresh rate der IMU hochsetzen kann. Pin12 an die Steckerleiste zu bekommen ist scheinbar etwas Aufwand...

[bendh]

ich muß gestehen, dass ich bis jetzt nur MultiWii-Kopter mit der MPU6050 in die Luft bekommen habe.
Mit der Software von Harald gibt es nur sehr kurze unruhige Flüge die, wenn ich sie nicht schnell beende, mit einem Überschlag enden.
Es hilft bis jetzt auch nicht die Werte in der GUI zu verändern, da wird alles zwar träger, aber auch nicht fliegbarer.
Es könnte aber auch seine Impulserzeugung sein, evt. ist sie nicht schnell genug. So flogen meine Kopter, wenn die ESCs nicht geeignet waren.
Zum testen verwende ich aber immer dieselbe Mechanik und ändere nur die Software. Beides, Willa und Wii Software läufen auf einem ATmega 328.
Ich habe aber keine Ahnung von der Software und habe meine Änderungen im Arduino-Sketch beim Wiikopter immer mit ausprobieren erreicht.

Gruß Bernd

[Che Guevara]

Hi Willa,

den selben Programmer habe ich mir vor kurzem auch bei Reichelt bestellt. Anfangs hatte ich auch bedenken, weil im DB nichts von der PDI Schnittstelle steht, aber er kanns Die Einbindung in Bascom ist auch ganz einfach und in der Hilfe von Bascom findet man eine gute Anleitung, auch bzgl. des Treibers usw....
Falls du Fragen zur Programmierung des XMegas hast, stehe ich gerne zur Verfügung. Habe schon fast mit allen Schnittstellen gearbeitet.
Eine Frage habe ich aber noch:
Wäre es nicht sinnvoll, den MPU6000 zu verwenden und diesen über die SPI Schnittstelle auszulesen? Ich werde das heute mal testen. Damit wäre der Kontrollloop nochmal schneller, da man auf das Senden der Adresse verzichten könnte und der Sensor bis zu 1Mhz Taktrate funktioniert.

Gruß
Chris

EDIT:
Habe gerade mal deinen Code vom Bolt auf einen XMEGA64A3 mit MPU6000 (I2C) umgeschrieben und an den PC angeschlossen. Es funktioniert
Natürlich ist jetzt noch kein Empfänger dran und auch keine Motoren, aber die PWM funktioniert (6 mal Hardware PWM mit 500Hz und 16Bit Auflösung) und die Sensorwerte werden in der TRIGuide angezeigt. Einziges Manko:
Der Sensor liefert 16Bit Werte, somit müsste man einige Variablen noch anders definieren und auch die OFFSET-Berechnung kann wegfallen (MPU gibt bereits Integer aus) und eben noch ein paar Kleinigkeiten. Aber im Prinzip war das eine Änderung innerhalb 20Minuten. Wenn Interesse besteht, würde ich den Code (von Willa!!!) reinstellen.

[bendh]

Hallo Chris,

das sind ja tolle Neuigkeiten.
Kommst du mit dem von mir erzeugten Layout zurecht, oder soll ich da noch etwas anpassen?


an alle:
ist das letzte Layout in Ordnung, oder hat noch jemand Wünsche?
Nur eine Quattro-Version oder bestimmte Pads auf Stecker oder noch kleiner oder....

Gruß Bernd

[Che Guevara]

Hallo Bernd,

hm ich habe bis jetzt noch nie ein Eagle Layout gedruckt und geätzt, aber das sollte kein Problem werden. Aber könntest du mir bitte einen Gefallen tun? Ich weiß leider nicht, wie man einen Design Rule Check in Eagle macht. Könntest du für den Mindestabstand von Kupfer zu Kupfer (also Leiterbahn - Leiterbahn, Leiterbahn - Loch, SMD Pad - Leiterbahn, usw...) 0.15mm (also ca. 6mil) eingeben und den Test durchlaufen lassen? Es wären zwar auch geringere Abstände möglich, aber ich möchte gerne informiert sein
Ich habs gerade selbst probiert, aber irgendwie kommen bei mir 113 Fehler. Teilweise wird der Abstand eines SMD-Pads mit sich selbst angezeigt xD

Gruß
Chris

EDIT:
Wäre es noch möglich, dass du eine "Automasse" einfügst, damit ich etwas Natriumpersulfat sparen kann? Auch das kann ich leider nicht, da ich noch nie mit Eagle gearbeitet habe.

EDIT2:
Habe gerade versucht, das Layout mal auszudrucken, jedoch habe ich dabei ein Problem: Ich habe den Hacken bei "Schwarz" gesetzt, trotzdem wird es nur sehr blass-blau ausgedruckt, fast nicht sichtbar... Wahrscheinlich muss man es anders machen, oder?! Ich habe die ganz normale "Drucken" Funktion verwendet.

[deHarry]

ist das letzte Layout in Ordnung, oder hat noch jemand Wünsche?
Nur eine Quattro-Version oder bestimmte Pads auf Stecker oder noch kleiner oder....

Hallo Bernd,
also das machst du wirklich Klasse!

Eine kleine Anmerkung habe ich noch zu deinem letzten Layout.
Ich lege die Masse bei einseitigen Layouts immer als Ring komplett außen rum, wenn es sich einrichten lässt.
So wie du jetzt entflochten hast, "baumelt" der Quarz ganz am Ende ewig weit weg vom Akku massetechnisch in der Luft rum.
In gewisser Weise gilt das auch für den MPU.
Andererseits sitzt direkt im Pfad vor dem Quarz der Atmel, der durch die Schaltvorgänge an seinen Ausgängen die Masse ziemlich in Unruhe versetzt.

Würdest du auf 12 Uhr die Masse (an der Referenz vorbei mit dicker Leitung) zum Ring schließen, wäre das "Rumbaumeln" weg.

Gibt es dazu andere Meinungen? Oder Bestätigungen? Würde mich interessieren, ob ich mit dieser Betrachtungsweise alleine dastehe.


[edit]
Du hast verschiedene der Kondensatoren als 0402 verbaut (die 4 Blockkondensatoren um den Atmel herum), alle anderen aber auf 0603 belassen.
Absicht? Vermutlich. Der Hintergedanke dabei?

[deHarry]

Habe gerade mal deinen Code vom Bolt auf einen XMEGA64A3 mit MPU6000 (I2C) umgeschrieben und an den PC angeschlossen. Es funktioniert
Natürlich ist jetzt noch kein Empfänger dran und auch keine Motoren, aber die PWM funktioniert (6 mal Hardware PWM mit 500Hz und 16Bit Auflösung) und die Sensorwerte werden in der TRIGuide angezeigt.

Super!
Hast du mal auf die Sensorwerte im Sinne von "Rauschen" geachtet? Zappeln die Anzeigen wild rum, oder stehen die wie eine Eins?
Naja, ohne Motoren waren meine Anzeigen in der GUI auch ganz brauchbar...

[Che Guevara]

Hi,

Code ist im Anhang, da er zu groß für die CodeTags ist.
Es waren auch nicht sehr viele Änderungen, hauptsächlich habe ich die ganzen Variablen für die Regelung von Integer auf Long geändert, damit keine Überläufe mehr vorkommen. Dann noch den MPU integriert, die typischen XMEGA Geschichten eingefügt (Config Priority, Open "COM2", ADC Settings, usw...) und ein paar Änderungen gabs noch bei der GUI Connection bzgl. Skalierung. Aber seht selbst
Zu den PWM Ports:
Beim XMega64A3 gibt es
- TCC0 (Portc.0 - Portc.3)
- TCC1 (portc.4 - Portc.5)
- TCD0 (portd.0 - portd.3)
- TCD1 (portd.4 - portd.5)
- TCE0 (porte.0 - porte.3)
- TCE1 (porte.4 - porte.5)
Aufs Layout habe ich es jetzt nicht angepasst, aber ich denke, bei der Auswahl sollte das kein Problem sein.
@Harald:
Nein, habe ich noch nicht sooo genau gemacht, aber das werde ich mal demnächst machen. Mir stellt sich sowieso die Frage:
Sollte man die Werte der Sensoren entweder auf 12Bit Auflösung (wie im Original) kürzen oder mit den vollen 16Bit rechnen? Dann wäre ggf. der interne Digital Lowpassfilter angebracht. Grundsätzlich sehen aber die Sensorwerte gut aus.
"Rumzappeln" tun sie auf jeden Fall nicht und in der Gui stehen sie wirklich fast wie eine Eins
Info:
Im Code habe ich die "Gyro / ACC Reverse" Funktionen gelöscht, da man das ja dann fest einstellen kann. Das stimmt ggf. noch nicht. Wie gesagt ist der Code sowieso nur ganz Grob abgeändert, aber grundsätzlich funktionierts.

Gruß
Chris