Quadrocopter (Dimensionierung)

[crabtack]

Morgen!

Mittlerweile habe ich endlich wieder Zeit um mich mit einem größeren Projekt zu beschäftigen.
Es soll ein Quadrocopter werden.
Ich könnte dabei noch ein wenig Hilfe bei der Auswahl der richtigen Bauteile gebrauchen.

Also, wichtig ist mir, dass er relativ ruhig fliegt, aber auch schnell fliegen kann.
Also ein Kompromiss zwischen langsamen Kameraträger und schnellem Stunt Copter.
Er soll eine Funkkamera tragen, die durchgehend sendet, aber natürlich auch abschaltbar sein soll, da habe ich leider Garnichts brauchbares gefunden, ich bräuchte was mit geringem Gewicht, geringer Stromaufnahme und recht hoher Reichweite.
Die Bildqualität ist mir weniger wichtig.
Kann mir jemand was empfehlen?
Ich finde in die Richtung überhaupt nichts brauchbares.

Als Funkmodul dachte ich an ein RFM12BP, professionelle Fernbedienungen sind einfach viel zu teuer :D
Die Controller für die Brushlessmotoren wollte ich aus jeweils einem Atmega8, Mosfets und nem bisschen Kleinscheiß aufbauen.
Dann kann jeder Controller vom Haupt µC per SPI angesteuert werden.

Jetzt stellt sich natürlich die Frage, was ich als Hauptcontroller verwenden soll.
Gerne würde ich bei den Atmegas bleiben, da ich damit viel Erfahrung habe.
Allerdings weiß ich nicht, ob die Rechenleistung ausreicht, um die komplexen Reglungsaufgaben zu erfüllen.
Ich würde schon gerne eine schöne PID Reglung implementieren.
Ich könnte mir gut vorstellen, dass dazu ein ATxmega besser geeignet wäre.
Die vielen Schnittstellen wären ein weiterer vorteil, so könnte ich z.B. die Motor Controller jeweils über einen eigenen UART ansteuern.
Wären die Vorteile die Einarbeitung in die Xmegas wert?

Kommen wir jetzt zum heikelsten Punkt, die Kombination aus Akku, Motoren und Propellern.
Als Akku denke ich an den hier: http://www.pollin.de/shop/dt/MzI3ODI3OTk-/Stromversorgung/Akkus/LiPo_Akkus/Modellbau_Akkupack_EXTRON_X1_LiPo_14_8_V_3500_mAh. html
Hat nur 300g und die 3500mAH sollten erstmal reichen :D
Ich möchte definitiv einen 4S Akku verwenden, da ich mir durch die größere Spannung eine höhere Effizienz erhoffe.

Als Motor denke ich über den Roxxy2827-35 nach.
Er macht 760 Umin/V, ich denke, damit bekomme ich eine gute Flugstabilität hin, wenn ich große Propeller verwende.
Außerdem hat er einen Wirkungsgrad von bis zu 76% und 820g Schubkraft.
Lässt also noch Spielraum nach oben, falls ich mal einen größeren Akku oder zusätzlichen Kram anbauen möchte.

Als Propeller werde ich recht große 10x4,5" verwenden, ich dachte da an die hier:
http://www.premium-modellbau.de/10x4-5-Propeller-Carbon-Fiber-1045-1x-CCW-1x-CW-Hexacopter-Quadcopter-CFK/a46742529_u2344/?gclid=COSR-L2c6MACFQH3wgoddTMAWg

Wenn ich mal ganz simpel, unter Annahme von einem Gesamtgewicht von 1kg rechne, komme ich auf 37 Minuten Flugzeit.
In der Realität werden es wohl eher 20, aber damit bin ich dann auch zufrieden.

Als Beschleunigungssensor möchte ich den BMA020 verwenden, da ich damit schon Erfahrung habe und das Teil für ganz brauchbar halte.
Wenn es was deutlich besseres gibt wäre ich natürlich auch dafür offen.

Fehlt noch ein Gyroskop.
Kann mir da jemand was Empfehlen?
Habe echt keine Ahnung, was in dem Fall gut ist.
Wichtig wäre nur, dass es mit 3,3V arbeitet.

Das war jetzt ganz schön viel, hoffe ich erschlage euch nicht.
Ich wäre dankbar für jede Antwort!

Mit freundlichen Grüßen

Olaf

[Che Guevara]

Hi,

also du solltest dich schon entscheiden, ob du eher einen schnellen, wendigen Kopter oder einen Kamera-Schwebe-Kopter willst. Je kleiner / leichter er wird, desto wendiger ist er, je schwerer / größer, desto ruhiger liegt er in der Luft. Für eine Kamera würde ich mind. einen Hexacopter bauen, dieser fällt nicht sofort wie ein Stein vom Himmel, wenn mal ein Motor ausfällt.
Ich weiß ja nicht, wieviel Erfahrung du in dem Gebiet hast, aber Hauptcontroller, BL-Controller & RC-Sender/Empfänger gleichzeitig aufbauen zu wollen ist eine gewaltige Herausforderung auf einmal!
An deiner Stelle würde ich erstmal mit dem Hauptcontroller anfangen, wenn dieser funktioniert, sich an die Bl-Controller waagen.
Eine günstige Rc-Funke bekommst du für unter 100€.
Jeden Bl-Controller mit eigenem Bus anzusteuern, halte ich für übertrieben. Wieso willst du das machen?
Ich selbst verwende auch einen ATXMega, hat schon viele Vorteile, die Einarbeitung hält sich in Grenzen.
Der BMA funktioniert zwar grundsätzlich, hat aber einige Resonanzprobleme in Verbindung mit Bl-Motoren.
Ich würde dir einen MPU6000 / MPU6500 empfehlen, ist eine 6DOF Imu, funktioniert hervorragend und ist bezahlbar.

Gruß
Chris

[crabtack]

Danke für die Schnelle Antwort!

Also der MPU6000 gefällt mir sehr gut, danke für die Empfehlung!
Mit Atmega Mikrocontrollern, C und Assembler habe ich viel Erfahrung und ich kann auf der Arbeit an dem Projekt arbeiten, habe also viel Zeit.
Daher Denke ich, es sollte machbar sein, alles selbst zu machen.
Der Vorteil, jeden mit einem eigenem Bus anzusteuern wäre die Etwas schnellere Übrertragungsrate.
So kann ich einfach das was übertragen werden soll ins UART FIFO schreiben und der Sendet es dann während das Hauptprogramm schon weiter läuft.
Aber vielleicht wäre es sinnvoller, ein paar Busse für andere Sachen offen zu halten.
Die Zeitersparnis ist ja eher minimal :D

Habe mir die Xmegas mal genauer angeschaut.
Ist ja garnichtmal so schlimm und meinen Programmer kann ich dafür auch noch verwenden, dann werde ich mich mal einarbeiten.

Also der Flug muss nicht so stabil sein, wie bei den Normalen Kamerakoptern, es soll in etwa so sein, wie in diesem Video:
http://www.youtube.com/watch?v=kOzA9b_kIvs&list=PLZqRsExZyRDYO3-QhV6vvsYveT820xTjv&src_vid=CjgMhO_qZT0&feature=iv&annotation_id=annotation_3683162411

mfg
Olaf

[Che Guevara]

Ich meinte auch nicht, dass es nicht zu schaffen ist, sondern dass ich alles nacheinander machen würde, so findet man auch Fehler um einiges schneller.
Die XMega haben auch 4 DMA Kanäle, damit brauchst du nur einen Bus. Oder du steuerst die Regler per PWM an, genügend Kanäle sind in HW vorhanden.
Also willst du eine FPV-Ausrüstung? Das kriegst du auf jeden Kopter, egal wie klein / groß , leicht / schwer , zittrig / stabil.

Gruß
Chris

[crabtack]

Oh, das hatte ich vergessen zu erwähnen, ja ich möchte ne FPV :)

Die xmegas sind ja richtig toll, DMA sollte eine Brauchbare Lösung sein.

Naürlich baue ich alles nacheinander auf, sonst kommt am Ende erstmal nichts funktionierendes bei raus :D
Aber ich plane erstmal grob das ganze Teil, damit alle Module am Ende zusammenpassen.
Ich denke, ich werde erstmal mit den Motorcontrollern anfangen, da ich dafür alle Bauteile haben.
Aber erstmal kümmer ich mich um die ganze Planung.
Ich kann erst nächste Woche zur Arbeit, aber die Planung dauert ja erstmal lang genug.

Am wichtigsten ist jetzt erstmal, ob die Motoren geeignet sind.

mfg
Olaf

Edit: Verzeiht mir die übermäßige Nutzung von "erstmal" :D

[crabtack]

So, ich habe erstmal mit der Planung der Platine zur Ansteuerung der Brushlessmotoren begonnen.

Darauf soll ein Atmega88 werkeln.
Als Mosfets kommen die bewährten IRLR7843 zum Einsatz und jeweils eine Halbbrücke wird von einem IR2104S getrieben, das wird mir vermutlich viele tote Mosfets ersparen :D
Die SPI Verbindung möchte ich über den ISP Stecker realisieren, der auch zum Programmieren benutzt wird, zusammen mit einem Pad für die Chip Select Leitung.
Das geht dann alles an einen SPI vom XMega
Sollte so funktionieren oder?

Im wesentlichen ist meine Schaltung der von Microcontroller.net sehr ähnlich.
Der Unterschied ist, dass ich nur SPI zur Kommunikation verwende, eine LED zur Fehleranzeige vorgesehen habe und ich habe die Bootstrapping Kondensatoren auf 1µF erhöht, um etwas mehr Spielraum zu haben.

Damit das ganze klein bleibt (61x33mm) lasse ich die Platine von Iteadstudio fertigen.
Kann sich bitte jemand meinen Schaltplan und Layout grob angucken?
Wäre Blöd, wenn sich ein mehr oder weniger großer Fehler eingeschlichen hat und meine Platinen verhunzt.

Ich habe jetzt nur die Leiterbahnen besonders breit ausgeführt, die die Motoren versorgen.
Ich denke an anderer stelle wird nicht viel Strom fließen und 8mil sollten ausreichen.

Edit: Mir fällt gerade auf, dass ich noch einen Großen Kondensator in die Versorgung hängen sollte, wird noch noch gemacht.

mfg
Olaf Kozießa

[Che Guevara]

Hi,

also die Bauteilauswahl ist gut, ich verwende fast die selbe Konstellation.
Leider kann ich auf beiden Bildern nicht allzuviel erkennen, der Schaltplan ist zu klein, das Layout durch die Doppelseitigkeit zu unübersichtlich (für mich). Vielleicht könntest du ja zusätzlich noch beide Layer getrennt einstellen.
Die Ausmaße von 61x33mm kommen mir sehr viel vor, da liese sich noch einiges einsparen.
Die drei roten Leitungen, die u.a. im linken-unteren Eck zu sehen sind, sind auf jeden Fall sehr suboptimal. Bei so einem Layout heißt die Devise: so kurz wie möglich, so lange wie nötig!
Ich habe mittlerweile 3 Layouts gebraucht, um meine Regler in allen Funktionen verwenden zu können. Außerdem sehe ich weder eine Spannungs- noch eine Strommessung in dem Schaltplan. Bei der Strommessung würde ich nicht sparen, da reicht ein einfacher Shunt. Damit kannst du Fehlkommutierungen erkennen und sparst so evtl. ein paar verbrannte Motoren.

Gruß
Chris

[crabtack]

Hey,
Danke für die Hinweise!

Die Abmessungen konnte ich auf 45x33mm reduzieren, jetzt Zahle ich auch 5$ weniger für die Platinen :)
Das Problem habe ich öfters, dass ich die Platinen größer als nötig mache.

Habe die Bauteile auch neu angeordnet, so dass die Leiterbahnen, bei denen die Länge wichtig ist möglichst kurz sind.

Strommessung ist eine gute Idee, ist jetzt auch drin.
Wäre ja schade, wenn die armen Motoren sterben.

Wozu benötige ich eine Spannungsmessung?
Die Akku Spannung soll vom Hauptcontroller überwacht werden.
Die Spannungen, die der Motor induziert wird über ADC0 bis ADC2 gemessen.

Ich habe Schaltplan, Layout Bottom und Top in den Anhgang gepackt (Ohne Polygon, damit es übersichtlicher ist. Natürlich bekommt die Platine noch ein Polygon)
Der Schaltplan ist für den Anhang etwas zu groß, daher habe ich ihn hier hochgeladen:
http://abload.de/thumb/schaltplanepk0u.png (http://abload.de/image.php?img=schaltplanepk0u.png)

mfg
Olaf

[Che Guevara]

Hi,

also so wie dein Layout momentan aussieht, wirds nicht sicher funktionieren.
Ich habe selbst erst ein Layout entwickelt, das deinem sehr ähnlich war, dadurch dass die Fets direkt unter / über allem anderen (auch dem Analogteil) sitzen, werden sich da massive Störungen einkoppeln, sodass u.a. der Kommutierungszeitpunkt nicht mehr richtig bestimmt werden kann.
Evtl. solltest du versuchen, alles nebeneinander, nicht übereinander zu setzen.

Gruß
Chris

[crabtack]

Hey,

also das mit den Störungen könnte ein Problem werden.
Aber wenn ich alles nebeneinander aufbaue wird es dazu führen, dass die Platine deutlich größer wird.
Eigentlich sind alle Platinen, die ich bisher gefunden haben (z.B. die Mikrocopter Platine) so aufgebaut, dass die ICs direkt über den Mosfets liegen.
Ich wüsste nicht, wie ich es anstellen soll, eine kleine Größe zu erreichen und dabei auch noch eine geringe Störung der Bauteile untereinander.
Hast du dein letztes Layout gerade griffbereit?
Ich würde gerne sehen, wie du es gelöst hast, wenn ich darf :)

mfg
Olaf

[Che Guevara]

Also den Treiber-ICs macht das nichts, aber eben der Sternpunktschaltung und evtl. auch dem Atmega.

Die Platine ist 43x28mm groß, der Chip ist ein Atxmega16A4. Der Rest ist wie bei dir, IR2104S und IRLR8743. Notfalls könnte man hier und da noch ein paar mm einsparen, mir passt aber die Größe so wies ist.

Gruß
Chris

[crabtack]

Danke!

Der Atmega direkt über den Mosfets ist wohl wirklich eher ungünstig.
Aber stellt es kein Problem dar, die Mosfets Top und Bottomseitig anzubringen?
Dann muss immerhin der ganze Strom durch eine Durchkontaktierung fließen.

mfg
Olaf

[Che Guevara]

Also ich hab bis jetzt nur mittelgroße Motoren mit max. 12A Peak drangehabt, der Duko ist das egal. Für größere Motoren würde ich aber mind. noch eine 2. anbringen, kostet schließlich nicht die Welt.

Gruß
Chris

[crabtack]

Ok, danke!

Es ist wirklich von Vorteil, die Mosfets übereinander anzuordnen, so hab ich den Mist in einer Ecke der Platine und der Empfindliche Kram ist weiter weg.
Ich habe mal ein neues Layout gemacht und einfach mit den Vias übertrieben, sollte definitiv reichen.
Die Leitungen, die von den Mosfets zum ADC gehe, gehen sofort von den Mosfets weg, so sollten da wenig Störungen auftreten.

Ich denke, mit dem Layout kann man leben.
Macht ITeadstudio eigentlich auch Durchkontaktierungen?
Ich finde das auf deren Seite nicht.

mfg
Olaf

[Che Guevara]

Hi,

also dein Layout ist etwas unaufgeräumt. Die Batterie-Anschlüsse würde ich auf jeden Fall nebeneinander legen (oder übereinander), die Motor-Anschlüsse sind auch nicht perfekt, die sollten schon an den Rand.
Auch einige Leiterbahnen sind doppelt oder irgendwie verwinkelt, auf der Bottom Seite kann ich zudem nicht allzuviel erkennen, weil einige Bauteile darauf sind, die eigentlich auf dem Top-Layer liegen.
Zu den Dukos dieser Firma kann ich dir nichts sagen, ich fertige meine Platinen immer selbst. Aber das sollte doch eigentlich auf der HP stehen?!

Gruß
Chris

[crabtack]

Danke!

Ok, Batterie Anschlüsse werden noch verändert.
Ich denke, die Motoranschlüsse werde ich so lassen.
In dem Fall ist es mir wichtiger, dass sie Möglichst nah an den Mosfets liegen, als das sie am Rand der Platine sind, sollte nicht so problematisch werden, da Leitungen anzulöten.
Die Homepage von denen ist sehr unübersichtlich, habe ewig gebraucht um da die cam und drc dateien für Eagle zu finden.
Habe jetzt einen Freund gefragt, der da mal bestellt hat, die machen auch Durchkontaktierungen.

War ja klaar, dass ich mal wieder vergesse einen Layer auszublenden, sorry.
Im Anhang noch mal ohne Nervige Top Bauteile.
Da sieht man auch gut, dass es kein Problem ist, die Leitungen für die Motoren anzulöten.

mfg
Olaf

[Che Guevara]

Das mit den Motoranschlüßen ist kein riesen Problem, die Kabel sollten nur nicht über den Logik-Analog-Teil liegen, sonst koppeln sich wieder Störungen ein.
Du hast sehr viele 90° Leiterbahnen drin, außerdem ist die generelle Führung der Bahnen teilweise sehr suboptimal, einige sind sogar doppelt vorhanden.
Auch hast du sehr viele Dukos, ist zwar prinzipiell kein Problem, ginge aber auch mit deutlich weniger.

Gruß
Chris

EDIT:
Achja, ich kann keinen Spannungsregler erkennen. Der war / ist auch nicht in deinem Schaltplan drin, der muss auch noch wohin!

[crabtack]

Hi!

Danke!
Leiterbahnen abrunden habe ich ganz vergessen, wird noch gemacht, sobald der Rest stimmt.
So wie es jetzt ist gehen die Motorleitungen ja nur über die Mosfets, was auch gut so ist.
Das Problem mit den Dukos haben dann die Chinesen :D

Einen Spannungsregler habe ich bewusst nicht auf der Platine.
Die Spannungen werden alle auf der Hauptplatine geregelt und zu den Brushlesscontroller Platinen geführt, dazu ist das Pad 3V3 da.
Ein Großer Elko (470µF) kommt auch noch rein.

mfg
Olaf

[Che Guevara]

Die sollten aber nicht abgerundet, sondern mit 45° Winkeln versehen werden. Wieviele Layouts hast du den schon gemacht? Bin mir nicht sicher, ob du gleich mit einem EMV-technisch "schwierigen" Projekt anfangen solltest (nicht falsch verstehen).
Die doppelten Leiterbahnen müssen auch noch weg!
Die Spannung per Kabel von der Hauptplatine zu den Reglern zu bringen, ist eine sehr schlechte Idee! Alleine schon für den Analog-Teil, sollte man alle Störungen soweit es geht unterbinden. Wenn sich da was einkoppelt, kommutiert der Regler nicht mehr richtig und der Motor raucht dir ab.

Gruß
Chris

[crabtack]

Hi,
also ich habe schon relativ viele Layouts gemacht, die haben auch immer funktioniert.
Allerdings habe ich noch nie so ein kleines Layout, gemacht.
Sonst konnte ich immer Problemlos Logikteil und Leistungsteil voneinander trennen, auch wenn ich dabei massiv Platz verschwende.
Inwiefern sind 45° Winkel denn besser als schöne runde Leiterbahnen?
Ich habe das andersrum in Erinnerung.
Habe gerade keinen besseren Beleg dafür als diesen Thread: http://www.mikrocontroller.net/topic/251876
Normalerweise kombiniere ich beides indem ich erstmal 45° mache und dann die Ecken nochmal abrunde, so braucht das auch nicht viel Platz.
Ob das wirklich viel bringt weis ich nicht, aber schaden kann es auch nicht.

Problem am Spannungsregler auf der Platine ist, dass er wieder platz braucht, wenn, dann müsste ich einen linearen Regler verwenden, der unnötige Verluste mit sich bringt.
Ich hatte mir überlegt, einfach eine Gleichtaktdrossel in die Zuleitung einzubringen.
Da Die Leitung relativ kurz ist sollte das ausreichen, um die Störungen zu kompensieren.
Wenn ich damit vollkommen Falsch liege könnte ich natürlich auch von der Hauptplatine 5V ausgeben lassen, die dann auf der Motorplatine auf 3,3V runtergeregelt werden.

mfg
Olaf

[Che Guevara]

Also 45° Winkel sind überall üblich, es sei den bei speziellen HF-Anwendungen, wo es auf bestimmte Charakteristiken ankommt.
Runde Bahnen sind natürlich nicht schlecht, man verwendet aber normalerweise 45° Winkel.
Soviel Platz braucht der Spannungsregler garnicht, den bekommt man da noch relativ problemlos unter! Es sollte generell noch alles aufgeräumt werden, damit auch die Bahnen direkter verlaufen.
Die Verluste, die der Spannungsregler produziert, sind im Vergleich zum Motorstrom unbedeutend.

Gruß
Chris

[crabtack]

Hi,

ok, du hast recht.
Bei den kleinen Strömen, die der Logikteil braucht bringen mich die Verluste nicht um.
Die Frage ist nur, ob ich die Spannung direkt aus den 14V, die auch für die Motoren genutzt werden erzeuge oder aus einer kleineren Spannung.
Denn ich brauche definitiv eine weitere kleine Spannung, die ich effizient erzeuge, zur Versorgung der FPV Kamera.
Ich weiß nur noch nicht, ob ich dazu einen Separaten Akku verwende oder einen Abwärtswandler in Kombination mit Spannungsregler.
Kannst du mir eine Variante empfehlen?

mfg
Olaf

[Che Guevara]

Also ich würde einfach die Batterie-Spannung verwenden, um damit die Spannungsregler zu füttern.
Ich hab so eine FPV-Ausrüstung: http://www.globe-flight.de/58-GHz-ImmersionRC-25-mW-A-V-Sender
Auf diesem Sender wird auch eine 5V Spannung für die Kamera erzeugt, damit brauchst du nicht nochmal einen extra Regler.
Die 25mW sind die maximal erlaubte Sendeleistung bei 5.8GHz. Wenn du mehr Leistung willst, gibts natürlich noch ein paar "illegale" Sender, mit teilweise bis zu 250mW (evtl. sogar mehr). Das ist aber IMHO nicht nötig, mit guten Antennen und gutem Empfänger kommt man locker einige hundert Meter, teilweise sogar einige km weit.

Gruß
Chris

[crabtack]

Danke!
Das Teil ist ja perfekt :D
Einige hundert Meter reichen ja vollkommen.
Weiter komme ich mit meinem RFM12BP im legalen 10mW Bereich sowieso nicht.
Dann kann ich ja problemlos lineare Spannungsregler einsetzen.
Wo hast du eigentlich noch Doppelte Leiterbahnen sehen?
Ich habe nur eine gefunden :(

mfg
Olaf

[Che Guevara]

Auf dem Bottom-Layer, neben dem unteren der 3 dicken SMD-Teile (evtl. ist das der Bootstrap-C). Außerdem gibts ein paar Leitungen, die viel zu lange sind.
Wieso verwendest du keine XBee-Module? Die gibts legal mit bis zu 80km Reichweite (ist natürlich übertrieben), aber eine Funke mit <1km Reichweite ist vielleicht keine so tolle Idee. Wenn da mal ein Fehler passiert, ist das Teil u.U. weg und/oder kaputt.

Gruß
Chris

[crabtack]

Hi!
Jo, das sind die Bootstrap Kondensatoren, Leiterbahn ist jetzt ordentlich.
Ich guck mal, dass ich die langen Leiterbahnen noch irgendwie verkürzt bekomme.
Also die XBee Module habe ich mir mal angesehen.
Die günstigen haben ja nur sehr geringe Reichweiten <200m.
Und dann gibt es noch dieses XBee Pro 868 für 80€, was schon sehr teuer im Vergleich zum RFM12 ist.
Außerdem hat es 315mW, das kann ich beim RFM12BP (Bis zu 500mW) auch einstellen.
Ein weiterer Grund, warum ich RFM12 bevorzuge ist, dass ich damit schon Erfahrung habe.
Die Umstellung zum RFM12BP sollte nicht sonderlich kompliziert sein.

mfg
Olaf

[Che Guevara]

Hi,

also einige Bahnen sind definitiv zu lange, in so einer EMV-verseuchten Umgebung bekommst du sonst massive Probleme, vor allem bei größeren Motoren.
Zum Funkmodul:
Da ist es natürlich interessant, wieviel Leistung erlaubt ist. Wie gesagt, eine Reichweite im freien Feld von unter 1km wäre mir persönlich zu riskant, das musst du aber selbst wissen was du brauchst und was nicht.

Gruß
Chris

[crabtack]

Hi!
Danke, dann werde ich mich bemühen, das ordentlich hinzubekommen, soll ja stabil laufen.
Ich hab mich jetzt mal tiefgehender mit Xmegas befasst.
Und bin zum Entschluss gekommen, dass es sinnvoller wäre auch einen Xmega für den Motorcontroller zu verwenden.
Habe dafür erstmal den Schaltplan abgeändert, diesmal ist er auch ordentlich.
Und ich habe noch einige Entstörkondensatoren hinzugefügt, jetzt hat jedes nebeneinanderliegendes Versorgungsspannungs-Paar einen 100nf Kerko.
http://abload.de/thumb/blctrlschnslei.png (http://abload.de/image.php?img=blctrlschnslei.png)

Dabei bin ich mir bei einigen Dingen unsicher.
Meine Überlegung war es, die PWM mit Timer0 an PORTC zu generieren.
Sehe ich es richtig, dass es problemlos möglich ist, per Software auszuwählen, ob die PWM an PC0, PC1 oder PC2 ausgegeben wird?
Zur Datenübertragung verwende ich einfach den SPI an PORTD.

Die Auswertung der BEMF soll über den Komparator an PORTA erfolgen.
Dazu wollte ich den Positiven Eingang des Komparators mit PA0(Mittelpunktspannung) verbinden.
Über den Multiplexer sollen dann jeweils PA1, PA3 oder PA5 auf den negativen Eingang geschaltet werden.
Dadurch kann ich Nullpunktspannung mit der jeweiligen Spannung an PA1,3 und 5 vergleichen und so Interrupts generieren.
Ist diese Überlegung richtig?

Das wars dann auch schon an Xmega spezifischen fragen, ich mach erstmal weiter am Layout.

Edit:
Hab den Spannungsregler durch einen LM7833 ersetzt, der kann bis zu 1A Strom ab, ist mir sicherer.
Edit2:
Ich brauchte mal etwas Abwechslung vom Layouten.
Habe einen Schaltplan für die Fernbedienung erstellt:
http://abload.de/thumb/schaltplanfernbkis2.png (http://abload.de/image.php?img=schaltplanfernbkis2.png)

Gesteuert wird mit einem Dualshock2 Controller, der einfach per Bitbanging ausgewertet werden soll.
Verbindung zum PC kann per UART über einen FT232 per USB hergestellt werden.
So kann der PC zum Beispiel Informationen über Akku, Gyroskope und Höhe erhalten und für den Nutzer Darstellen.
In Zukunft könnte dann auch der PC den Quadrocopter steuern, so dass er auch per Bildauswertung autonome Aufgaben übernehmen kann, die Option halte ich mir mal offen.
Auf dem Board sind noch 4 LEDs vorgesehen.
3 Davon um den Akkustand anzuzeigen, das ganze soll ja auch ohne PC Funktionieren.
Habe mich jetzt doch für ein XBee entschieden (Danke für den Hinweis!) Bei dem ganzen anderen Kram spielen die kosten auch keine Rolle mehr und ich denke mal, dass ich damit deutlich weniger Probleme haben werde.

Dann Layoute ich mal weiter :(


mfg
Olaf

[crabtack]

Hi!

Sorry, für den Doppelpost, aber hier ist ja länger nichts mehr passiert (ich war in Urlaub).

Jedenfalls habe ich jetzt das Layout vom neuen ESC fertig, diesmal mit Xmega.
Ich habe auf möglichst kurze Leitungen von den Mosfets zur BEMF Schaltung geachtet, und die Leiterbahnen im 45° Winkel gelegt.
Das sollte so nach China gehen können oder?
(Polygon ist zur Besseren Übersicht ausgeblendet)

mfg
Olaf

[Che Guevara]

Hi,

sorry, dass ich das schon wieder erwähnen muss, aber die Leiterbahnführung ist grausig!
Manche Bahnen laufen um mehrere Bauteile rum, obwohl die zu überbrückende Luftlinie keine 10mm sind. Außerdem ist VCC der einzelnen Treiber falsch angeschlossen, das sollte bei jedem Treiber vom jeweiligen Mosfets geholt werden, um Spannungsunterschiede zu unterdrücken (mit GND ist es genauso). Außerdem sind wieder einige Leiterbahnen im 90° Winkel.
Ich bin mir nicht sicher, ob du dich da nicht einwenig übernimmst. Du hast auch viel-zu-viele Dukos, das geht mit deutlich weniger. Fang doch nochmal von vorne an, setze alle Bauteile an die gewünschte Stelle (Mosfets links übereinander, daneben dann die Treiber und dann den XMega & Spannungsregler) und fange mit den "einfachsten" (sprich: kürzesten / naheliegendsten) Verbindungen an. Unter den XMega würde ich ein Groundplane machen, damit alle GND-Pins absolut das gleiche Bezugspotenzial haben. Da ich keine Lust habe, mich in dein Layout einzudenken, gebe ich noch den Tipp, die Masse (& VCC) sternförmig auszulegen, kann sein, dass das schon so ist.

Gruß
Chris

[crabtack]

Hi!
Danke für die Antwort.
Du kannst ja nichts dafür, dass meine Leiterbahnführung grausig ist :D
Aber ich denke, so langsam, dass du damit recht hast, dass ich für so ein kritisches Layout noch nicht gut genug Layouten kann.
Deshalb habe ich mich erstmal dazu Entschlossen, eine fertige ESC zu nehmen, ich habe leider nicht die Zeit, um besser Layouten zu lernen und ein vernünftiges Layout hinzubekommen :(
Tut mir Leid, dass deine Mühe erstmal umsonst war.
Aber ich werde deinen vielen Tipps bei den anderen Layouts beherzigen, danke dafür!

Jedenfalls habe ich mir einige ESCs angeschaut und bin begeistert von der KISS 18a ESC.
http://ultraesc.de/downloads/KISS%20ESC%20Manual%20EN%20v01.pdf
Die könnte ich sehr einfach mit nem Xmega über PWM ansteuern.
Meine Motoren dürften Maximal auch nur 10A brauchen, da ist also noch Luft nach oben.
Wenn ich mit dem Projekt fertig bin werde ich mich nochmal an einem eigenem ESC versuchen.

Jetzt muss ich mich nur noch um ein schönes Layout der Hauptplatine kümmern, dass ist ja zum glück nicht so kritisch.
Ich muss mir mal andere Layout Programme als Eagle anschauen, manuelles Routen ist damit einfach grausam.

mfg
Olaf

[crabtack]

Hi!

Ich habe mich jetzt endgültig für die KISS ESC entschieden.
Jedenfalls sind jetzt Schaltplan und Layout für die Hauptplatine fertig.
Schaltplan:
http://abload.de/thumb/mainschvxp0t.png (http://abload.de/image.php?img=mainschvxp0t.png)
Zum Einsatz kommt ein Xmega128A1.
Er kommuniziert über Uart mit dem Xbee.
Der MPU 6000 wird per SPI angesprochen.
Das UP501B GPS Modul wird ebenfalls per UART verbunden.
Über Stiftleisten sind noch diverse Anschlussmöglichkeiten vorhanden, die Namen sollten selbsterklärend sein.
Die Akkuspannung wird vom ADC über einen Spannungsteiler überwacht (Schottkydiode gegen Überspannung).

Das Layout ist diesmal etwas besser Überlegt, die Leiterbahnführung ist zwar immer noch grausig, aber die Störungen von der Motor PWM ist ja recht weit weg.
Ich frage mich nur, ob es eine gute Idee ist, die Versorgung der Motoren über Leiterbahnen zu machen, die das Layout umschließen.
Ich habe das schon oft gesehen, bin mir aber nicht sicher, ob das nicht Probleme verursachen könnte?

Bottom:
http://abload.de/thumb/mainbotpoqet.png (http://abload.de/image.php?img=mainbotpoqet.png)
Top:
http://abload.de/thumb/maintop13r6p.png (http://abload.de/image.php?img=maintop13r6p.png)

Es sind natürlich wieder viele Vias, aber die verursachen keinen Aufpreis.
Viel wichtiger, als das Layout ist mir erstmal die Bauteilauswahl, wenn die stimmt kann ich schonmal bestellen und am Ende meines Urlaubs direkt mit der Fertigung der Fernbedienung anfangen.
für Hilfe wäre ich sehr Dankbar :)

mfg
Olaf

[Jimmybot]

Eine Frage: Warum hast du zwischen den VCCs- und GNDs-Pins soviele Kondensatoren?
Ich betreibe meine ATmegas immer nur mit einem 100nF.

[crabtack]

Hi!
Bei Atmegas habe ich das auch so gemacht.
Aber bei den Xmegas hat jeder Port 2 eigene Versorgungsspannungspins.
Deshalb habe ich jedem einen eigenen Entstörkondensator spendiert, zu viele davon können ja auch nicht schaden :D

mfg
Olaf

[Jimmybot]

Gut das ist dann einleuchtend.

[Che Guevara]

Hi,

die KISS-Regler sind für Multicopter gemacht, das sollte also passen.
Dein neues Layout ist ... naja.
Die große Fläche unter dem XMega ist kontra-produktiv, es sei den, du schließt sie noch an GND an.
Du hast keinen Anschluss für einen Kompass, ohne den wird mit dem PH / CH / WP schwierig bis unmöglich.
Die Masseführung hab ich jetzt nicht überprüft, sieht aber auf den ersten Blick auch sehr verwinkelt aus.
Außen, am Rand die Versorgung für die Motoren zu verlegen ist auch eine eher schlechte Idee, das führt nur zu Problemen, v.a. wenn du den MPU mal mit 16MHz SPI betreiben willst. Da läuft ja ständig gepulste Gleichspannung im 10-100A Bereich drüber.
Außerdem ist das ganze viel zu groß, das ist aber kein wirklicher Kritikpunkt ;)

Gruß
Chris

[crabtack]

Hi!
Danke, für die schnelle Antwort.
Die Größe ist Absicht, so passt das ganze schön aufs Gestell.
Die Flächen unter dem Xmega ist eine GND Fläche, wenn ich das Polygon rein mache, wird die verbunden und dann ist die GND Führung auch nicht mehr Grausig :D
Sorry, für die Blöde Frage, aber was meinst du mit PH / CH / WP? Davon habe ich noch nie gehört und finde auch nichts dazu.
Ich dachte mir, dass ein Kompass eher sinnlos ist, wegen den Magnetfeldern der Motoren, die das Magnetfeld der Erde überdecken.
Hast du damit schon Erfahrungen gemacht?
Also wenn ich noch einen Kopass verwende würde ich ihn entweder per I²C an den MPU6000 anschließen, so kann ich irgendwann auch mal den DMP mit einbeziehen.
Oder ich verwende den MPU 9150, der schon ein Magnetometer integriert hat, nachteil ist halt, dass ich den nur mit I²C ansprechen kann (400KHz), der 9255 ist ja leider noch nicht erhältlich.
Oder ich werde ihn direkt per SPI oder I²C an den Xmega hängen, das wäre wohl die schnellste (Wobei die Kompassmodule alle recht lahm sind) und sicherste Möglichkeit, dafür entfällt aber die Möglichkeit der Nutzung des DMPs.
Viel gutes habe ich zu dem HMC5883L von Honeywell gehört, währe der Brauchbar?
Welche Vorgehensweise würdest du empfhehlen?

Noch was anderes, zur Höhenmessung wollte ich eigentlich das GPS nutzen, aber das soll ja relativ ungenau sein.
Könnte ich mit einem Luftdrucksensor bessere Ergebnisse erzielen oder wäre das unsinnig?
Also viele kommerzielle Quadrocopter haben ja beides verbaut.

mfg
Olaf

[crabtack]

Tag,

Ich habe mich jetzt gegen Luftdrucksensor und Magnetfeldsensor entschieden, da Luftdrucksensoren nicht deutlich präziser als GPS sind.
Der Magnetfeldsensor würde vor allem durch die Motoren so stark gestört werden, dass er kaum die Schwankungen der anderen Sensoren ausgleichen kann, ich denke Gyro und ACC sind vollkommen ausreichend.

Ich habe das Layout überarbeitet, es ist jetzt noch 80x80mm groß und die Masseführung ist direkter.
Es ist zwar nicht optimal, aber ich denke, damit sollte ich keine großen Probleme haben oder?

mfg
Olaf

[Che Guevara]

Hi,

also WP (WayPoint), PH (Position Hold) und CH (Coming Home) sind Funktionen, die du mit dem GPS-Modul bewerkstelligen KÖNNTEST, aber nur in Verbindung mit einem Kompass.
Die berechnete Höhe des GPS-Moduls kannst du nie-und-nimmer für eine Höhehalten Funktion verwenden! ALLE Multikopter (von Firmen, Privatleuten, etc...) verwenden Luftdrucksensoren, um die Höhe zu messen, auch wenn dies natürlich Wetterabhängig ist. Lediglich einige wenige Projekte verwenden US-Sensoren (da fällt mir nur die AR-Drone ein), die meisten (u.a. Arducopter) aber in Verbindung mit einem Luftdrucksensor.
Den MPU würde ich per SPI auswerten, damit kommst du bei 12Bytes (6Bytes für Gyro, 6 für ACC) auf ca. 30us, mit TWI würde das ca. 520us dauern (bei 400kHz). Den Kompass kannst du dann per TWI anschließen, der muss / kann maximal mit 75Hz ausgelesen werden (HMC5883L), das reicht aber auch locker. Den DMP des MPU zu nutzen würde ich nicht machen, da gibts nur einige reverse-engenierd Lösungen, der Hersteller gibt da die nötigen Infos nur gegen Bezahlung raus.


Sorry, für die Blöde Frage, aber was meinst du mit PH / CH / WP? Davon habe ich noch nie gehört und finde auch nichts dazu.

Sorry für die blöde Antwort, aber hast du mal gegoogelt?

Meiner Meinung nach gehst du etwas sehr blauäugig an das Thema heran!
Einen Quadrocopter (oder generell dessen Steuerung) zu bauen, ist nichts, was man mal eben auf ein paar Wochen macht. Dazu gehört auch viel Erfahrung und Simulierung und/oder Ausprobieren.
Ich habe vor einige Jahren damit begonnen eine Steuerung zu entwerfen, von Anfang an bis jetzt habe ich bestimmt über 30 Motoren (â 30€) in den Sand gesetzt, teilweise weil ich nicht fliegen konnte, teilweise weil ich Fehler in der Software hatte, die sich nur in bestimmten, speziellen Flugmanövern (etc..) gezeigt haben. In solchen Fällen braucht man seeeehr viel Durchhaltevermögen (bzw. Interesse & Leidenschaft), um das ganze nicht in die Ecke zu schmeißen, sondern sich tagelang / nächtelang davor zu hocken und zu debuggen und überlegen, wo den jetzt der Fehler stecken könnte ....

Ich will dich damit nicht entmutigen, aber auf die leichte Schulter sollte man es auch nicht nehmen, auch wenn ich sehe, dass du nichtmal in der Lage warst, GRUNDLEGENDE Begriffe zu ergoogeln (WP, CH, PH).

Gruß
Chris

[Rabenauge]

Ohne einen vernünftigen Kompass kannst du ne autonome Navigation vergessen. Das geht, wenn überhaupt, _nur_ per GPS bestenfalls sehr grob.
Im "Stand" schon mal gar nicht.
Die Magnetfelder der Motoren sind nicht wirklich nen Problem- ich betreibe einen 5883l in weniger als 20 cm Abstand von nem 540er Bürstenmotor- geht einwandfrei.
Dafür gibt die Kalibrierung (meiner ist _nur_ hard-iron kalibriert)- damit erreiche ich Genauigkeiten von ungefähr 5 Grad- mit bisschen Filterung unter 3 Grad. Das reicht völlig aus, um metergenau zu navigieren, vorausgesetzt, das GPS hat das auch drauf.
Würd man wahrscheinlich noch genauer hinbekommen, wenn es denn nötig wäre- isses aber nicht.
Die Ausleserate dagegen reicht locker- das GPS wird dir auch nicht mehr als 10 Hz liefern, wozu also brauchst du alle Millisekunden Kompassdaten? Völlig sinnlos...

[crabtack]

Hi, Danke für die Antworten!

Gut, dann kommen Kompass und Luftdrucksensor noch rein.
Ja, ich habe versucht nach den Abkürzungen zu googlen, aber einfach nichts brauchbares gefunden.
Zu autonomen Funktionen habe ich mir noch nichts durchgelesen, da ich die Probleme selbst lösen möchte.
Den Kompass wollte ich dadurch ersetzen, dass durch die GPS Daten (in Bewegung) die Richtung bestimmt wird und bei Drehungen auf der Stelle soll das Gyro übernehmen.
Wenn der Copter dann nah genufgam Homepoint ist soll die Kamera den Landeplatz erkennen und den Copter landen (Er soll nie ohne PC gesteuert werden).
Aber wenn Kompassmodule so gut funktionieren werde ich noch eins einplanen.

Sorry, dass ich gerade etwas unmotiviert bin, aber es gibt einfach nichts, was ich mehr hasse, als Layouten.
Ich möchte einfach so schnell wie möglich damit fertig werden, damit ich mit dem Programmieren anfangen kann, woran ich deutlich mehr Spaß habe.
Ab nächster Woche darf ich endlich wieder arbeiten, dann wird das wieder besser.

mfg
Olaf

[crabtack]

Hi!

So, jetzt passiert endlich mal was.
Letzte Woche sind die Bauteile für die Fernbedienung angekommen, habe dann gleich eine Platine geätzt und bestückt.
Nach 3 Stunden probieren wusste ich dann auch, dass der Kondensator an Reset zum Programmieren weg muss :D
Dann lief erstmal alles gut, Ansteuerung für Dualshock war schnell geschrieben, Kommunikation zum PC läuft auch ohne Probleme und das Funkmodul scheint auch zu funktionieren.
Xmegas sind echt toll.

Jedenfalls habe ich jetzt doch ein Problem, dass ich mir einfach nicht erklären kann.
In meinem Programm sende ich dem Xbee 3 Plus Zeichen um es in den Command Mode zu versetzen, danach soll es ein "OK<CR>" zur Bestätigung senden.
Das kommt auch definitiv an.
Jedenfalls möchte ich die Zeichen, die das Xbee sendet in einer Interrupt Routine in ein Char Array schreiben, das später durch die Debug() Funktion an den PC übertragen werden soll.
In der Funktion gebe ich auch die Zählvariable ISRCounter aus, die in der Interrupt Routine hochgezählt werden soll.
Außerdem Toggle ich in der ISR das untere Nibble von PORTB, dadurch sehe ich an den LEDs, dass die ISR auch ausgeführt wird.
Das Problem ist, dass der ISRCounter immer seinen Ursprungswert behält, in dem Fall 0, ich habe es aber auch mal oben mit 1 definiert, auch dabei bleibt der Wert 1.
Ich kann mir das einfach nicht erklären, der Wert ist auch volatil und global, aber er ändert sich einfach nicht.
Hier das Hauptprogramm:


#include "Dualshock.h"


volatile char USARTdata[20];
volatile uint8_t ISRCounter = 0;


void DebugOut()
{
while(!(USARTD0.STATUS & USART_DREIF_bm));
USARTD0.DATA = ISRCounter;
for(uint8_t i = 0; ((USARTdata[i - 1] != 13) && (i < 20));i++)
{
if(USARTdata[i] != 0x00)
{
while(!(USARTD0.STATUS & USART_DREIF_bm));
USARTD0.DATA = i;

while(!(USARTD0.STATUS & USART_DREIF_bm));
USARTD0.DATA = USARTdata[i];
}

}


}




int main(void)
{
Init::Clock_Init();
Init::USART_Init();
PMIC.CTRL |= PMIC_HILVLEN_bm; //High Level Interrupts freigeben
sei();

PORTB.DIR = 0xFF;
PORTB.OUT = 0x00;
Dualshock::init();
while (!(Dualshock::SetAnalogMode() == 0x73)); //Versuchen in Analog Mode zu wechseln, bis es funktioniert

_delay_ms(1000); //Funkmodul in Command Mode
while(!(USARTC0.STATUS & USART_DREIF_bm));
USARTC0.DATA = '+';
while(!(USARTC0.STATUS & USART_DREIF_bm));
USARTC0.DATA = '+';
while(!(USARTC0.STATUS & USART_DREIF_bm));
USARTC0.DATA = '+';
_delay_ms(1000);

DebugOut();
while(1)
{
Dualshock::getBytes();
//while (!( USARTD0.STATUS & USART_DREIF_bm));
//USARTD0.DATA = Dualshock::RightY;
//while (!( USARTD0.STATUS & USART_DREIF_bm));
//USARTD0.DATA = Dualshock::RightX;
//PORTB.OUT = (Dualshock::RightX & 0x0F);

}
}


ISR (USARTC0_RXC_vect)
{
USARTdata[ISRCounter] = USARTC0.DATA;
PORTB.OUTTGL = 0x0F;
//if(USARTdata[ISRCounter] == 13)
//ISRCounter = 0;
//else
ISRCounter ++;
}
Kann sich das jemand erklären?

Ich habe mal darauf verzichtet, die Klassen zu Posten, die Funktionen sollten soweit selbsterklärend sein.
Falls jemand Interesse hat kann ich natürlich die Dualshock Klasse hochladen.

Edit:
Habe das Problem jetzt gelöst bekommen.
Problem war einfach nur, dass das Xbee etwas mehr als eine Sekunde braucht um nach dem empfangen der "+++" Zeichenfolge das OK zurückzuschicken.
Deshalb wurde zu dem Zeitpunkt, wo die Debug Funktion aufgerufen wird noch kein einziges mal die ISR ausgeführt.
Echt mies, dass ich erst jetzt drauf gekommen bin, naja egal, jetzt läuft alles bestens.
Hoffe, dass der Kram aus China bald ankommt, langsam wird es langweilig mit der Fernbedienung.

mfg
Olaf

[crabtack]

Morgen!

Ich habe wieder ein Problem.
Der Copter ist jetzt Hardwaremäßig fertig, Funk funktioniert auch fehlerfrei, genauso wie die Datenfusion von Gyroskop und Beschleunigungssensor.
Ansteuerung der Motoren läuft auch.
Minimalgas bei 780µS und Maximum bei 1780µS.

Ich habe erstmal eine einfache P-Reglung geschrieben.
Jetzt habe ich das Problem, dass wenn ich die Motoren Ausgeschaltet habe und das Signal an einem der Motoren messe, verhält es sich richtig.
Ist der Copter zu weit nach hinten geneigt wird das Signal länger, ist er nach vorne geneigt kürzer.

Problem ist jetzt, wenn ich die Motoren einschalte und sie Laufen, dann funktioniert es kurz, aber irgendwann bleibt das Signal beim Maximalwert (1780µS) hängen und schwankt nur noch leicht.
Woran kann das liegen?
Ich vermute eine Störung des MPU-6000 (Gyro + ACC) durch die Motoren.
Der MPU-6000 befindet sich unter der Hauptplatine und ist mit einer etwa 10cm langen Flachbandleitung angeschlossen. (Oben Mittig im Bild zu sehen, zwischen Xbee und Spannungsregler)
Könnte es sinn machen, eine Abgeschirmte Leitung zu verwenden?
Ich hätte nur 2 Adrige Leitung da (1Ader + Abschirmung), würde es funktionieren, den Sensor mit insgesamt 5 Leitungen anzuschließen? (SCK, MISO, MOSI, CS, VCC und Masse als Abschirmung)?

Oder Kann es vielleicht noch an etwas ganz anderem liegen?

mfg
Olaf

[PICture]

Hallo!


Ich vermute eine Störung des MPU-6000 (Gyro + ACC) durch die Motoren.

Ich kann dir aus Erfahrung nur empfehlen: nicht vermuten sondern messen und prüfen. Um eventuelle EMV Störungen zu detektieren, würde ich ein Radio mit Lang- bzw. Mittelwellen nehmen, auf niedrigste Frequenz ohne Sender einstellen und zuhören. ;)

[Che Guevara]

Hi,

ich würde da auch erstmal versuchen, soviel wie möglich zu messen & debuggen.
Wenns geht, lass dir doch die MPU-Daten (GYRO, ACC, FUS. WINKEL), die Motor-Daten (PWM-Wert) und soweiter ausgeben. Dann sollte man doch relativ schnell draufkommen, welcher Wert da in die Begrenzung geht.
Wie fusionierst du den die Werte vom MPU? Ist der P-Regler auf diesem fus. Wert aufgebaut oder aus auf was anderem?

Gruß
Chris

[crabtack]

Hi, danke für die schnellen Antworten!

Radio habe ich gerade kein funktionsfähiges in der Werkstatt, ist ironischerweise vorgestern kaputt gegangen....
Aber die Idee ist gut, werde ich definitiv probieren, wenn wieder EMV im Verdacht steht.
Mittlerweile ist aber klar, dass es nicht an EMV Störungen liegt.
Ich habe mal alle relevanten Leitungen mit dem Scope gemessen, da ist kaum was an Störungen drauf, auch wenn die Motoren laufen.

Mir mal die Werte vor der Datenfusion ausgeben zu lassen war eine gute Idee.
Das Problem ist, dass der Beschleunigungssensor durch die Vibration der Motoren gestört wird.
Das Gyroskop gibt die richtigen werte aus.
Wenn die Mototoren aus sind erhalte ich vom Beschleunigungssensor etwa den Wert 0x4000 (Entspricht 90°), also er liegt horizontal(Habe ihn ziemlich exakt ausgerichtet).
Wenn ich nun die Motoren einschalte steigt der Wert auf etwa 0x6000 (Entspricht 135°, also 45° Abweichung).
Wenn ich die Motoren Abschalte gehen die Werte wieder runter auf 0x4000.
Das Ergebnis der Fusion hängt dem Wert natürlich etwas hinterher, aber nimmt nach einer gewissen Zeit den Wert an.
Problem ist, dass der Ausgabewert des Beschleunigungssensors nicht nach unten und oben schwankt, sondern nur auf etwa 0x6000 geht und dort bleibt, sobald die Motoren an sind, dadurch wird das Ergenis recht schnell in die Höhe getrieben.

Auch wenn ich den Einfluss des Beschleunigungssensors stark reduziere bleibt das Problem bestehen, dauert dann halt noch was länger.

Der relevante Teil zur Datenfusion und zum Auslesen des MPU-6000 sieht so aus:


void MPU::Init()
{
WriteReg(107,0x83); //Reset und PLL mit ZGyro Referenz als Takt
_delay_ms(5);
WriteReg(107,0x03); //PLL mit ZGyro Referenz als Takt
_delay_ms(1);
WriteReg(106,0x10); //I²C Deaktivieren, SPI aktivieren
_delay_ms(1);
WriteReg(25,0x00); //Sample Rate = GyroOutputRate/(1 + SMPLRT_DIV)
_delay_ms(1);
WriteReg(26,0x06); //Tiefpass 5Hz
_delay_ms(1);
WriteReg(27,0x18); //Gyro +/- 2000°/s
_delay_ms(1);
WriteReg(28,0x00); //ACC +/- 2g
_delay_ms(1);

TCE1.CTRLA = TC_CLKSEL_DIV1024_gc;
TCE1.CTRLB = 0x00; //Normal Mode
TCE1.PER = 0xFFFF; //Obergrenze

Xangle.integer = 0x4000;
Yangle.integer = 0x4000;


}


void MPU::GetSensorData()
{
uint8_t dump;
PORTC.OUT &= ~(1 <<PIN4);
dump = SpiTransfer(0xBB);
Ax.byte2 = SpiTransfer(0x00);
Ax.byte1 = SpiTransfer(0x00);
Ay.byte2 = SpiTransfer(0x00);
Ay.byte1 = SpiTransfer(0x00);
Az.byte2 = SpiTransfer(0x00);
Az.byte1 = SpiTransfer(0x00);
Temperature.byte2 = SpiTransfer(0x00);
Temperature.byte1 = SpiTransfer(0x00);
Gx.byte2 = SpiTransfer(0x00);
Gx.byte1 = SpiTransfer(0x00);
Gy.byte2 = SpiTransfer(0x00);
Gy.byte1 = SpiTransfer(0x00);
Gz.byte2 = SpiTransfer(0x00);
Gz.byte1 = SpiTransfer(0x00);



PORTC.OUT |= (1 << PIN4);
}


void MPU::CalcAngle()
{
MPU::AccXangle.integer = (atan2(MPU::Az.integer,MPU::Ay.integer) * 10430); //Winkel Berechnen und auf werte von -32766 bis + 32766 hochskalieren
MPU::AccYangle.integer = (atan2(MPU::Az.integer,MPU::Ax.integer) * 10430);
MPU::AccZangle.integer = (atan2(MPU::Ay.integer,MPU::Ax.integer) * 10430);

float deltaTime = ((float)(TCE1.CNTL + (TCE1.CNTH << 8)) / 31250.0f); //Verstrichene Zeit
TCE1.CNTL = 0;
TCE1.CNTH = 0;
Xangle.integer = 0.999*(Xangle.integer +(-Gx.integer * deltaTime)) + 0.001*AccXangle.integer; //Fusion
Yangle.integer = 0.999*(Yangle.integer +(-Gy.integer * deltaTime)) + 0.001*AccYangle.integer;
Zangle.integer =(Zangle.integer +(-Gz.integer * deltaTime));
//PORTH.OUTTGL = 0x01;
}


uint16_t MPU::GetXangle()
{
return Xangle.integer - 0x4000; //Anpassen, dass der Wert bei horizontaler Lage 0 ist.
}


uint16_t MPU::GetYangle()
{
return Yangle.integer - 0x4000;
}


Habe ich vielleicht nur einen Programmfehler oder liegt es wirklich am Beschleunigungssensor selbst?
Ich Gehe übrigens von Kreisen mit 65536° aus, um 2Byte voll auszunutzen.

Edit:
Wenn ich den Tiefpass vom MPU-600 rausnehmen, also das Register 26 auf 0x00 setze, dann wird es etwas besser, dann schwanken die werte um die 0x4000.
Problem ist, dass viel häufiger Werte deutlich über 0x4000 auftreten, als Werte unter 0x4000.
Also nach der Fusion erhalte ich immer Werte über 0x4000, meistens zwischen 0x5000 und 0x6000

mfg
Olaf

[Che Guevara]

Hi,

also wenn ich mich recht erinnere, hatte Harald ( https://www.roboternetz.de/community/threads/55714-Shrediquette-NanoQuad ) damals fast das selbe Problem, da half glaube ich nur die Suche nach anderen Motoren, die runder laufen.
Was mir spontan auffällt:
- Beim MPU-6000 ist der DLPF auf 5Hz gestellt, das ist zu stark --> ich habe ihn auf 44Hz, etwas mehr ginge wohl auch noch (experimentiere gerade mit nem FIR-Filter)
- Beim Komplementärfilter beziehst du die Regelfrequenz (dt) mit ein. Da du aber in Fixed-Point rechnest und deswegen sowieso skalieren musst, würde ich (auch im Bezug aufs Ergebnis) den Filter mit einem festen Zeitintervall (z.b. 2ms oder 1ms oder..) aufrufen, so ist dt konstant und kann entfallen. Du musst dann nur den ACC-Winkel richtig skallieren.
- ATAN2 ist relativ teuer, es ginge auch mit arcsin. Wenn du aber bei ATAN2 bleiben willst, würde ich folgende Gleichung vorschlagen:


TotalForce = sqrtf((AccX*AccX)+(AccY*AccY)+(AccZ*AccZ));
RollAngleAcc = atan2(AccY, TotalForce);
NickAngleAcc = atan2(AccX, TotalForce);

Damit beziehst du die aktuelle Gesamtbeschleunigung mit ein und der Fehler durch "Querbeschleunigungen" wird geringer.
- Beim Komplementärfilter solltest du statt "0.999" & "0.001" lieber zwei Variablen nehmen, z.b. GyroInfluence & AccInfuence. Dann beschreibst du eine Variable und berechnest (!!!) aus dieser die andere Variable. So verhinderst du "Rundungsfehler" durch die begrenzte Nachkommastellenzahl bei Floats. Ansonsten könnte es passieren, dass 0.001f + 0.999f != 1.0f .
- Den Komplementärfilter würde ich als Float berechnen, ansonsten bekommst du ein ähnliches Problem wie beim Punkt vorher (Rundungsfehler).
- Hin und wieder ein Type-cast würde nicht schaden, schützt vor üblen Überraschungen ;)
- Wenn du den Timer TE1 verwendest, addressierst du immer CNTL & CNTH. Wieso nimmst du nicht einfach CNT (u16)?

Hoffe, das sind jetzt nicht zuviele Punkte auf einmal, aber ich hab mit den meisten davon selbst schon zu kämpfen gehabt ...

Gruß
Chris

[crabtack]

Hi!

Zu viele Punkte gibts nicht, ich bin dankbar für jeden einzelnen. :D
Die 5Hz waren nur zum testen, ob es das Verhalten des Beschleunigungssensors verbessert, ursprünglich hatte ich auch die 44Hz genommen (Wie in deinem Programm vom Anfang).

Die Idee, die Berechnung in einem festen Zeitintervall erfolgen zu lassen ist gut, lasse ich dann einfach per Interrupt steuern.

Ich musste schon feststellen, dass die Berechnung etwas Langsam ist, das Programm schafft nur etwa 1000 Durchläufe pro Sekunde, da sollte noch mehr möglich sein.
Sobald die groben Fehler beseitigt sind werde ich mal darauf umstellen, danke!

Zu den Rundungsfehlern.
Ich denke, dass ein 16bit int genau genug ist, dafür habe ich ja alles auf Werte von 0 bis 2^16 skaliert, damit ich nicht den höheren Rechenaufwand von float in kauf nehmen muss.
Oder irre ich mich?

- Hin und wieder ein Type-cast würde nicht schaden, schützt vor üblen Überraschungen :wink:
Du meinst, dass ich jeweils explizit auf signed oder unsigned casten soll?


- Wenn du den Timer TE1 verwendest, addressierst du immer CNTL & CNTH. Wieso nimmst du nicht einfach CNT (u16)?
Ich wusste bisher einfach nicht, dass diese Möglichkeit besteht und war es so gewohnt, aber wenn das geht werde ich es ab jetzt so machen.

Ich bin dem Problem jetzt etwas näher gekommen.
Ich habe mir mal die Werte, die das Gyroskop ausgibt über UART ausgeben lassen und grafisch dargestellt.
Dabei haben sich die Y und Z Achse so verhalten, wie ich es erwartet habe.
Der Wert bleibt bei Ausgeschalteten Motoren stabil, reagiert auf Lageänderungen und Erschütterungen, wie er soll.
Wenn ich die Motoren Einschalte schwingt der Wert um den eigentlich richtigen Wert (z.B. 0).
Wenn ich das Gleiche auf der X Achse mache, dann verhält es sich ohne Motoren normal und reagiert auf Lageänderungen und Erschütterungen.
Wenn ich aber die Motoren einschalte ist der Ausgangswert ungewöhnlich stark gestört.
Und vor allem Schwingt er nicht um 0, sondern darunter.
Ich habe die Bilder in den Anhang gesteckt, damit man sieht, was ich meine.

Ich verstehe nicht, wie das sein kann.
Die Y Beschleunigung wird auf die gleiche Weise ausgelesen, wie der X und die Z Beschleunigung.
Woher kann es kommen, dass nur die X Beschleunigung fehlerhaft ist?

@Chris: Gibt es eigentlich Videos oder sonstige Doku zu deinem Copter?
Würde mich mal interessieren, wie der sich so verhält. :)

mfg
Olaf

[Che Guevara]

Hi,

also zu den Rundungsfehlern. Nehmen wir mal dieses Stückchen Code:


Xangle.integer = 0.999*(Xangle.integer + (-Gx.integer * deltaTime)) + 0.001*AccXangle.integer;

So sähe es schonmal mit Typecase aus (ich verwende lieber zuviel als zuwenig wie man merkt):


Xangle.integer = (int16_t)((0.999f*(float32_t)(Xangle.integer+((flo at32_t)-Gx.integer * deltaTime)) + (0.001f*(float32_t)AccXangle.integer));

So wird auch korrekt gerechnet. Hast du mal überprüft, was dabei rauskommt, wenn man einen int16_t (vor allem sehr kleine Werte) mit einem float (0.999 oder 0.001) multipliziert?
Diese Kurve vom AccX sieht wirklich etwas komisch aus, da fällt mir momentan auch keine Erklärung ein (außer evtl. Vibrationen von den Motoren).
Ein Video bzw. Homepage steht schon lange auf der Liste, aber dafür hab ich irgendwie nie so wirklich Zeit ...

Gruß
Chris

[crabtack]

Hi, danke für die Antwort!

Bisher hatte ich noch nicht mit float auf Mikrocontrollern gearbeitet, sondern nur auf dem PC, dort hatte ich damit nie Probleme gehabt.
Ich werde es mal auf dem Controller ausprobieren, sobald ich wieder in der Werkstatt bin.

Also es liegt definitiv an den Vibrationen der Motoren.
Das "Schwingen" der werte auf den Anderen beiden Achsen liegt ja auch daran.
Problem ist nur, dass die AccX Kurve nicht um die Nullinie Schwingt und außerdem viel zu stark.
Vibrationen können ja eigentlich nicht auf eine Achse viel Stärker wirken als auf die andere, zumindest in diesem Fall nicht.
Ich finde einfach keinen Grund dafür, bin jetzt alles nochmal mehrfach durchgegangen.

mfg
Olaf

[crabtack]

Hi!

Das Problem ist endlich gelöst:mrgreen:
Ich habe einfach die Motoren mit Gummimatten gedämpft, damit die Schwingungen nicht so stark aufs Gestell wirken.
Jetzt sind die Vibrationen nicht mehr so schlimm und laufen vor allem Symmetrisch.

Jetzt noch was an der Reglung feilen, dann gibt es hoffentlich bald einen Testflug!

mfg
Olaf

[crabtack]

Hi!

Also, wenn ich den Copter in einem Gestell habe, wo er sich nur um eine Achse drehen kann ist alles bestens.
Lässt sich gut steuern und bleibt stabil.

Wenn ich ihn jetzt frei fliegen lasse klappt es prinzipiell ganz gut.
Problem ist, dass er relativ stark in eine Richtung geneigt bleibt (Y Achse).
Wenn ich nun etwas zu viel Gas gebe, kippt er um.

Also, ich denke, ich muss die Parameter weiter einstellen.
Aber wie soll ich das am besten Machen, ohne viel zu viele Rotoren zu zerstören?

Ich habe die PID übrigens etwas unkonventionell gelöst, um Fließkommazahlen zu umgehen:


int16_t PID::Compute(int16_t error)
{

//errSum += (error); //Integralanteil

if ((errSum + error/prescaler) > Imax) //errsum begrenzen
errSum = Imax;

else if ((errSum + error/prescaler) < Imin)
errSum = Imin;
else
errSum += (error /prescaler);

float dErr = (error - lastErr); //Differentialanteil

lastErr = error;

return (int16_t)((error/kp) + (dErr / kd) + (errSum/ki));

}




pidX.SetParam(420,10000,10); //P, I, D
pidX.SetLimits(-5000,5000);
pidX.SetPrescaler(100);
zum Test war der I Anteil verschwindend gering, der war früher mal höher

Aber Prinzipiell spricht nicht gegen das Prinzip, oder?

mfg
Olaf

[radbruch]

Hallo

Ich kenn mich nicht aus, aber wenn du hier ankommst berechnest du das zum dritten mal:

else
errSum += (error /prescaler);

Gruß mic

[crabtack]

Hi!

Danke, für die Schnelle Antwort!

Allerdings habe ich es bis dahin nicht wirklich 3 mal berechnet.

Weiter oben rechne ich errsum + error/prescaler.
Dabei wird der Wert aber nicht wieder in errsum gespeichert, sondern nur zum Vergleich genutzt und ist dann wieder "weg".
Mit dem += Operator wird das Ergebnis direkt in errsum gespeichert und bleibt erhalten.

mfg
Olaf

[crabtack]

Morgen!

Mittlerweile fliegt das Teil und ich bin überglücklich :D
Ich musste die Frequenz der PWM, mit der ich die Motoren ansteuer von 50Hz auf 1500Hz erhöhen.
Läuft noch nicht perfekt, aber es kann sich schonmal sehen lassen:
<a href="https://www.youtube.com/watch?v=C99vFfhYrd4&amp;feature=youtu.be" target="_blank">
https://www.youtube.com/watch?v=C99vFfhYrd4&amp;feature=youtu.be (https://www.youtube.com/watch?v=C99vFfhYrd4&feature=youtu.be)

Problem ist nur, wenn ich lenke und dann aufhöre zu lenken fängt er an zu wippen, im Video ab 0:22 zu sehen.
Woran kann das liegen?
Und wie behebe ich es am besten?

Eigentlich muss dafür nur die Reglung direkter reagieren oder?

mfg
Olaf