hier noch die von Harald angesprochene Version. " Sensor on Board "
Druckbare Version
hier noch die von Harald angesprochene Version. " Sensor on Board "
Testboard deshalb, weil ich nicht weiß ob die Software mit den jetzt verwendeten Anschlüssen zurecht kommt, oder ob es besser andere wären.
Ich dachte halt so wie ein Arduinoboard zum Ausprobieren.
Es wäre schön, wenn sich auch mal jemand über die Software äußern würde, machbar oder nicht?
Gruß Bernd
Also ich würde als "Testboard" ebenfalls das hier bereits diskutierte verwenden. Wenn Chris uns die Prototypen ätzen könnte wäre das doch optimal. Ansonsten müsste man nur wieder ein Board mehr erstellen, löten etc. Wenn auf dem Prototypen was falsch ist muss man halt mit Kupferlackdraht ran, aber immerhin hat man dann ein einsatzbereites Board. Ich wäre für den PDI Stecker, da der Bootloader wieder eine andere Baustelle ist, und zu testen ob der ganze Krempel überhaupt funktioniert erfordert viiiiele Programmiertests. Da ist mir halt ein Stecker lieber. Auch weiß ich noch nicht wie das im Xmega mit dem Eeprom funktioniert. Das kommt alles später, erstmal muss der Xmega einen Copter zum fliegen bringen.
Die paar Sachen die ich bisher gelesen habe klingen sehr vielversprechend. Wie das aber im Detail mit PWMs, UARTs, I²C usw. funktioniert weiss ich noch nicht. Bootloader und EEprom sind wieder anders. Aber wir sind ja nun ein paar mehr Leute (z.T. sogar schon mit xmega erfahrung), vielleicht kann sich jeder auf einen Teil konzentrieren und wir führen die Lösungen dann Schritt für Schritt zusammen.Zitat:
Es wäre schön, wenn sich auch mal jemand über die Software äußern würde, machbar oder nicht?
Was mir noch einfällt: Bei meinen layout mache ich die Solderpads für SMD Teile immer eine Ecke länger. Dann komme ich besser mit dem Lötkolben dran. Sind die Pads der IMU lang genug?
Wenn Bernd das Pad von mir verwendet hat, dann sind die Pads länger als Original und lang genug (Sven und ich haben mit diesen Pads schon insgesamt 5 Copter gelötet).Zitat:
Zitat von Willa
Also gut, dann überarbeite ich das Board mit den 6 Motoren ( je ein Anschluß ) und dem extra Sensor für 1,27 mm Stecker (oder besser Buchse, gegen Kurzschlüsse beim Absturz :-) ), die nehmen auch nicht mehr Platz weg als die Pads.
Die wichtigen Pads bei der IMU sind schon etwas länger. (da war ich zu langsam)
Weitere Wünsche??
Ich kann auch zwei oder drei verschiedene Layouts machen.
Gruß Bernd
Ich habe das Schaltbild nach bestem Wissen und Gewissen so ausgelegt, dass die Ports passend zur Aufgabe gewählt sind.Zitat:
Zitat von bendh
Also einen HW-UART für den Empfänger (ok, hier muss noch die Beschaltung des Steckers geändert werden), einen weiteren HW-UART für die Kommunikation zur GUI [edit] die beiden UARTs können vertauscht verwendet werden, wenn die Stromversorgung besser an den GUI-Stecker gebracht werden kann [/edit] , die sechs HW-PWM-Ausgänge für die ESC-Ansteuerung, einen HW-I²C-Port für den MPU, einen weiteren HW-I²C-Port für den potentiellen Versuch von Willa, seine ESCs über die Konverter anzusprechen.
Den Kleinkram (im Wesentlichen sind das noch die LEDs) habe ich dann noch auf die restlichen freien Ports verteilt und dabei versucht, kurze Leitungen zum geplanten Einbauplatz (der LEDs z.B.) zu ermöglichen.
Reset, Quarz, PDI sind vorgegeben.
Also, ich würde sagen, mit dieser Beschaltung können wir ins Rennen gehen.
?? Welcher extra Sensor? Habe ich einen oder mehrere Posts übersehen?Zitat:
Zitat von bendh
Eine Leitung von Pin 12 des MPU nach Pin 25/26/27 des Atmel -> Interrupt wenn neue Sensordaten im Ausleseregister stehen. Damit kann dann auch der MPU-interne Fifo verwendet werden. (Keine Ahnung, ob wir das nutzen können, aber wenn es Willa packt, dann findet er bestimmt raus, wie er an seine Euler- und sonstigen magischen Zahlen im MPU ran kommt, und die werden, glaube ich, über das Fifo ausgespuckt).Zitat:
Zitat von bendh
William möchte, glaube ich gelesen zu haben, auch lieber den Sensor auf einem extra Board.
Ja. Ursprünglich hätte ich es auch schicker gefunden nur ein Board inkl. Sensor zu haben. Aber Bernd hat recht, die Sensoren ändern sich dauernd (bleiben aber hoffentlich bei I²C und 3.3V). Somit hätte man ein board mit höherer Habwertszeit. Außerdem kann man so den Sensor besser lagern. Ich würde das Hauptboard mit Kunststoffschrauben vibrationsgedämpft anbringen. Dann kommt das IMU Board mit doppelseitigem Schaumklebeband oben auf den xmega drauf. Diese doppelte Entkopplung könnte was bringen. Vielleicht auch für den SNQ, denn dort sind die motoren ja "direkt an die IMU geschraubt".Zitat:
William möchte, glaube ich gelesen zu haben, auch lieber den Sensor auf einem extra Board.
Harald, wie ist das denn bei der IMU? Wie schnell kommen da neue Werte raus? Etwas weiter oben im Thread hast du geschrieben, dass du oftmals die gleichen Werte ausliest. D.h. die Daten kommen lansamer als mit 500Hz? Wenn dem so ist, ist das für den PID Regler natürlich ziemlich schlecht. Besonders für den D-Anteil, der ja zwei aufeinanderfolgende Werte vergleicht. Zu wissen wann neue Werte da sind ist also ziemlich wichtig.Zitat:
Eine Leitung von Pin 12 des MPU nach Pin 25/26/27 des Atmel -> Interrupt wenn neue Sensordaten im Ausleseregister stehen
Ich würde jetzt bei Reichelt mal die benötigten komponenten bestellen (Harald, hast du noch eine IMU für mich?)
Ich habe gelesen, dass der AVR ISP mk2 PDI unterstützt und auch direkt mit BASCOM funktioniert. Den gibt es bei Reichelt:
http://www.reichelt.de/Programmer-En...T=0&OFFSET=16&
Allerdings steht dort im Datenblatt nichts von PDI... Ist dass der richtige? Gibt es funktionierende Alternativen?
Im datenblatt des MPU600 lese ich beim Gyro:Zitat:
Wie schnell kommen da neue Werte raus?
OUTPUT DATA RATE Programmable 4 - 8000 Hz
und beim ACC:
OUTPUT DATA RATE Programmable Range 4 - 1000 Hz
Zitat:
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?