BLDC für Hexakopter

derNeue

Neues Mitglied
19. März 2014
6
0
0
Radeberg(er)
Sprachen
  1. ANSI C
Hallo!

In meinem Willkommens-Thread wurde ja nun schon mehrfach geäußert, das der eine oder andere gern etwas zu meinem BLDC-Regler wissen möchte.

In ferner Zukunft ist mal ein Hexakopter geplant. Begonnen hatte die Idee, als ich die Seite vom Mikrokopter gesehen habe. Und Holger hat irgendwie vieles selbst programmiert. Das hatte mir gefallen. Darum wollte ich auch einen bauen, aber nicht wie die meisten, fertige Baugruppen nur noch zusammenstellen, sondern ich wollte was mir möglich ist auch selber bauen. Motoren, Akkus und Propeller habe ich natürlich gekauft, das ist einfach jeweils schon eine Wissenschaft für sich, als das man sowas auch zuhause selbst bauen könnte. Aber die BLDC-Regler, die eigentliche Steuereinheit für den Hexa und die Fernsteuerung könnte man selbst bauen. Begonnen habe ich mit mit den Motoren-Reglern.

Da ich mich selbst auch noch als Anfänger bezeichne, habe ich natürlich auch eine Reihe Fehlschläge weg. Bei so einem Regler ist auch das Laiterplatten Layout wichtig. Ich habe insgesamt hier 5 verschiedene Layouts liegen, wovon eigentlich nur das letzte wirklich funktioniert. Da ich von den Bauteilen her nicht wirklich Ahnung hatte, habe ich mir natürlich das eine oder andere beim Mikrokopter abgucken wollen. Der Holger hat seine Halbbrücken mit einem P- und einem N-Mosfet realisiert. Diese Mosfets zu besorgen, war nicht ganz ohne, habe sie aber bekommen und bin damit kläglich gescheitert. Ich weis bis heute nicht, wie Holger das mit den P-Mosfets hinbekommt, bei mir haben die erst nach ca. 1ms gesperrt, was natürlich viel zu viel Zeit ist. Also habe ich umgeschwenkt auf den Halbbrückentreiber IR2101. Mit Hilfe von denen kann man auch die High-Side mit einem N-Mosfet beschalten. Jetzt hat dieser Part besser funktioniert, aber ich bin mit meinem Controller nicht klar gekommen. Ich habe am Anfang den Attiny261 genutzt, der genau für solche Motorenanwendungen spezielle Timer-Modi's hat. Sicher funktioniert dieser ganz wunderbar, aber eine Controller-spezifische Besonderheit hatte ich nicht mitbekommen, die Programmier-Pins sind an den Pins, wo auch die Timerausgänge für die Halbbrücken sind. So kann es vorkommen, das während des Programmierens High und Lowside gleichzeitig durchgeschalten werden -> Kurzschluss. Habe ich zu dem Zeitpunkt nicht mitbekommen, warum das so ist, ich habe mich dann einfach für den Atmega88 entschieden.

Nachdem die neue Platine angekommen war und ich alles gelötet hatte, stellte ich fest, das der Motor zwar losdreht, aber irgendwie nur geringe Drehzahlen möglich waren. Etwa ein halbes Jahr habe ich gesucht, wollte eigentlich fast schon aufgeben. Habs dann aber gefunden. Ich nutzte die Kopplung zwischen Analog Komparator in Input Capture Unit von Timer 1. Ich fand die Option einer Rauschunterdrückung eig gut, vier Takte lang muss das gleich Signal anliegen, erst dann kommt es zum Input Capture Interrupt. Aber genau da lag der Fehler. Als ich das ohne Rauschunterdrückung gemacht habe, lief auf einmal alles.

Dann habe ich noch die Strommessung eingebaut, das lief ohne weitere Zwischenfälle ab und funktioniert gut.

Kommunikation läuft über I²C. Ich sende nur einen 8-Bit Wert. Die Werte 1 bis 10 könnte ich für irgendwelche Steuerbefehle verwenden, bis jetzt ist es einfach Start und Stop. Werte zwischen 11 und 245 werden einfach direkt als PWM-Wert weitergereicht. Werte über 245 werden ignoriert. Wenn ich Daten vom Regler hole bekomme ich zwei 8-Bit werte. Der erste mit 32multipliziert ergibt die Drehzahl pro Minute und der zweite ist bis jetzt einfach der ADC Wert meiner Strommessung.

Ich habe einen aktiven Freilauf realisiert. Ansich ganz einfach. Ich verwende den Timer 2 im phasenrichtigen Modus. Er zählt also erst rauf, dann wieder runter. Der OC2A-Pin wird am Anfang gesetzt und bei Compare Match gelöscht. Mit OC2B-Pin ist es genau anders herum. Der Unterschied zwischen OC2A und OC2B ist die Totzeit, die die Mosfets zum sperren brauchen. Dann habe ich einen kleinen Trick angewandt, der hier sehr gut erklärt wird.

Ich habe den Regler nun nicht bastlerfreundlich aufgebaut, so ziemlich alles als SMD ausgeführt. Mir ist es auch nicht wichtig, das hauptsache viele meinen Regler nachbauen. Für mich war es nur wichtig, das ich es hinbekommen habe. Bilder kann ich die Tage nochmal machen, wenn gewünscht, aber meine Handykamera braucht besseres Licht, ist nicht mehr das jüngste, sieht man ja auch an dem grauenvollen Video des Reglers. Ist keine Minute lang, ist eben schwierig, was will man zu so einem Regler zeigen.



Jetzt warte ich auf die Platinen, damit ich den Regler noch weitere 5x aufbauen kann. Als nächstes soll es dann an die Fernsteuerung gehen. Da habe ich auch schon ein paar fertige Module bei Pollin gekauft, RFM12BP. Das wird die nächste Baustelle. Eine alte ganz einfache Fernsteuerung habe ich schon daliegen. Diese will ich ausschlachten, dass ich nur noch das Gehäuse und die Kreuzknüppel verwende.


Über die Steuereinheit auf dem Kopter habe ich mir bis jetzt am wenigsten Gedanken gemacht, obwohl das eigentlich der wichtigste und warsch auch schwierigste Teil des Ganzen ist. Dort bin ich bis jetzt am überlegen, ob ich da einen ATXMega einsetze. Aber das muss im Kopf noch reifen :)


Wenn Fragen sind, dann immer her damit, ich versuch sie soweit mir möglich zu beantworten.


Dennis
 
Oha... Deine verlinkte Quelle ist ja da recht interessant...
Das Prinzip mit der gemeinsam genutzten PWM für alle 3 Phasen raff ich trotzdem nicht. In der Tabelle darüber wird ja verdeutlicht, daß immer genau ein Motoranschluß frei ist, genau einer auf Gnd liegt, und genau einer auf Vcc (wobei letzterer über die PWM zerhackt wird).

Wie kann dies mit dem gemeinsamen PWM erreicht werden? Der PWM selbst wechselt ja immer zwischen Vcc und Gnd.
Die anderen Pins können entweder auf Vcc oder auf Gnd oder tristate geschaltet werden (hi über Pullup macht hier wohl keinen Sinn).
Pin ist Vcc -> Motoranschluß geht auf Vcc
Pin ist tristate -> PWM liegt über den Widerstand an -> Motoranschluß geht auf PWM-zerhacktes Vcc
Pin ist Gnd -> übersteuert PWM- > Motoranschluß Gnd

Was spräche denn dagegen, die PWM-Ausgabe von einem Pin auf den nächsten umzuschalten? Nur in Software-PWM? Quatsch! Der Timer soll die PWM mit einem Compare-Register generieren, zu den erkannten/berechneten/abgewarteten Kommutierungszeiten wird dann einfach die Ausgabe auf einen anderen Pin umgeschaltet.
Dazu braucht man also ein Output-Compare-Unit, bei welchem mindestens 3 unterschiedliche Pins variabel als Ausgang verwenden kann.
Die 3 Pins wechseln dann zyklisch zwischen Tristate, Gnd und PWM-Ausgabe, bei der Kommutierung müßten also erst alle 3 als Eingang geschaltet werden (DDR=0) -> tristate,
danach wird der PWM-ausgebende Pin umgeschaltet (hat wegen Eingang noch keinen Effekt), das PORT-Register neu beschrieben (PWM-Pin auf Hi, Gnd-Pin auf lo), der dritte ist egal, anschließend werden die beiden via DDR-Register als Ausgang deklariert, der dritte bleibt dabei Eingang. Die internen Pullups bleiben dabei dauerhaft aus.
Der Tiny441 kann das zB, von Vorteil ist hierbei, daß die Pullups über ein eigenes Register zugeschaltet werden (und nicht mehr durch PORT und DDR beeinflußt werden). Allerdings habe ich mir das mit den Override bei PWM-Ausgabe hier noch nicht genauer angesehen.

Desweiteren werden für die Kommutierung 3 unterschiedliche Signale (abwechselnd) über den AC mit deren Mittelpunkt (?) verglichen. Dazu wird der Multiplexer des ADC herangezogen. Wenn also der Motorstrom überwacht werden soll, muß der MUX auf den ADC zurückgeschaltet werden, solange wie gemessen wird. Und anschließend wieder zurück zum AC, oder wie?

Für den Strom reicht ja ein gemeinsamer Sense-Widerstand Gnd-seitig von den 3 Lo-FETs (insbesondere ist ja eh immer nur einer von den dreien durchgeschaltet, oder)?

Aber genug von meinen wirren Gedanken - mach weiter...;)
 
Hallo!

Das Prinzip mit der gemeinsam genutzten PWM für alle 3 Phasen raff ich trotzdem nicht.

Na du beschreibst es doch darunter selbst. Sobald ich einen Pin auf Eingang schalte, liegt dort die PWM an. Ich versteh gerade noch nicht, welchen Teil du nicht verstehst.

Der Timer soll die PWM mit einem Compare-Register generieren, zu den erkannten/berechneten/abgewarteten Kommutierungszeiten wird dann einfach die Ausgabe auf einen anderen Pin umgeschaltet...
Der Tiny441 kann das

Und dieser ist gerade mal seit Ende letzten Jahres auf dem Markt und ist zumindest meines Wissens der erste, der das kann. Ich habe den BLDC nicht mal eben in 6 Wochen entwickelt, da ging ein wenig mehr Zeit ins Land. Und da gabs den Attiny441 noch nicht. Außerdem habe ich auf die schnell keinen Händler gefunden, wo ich den kaufen kann. Aber ansich ein sehr interessanter Tiny, danke für den Hinweis, vielleicht hast du ja schon irgend eine Bezugsquelle, wo man auch mal 2 Stück kaufen kann, und nicht nur 100k. Interessant sind zwei Komparatoren und eben die umschaltbaren PWM-Ausgänge. Wenn es diese Funktionen auch mal in etwas größeren Tinys oder sogar Megas gibt, könnte man es vielleicht sogar schaffen, zwei BLDC-Motoren mit einem µC zu steuern. Wie gesagt, da es diese Funktion noch nicht in einem mir bekannten µC von Atmel gab, musste man sich eben anders behelfen. Weil mit Software-PWM hätte ich ja eine riesen Masse an Interrupts, die womöglich bei höheren Drehzahlen zu Problemen führen könnten.

Desweiteren werden für die Kommutierung 3 unterschiedliche Signale (abwechselnd) über den AC mit deren Mittelpunkt (?) verglichen. Dazu wird der Multiplexer des ADC herangezogen. Wenn also der Motorstrom überwacht werden soll, muß der MUX auf den ADC zurückgeschaltet werden, solange wie gemessen wird. Und anschließend wieder zurück zum AC, oder wie?

Genau so. Da ich keine 10bit Genauigkeit beim Motorstrom haben will, kann ich den ADC auch mit mehr als 200khz betreiben. Ich takte den ADC mit 1MHz. Laut Datenblatt benötigt er dann für die erste Wandlung 25Takte. Das reicht dicke bis zur nächsten Kommutierung. Rechnerisch könnte man also im 40khz-Rythmus neue Werte vom ADC bekommen. Und danach schaltet man wieder auf den AC, da ist keine "Einschwingzeit" (oder wie man das nennen soll, mir fällt grad kein besseres Wort ein) im Datenblatt angegeben, also direkt nach dem Takt, in dem man umgeschaltet hat funktioniert er wieder. Also könnte ich theoretisch 40000/6 = 6666.67 elektrische Umdrehungen pro Sekunde haben. Ein etwas utopischer Wert, den ich so mit meinen Motoren nicht annähernd erreichen werde. Die Genauigkeit dieser Messung ist eben bisschen unterirdisch, ich bin bei 120mA pro Digit. Aber das reicht mir völlig zu, evtl. programmiere ich nochmal einen Überstromschutz ein, muss ich mal überlegen, Zeit dafür hätte der µC noch genügend.

Für den Strom reicht ja ein gemeinsamer Sense-Widerstand Gnd-seitig von den 3 Lo-FETs

Genau so hab ich es gemacht. 5mOhm hat er und ich hab nur nen einfachen lm258 als Verstärker mit einigen Tiefpassfiltern. So muss ich keine PWM-High-Zeit abwarten, bis ich den ADC wandeln lasse.

Ich häng mal noch nen Schaltplan an, vielleicht interessiert den einen oder anderen.

Schaltplan.png

Dennis
 
Hi,

vorweg möchte ich nochmals(?) darauf hinweisen, daß ich Dich (bzw Dein Konzept) hier in keinster Weise angreifen wollte - ich mache mir nur meine eigenen Gedanken dazu.
Du hast zu "Trick 17" ja den externen Link gehabt, wo ein etwas anderer FET-Treiber verwendet wurde. Ich hatte mir die entsprechenden Datenblätter nicht angesehen, aber die Pinbezeichnungen hatte mich annehmen lassen, daß !SD zum abschalten des gesamten Treibers verwendet werden kann, und die FETs über IN angesteuert werden. Dabei war ich fälschlicherweise davon ausgegangen, daß der IN-Zustand auf die FETs übertragen wird, und somit 3 Zustände am In benötigt werden würden. Nach einem Blick in das Datenblatt ist die Sache klar, Du benötigst (beim 2104) je Phase einen eigenen PWM-fähigen Pin und einen Pin (für !SD) zum Tristateschalten. Statt der 3 separaten PWMs geht dann Trick 17 mit insgesamt 3+3+1 Pins (für 3 Phasen).

Beim von Dir verwendeten 2101 steuerst Du quasi beide FETs separat an. Für die 3 Hi-FETs bräuchtest Du wieder 3 separate PWMs (oder Trick17), die 3 Lo-FETs sollten sich doch aber über 3 einfache Pins nutzen lassen...
Ein low-Pegel am Eingang des ICs legt auch den Ausgang Lo, sodaß der dort hängende Lowside-FET offen ist, insofern werden die FETs dieser Phase nicht kurzgeschlossen, oder? Wenn der Eingang (und auch der Ausgang) high sind, der angeschlossene LowSideFET durchschaltet, nimmt diese Phase Strom aus einer anderen Phase (über den dort durchgeschalteten/-gepulsten HighSideFET) auf.
Insofern brauchst Du doch den PWM nur auf einer Seite (entweder oben oder unten), oder?

Zur Strommessung: irgendwie paßt das mit dem 0V-Netz nicht so ganz, oder? Meine Anmerkung bezog sich da auch eher auf die (Deine) Quelle:
...Strommessung, die man natürlich nicht für jede Phase einzeln aufbauen muss.
^^fand ich ein wenig "schwammig" formuliert...
Den Tiny441 findest Du zB bei Digikey, ansonsten kannst Du auch nach dem Tiny841 suchen (falls Dich die größeren Speicher nicht stören;)).
Und ja, der ist relativ neu - es gibt aber auch andere Controller mit zuweisbaren OC-Pins. Der Tiny87/167 hat beim Timer1 zB für jedes der beiden OC-Units 4 wählbare Pins. Allerdings hier noch mit der "alten" Pullup-Logik...
Und den gibt's bereits seit 2010. Den kannst Du sogar bei Christian Sharpe kaufen.
 
Hallo!

vorweg möchte ich nochmals(?) darauf hinweisen, daß ich Dich (bzw Dein Konzept) hier in keinster Weise angreifen wollte

Um Himmels Willen, so habe ich das auch nicht aufgefasst. Ich finde konstruktive Hinweise immer gut, vorallem wenns um Verbesserungen geht, oder eben einen Alternativ-Vorschlag. Aber ich werde wohl jetzt keinen anderen Controller mehr dafür einsetzen, jetzt habe ich langsam lange genug an den Motor-Reglern gebastelt, ich möchte mal einen Schritt weiter gehen. Aber so ein Hinweis ist natürlich für andere immer gut, die sich vielleicht auch überlegen, sowas zu bauen. Ich habe schließlich auch nicht alles selber rausgefunden, sondern habe mir genauso bei anderen das eine oder andere abgeschaut.

wo ein etwas anderer FET-Treiber verwendet wurde.

stimmt, daran hab ich nicht gedacht, mein Fehler

Ein low-Pegel am Eingang des ICs legt auch den Ausgang Lo, sodaß der dort hängende Lowside-FET offen ist, insofern werden die FETs dieser Phase nicht kurzgeschlossen, oder? Wenn der Eingang (und auch der Ausgang) high sind, der angeschlossene LowSideFET durchschaltet, nimmt diese Phase Strom aus einer anderen Phase (über den dort durchgeschalteten/-gepulsten HighSideFET) auf.
Insofern brauchst Du doch den PWM nur auf einer Seite (entweder oben oder unten), oder?

Ich weis jetzt nicht, ob ich dich richtig verstehe. Meine verwendeten Treiber-ICs sind nicht gegenseitig verriegelt. Also ich kann die High und die Lowside gleichzeitig durchschalten, wenn ich das möchte. Um einen Fet, egal ob High oder Lowside durchzuschalten, muss ich High-Pegel an die Eingänge anlegen. Jetzt habe ich den sog. aktiven Freilauf mit realisiert. Also in der PWM-Off Zeit schalte ich den Lowside-Fet durch, dass der Rückstrom nicht durch die Body-Diode muss, sondern schön niederohmig durch den Fet zurückfließen kann. In dieser PWM-Off Zeit sind dann auf zwei Phasen die Low-Side-Fets durchgeschalten.

irgendwie paßt das mit dem 0V-Netz nicht so ganz, oder?

Was meinst du mit 0V Netz?

Der Tiny87/167 hat beim Timer1 zB für jedes der beiden OC-Units 4 wählbare Pins.

Okay, also doch eher Unwissenheit meinerseits. Ehrlich gesagt wusste ich vorher(vor deinem hinweis) nicht einmal, das es eine solche Funktion in manchen µC gibt. Somit habe ich auch nie danach gesucht. Sei's drum, jetzt hab ich den Mega88 gewählt und es klappt mit dem.

Dennis
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)