Guten Tag, ich hab auf der Arbeit (Ausbildung) einen Robotterarm zum spielen bekommen. Leider ist die Steuerung futsch und ich muss eine komplett neue bauen. Der Arm hat insgesammt 5 Motoren mit jeweils einem Tachogenerator. Die motoren sollen über PWM angesteuert werden. Ich würde das ganze gerne über Mikrocontroller ansteuern. Nun gild es einen geeigneten Controller zu finden. Hat da jemand eine idee? Er braucht ja mindestens 5 pwm chanels. Oder währe es sinnvoll eine Sterntopologie zu basteln mit jeweils einem Controller pro Motor?
Normal hat so ein Arm Servomotore! Da ist nix mit PWM, jedenfalls nich so einfach. Lass mal ein paar mehr Infos rüberkommen. Axel
Moin, in Roboter-Spielzeug sind meist popelige Gleichstrommotore ohne Stellungsrückmeldung verbaut. Die Roboter für Ausbildungszwecke haben meist Schrittmotore. Die Geräte mit Servomotoren und Inkrementalgebern gehen dann schon in den professionellen Bereich. Da diese Teile schon sehr schnell werden können sollten Betrachtungen über Sicherheits- massnahmen, wie Einhausungen und hardwaremässige Geschwindigkeits- begrenzungen zum einteachen, vorgenommen werden. Bei einem ehemaligen Arbeitgeber sind einige Kollegen schon aus Roboterzellen herausgeboxt worden und haben anschliessend einige Zeit in der Horizotalen verbracht. Viel Erfolg Stefan
Es handelt sich um einfache Scheibenwischermotoren (24 V 4,9A) an denen wie gesagt jeweils ein Inkrementalgeber mit 500 Schritten pro Umdrehung ist. Es ist also schon möglich die mit PWM anzufahren, hab ich testweise auch schon gemacht. Da ich die Inkrementalgeber auch noch auswerten muss, müsste der controller mindestens 5 counter + 1 counter für pwm aben. Natürlich könnte man auch einen softwarezähler programmieren, aber ich denk das währ viel arbeit und wahrscheinlich auch weniger zuverlässig. Deshalb währ es vielleicht wirklich am besten für jeden motor einen kleinen controller (z.b. attiny 2313) zu benutzen. Ein counter für das pwm signal und einer zum auswerten des gebers. Über usart könnt man die dann mit einem Master verbinden. Was meint ihr dazu?
Ein Multi uC Konzept ist wahrscheinlich zu aufwändig. Nimm lieber eine etwas größeren uC mit genügend PWM Ausgängen. Wahrscheinlich kann man die Inkrementalgeber auch per Softwarecounter auswerten. Sind die 500 Schritte pro Umdrehung pro Robotergelenk oder irgendetwas anderes (Getriebe,...)? Falls du den Roboter "langsam" betreibst, dann ergeben sich auch relativ wenig "Schritte".
Hallo, ich würde die Motoren jeweils mit einem kleinen Prozessor ausrüsten, der selbstständig die Schrittgeber auswertet und die Geschwindigkeit regelt. Die Sollwerte können dann von einem weiteren Prozessor kommen, die Zusammenschaltung könnte man mit I2C-Bus machen. Ich baue gerade an solch einer Steuerung, allerdings für Schrittmotoren in einer schweren Teleskopmontierung. Der Hauptprozessor ist dort ein 32bit-ARM (LPC2148). Die 2-4 Slaves sind ATmega16. Der Master kommuniziert alle 50 millisekunden mit den Slaves, fragt Positionen und Endschalter ab und übermittelt neue Soll-Geschwindigkeiten. Gruß, Martin
> Oder währe es sinnvoll eine > Sterntopologie zu basteln mit jeweils einem Controller pro Motor? Das ist sinnvoll weil du dann einfach einen beliebigen Controller nehmen kannst, ein Problem einmal loesst und dann hinterher kopierst. > Es ist also schon möglich die mit PWM anzufahren, Das sollte in der Tat kein Problem sein. > Da ich die Inkrementalgeber auch noch auswerten muss, müsste > der controller mindestens 5 counter + 1 counter für pwm > aben. Das ist quatsch. Du braeuchtest nur einen Timer der dir einen periodischen IRQ generiert wo die Geber dann alle auf einmal eingelesen werden. > Natürlich könnte man auch einen softwarezähler programmieren, aber > ich denk das währ viel arbeit und wahrscheinlich auch weniger > zuverlässig. Liess dir bitte die diversen Diskussionen zum Thema Winkelencoder durch! > Deshalb währ es vielleicht wirklich am besten für jeden motor einen > kleinen controller (z.b. attiny 2313) zu benutzen. Ja, ich wuerde aber wenigstens einen Mega8 nehmen. Jedenfalls habe ich das vor ein paar Jahren mal mit mehreren Mega8 gemacht. Heutzutage wuerde ich aber auf JEDENFALL einen 16Bit Controller wie z.B R8Cxx verwenden. Wie dir ja sicher schon aufgefallen ist benoetigst du noch einen Regler fuer die Drehzahl und einen ueberlagerten Regler fuer die Position. Vielleicht sogar noch einen Regler fuer das Drehmoment. Dabei reicht eigentlich eine Aufloseung von 8Bit fuer die Ausgabe deiner PWM aus, aber zwischendrin in den Berechnungen benoetigst du 16Bit damit du keinen Ueberlauf hast. Ausserdem haben die AVR keine vernuenftigen einstellbaren IRQ Prioritaeten. Man bekommt es zwar hin, aber das ist unoetiger Stress den man sich heutzutage nicht mehr antun will. > Ein counter für das pwm signal und einer zum auswerten des gebers. Das geht nicht. Dein Motor wird keinen einfachen Inkrementalgeber nur fuer die Drehzahl haben. Waere das naemlich so dann koenntest du nicht die Drehrichtung bestimmen. Normalerweise haben die einen A/B Ausgang und dafuer will man keinesfalls einen Hardwarecounter verwenden. Olaf
>> Ja, ich wuerde aber wenigstens einen Mega8 nehmen. Jedenfalls habe ich das vor ein paar Jahren mal mit mehreren Mega8 gemacht. Heutzutage wuerde ich aber auf JEDENFALL einen 16Bit Controller wie z.B R8Cxx verwenden. Wie dir ja sicher schon aufgefallen ist benoetigst du noch einen Regler fuer die Drehzahl und einen ueberlagerten Regler fuer die Position. Vielleicht sogar noch einen Regler fuer das Drehmoment. Dabei reicht eigentlich eine Aufloseung von 8Bit fuer die Ausgabe deiner PWM aus, aber zwischendrin in den Berechnungen benoetigst du 16Bit damit du keinen Ueberlauf hast. Ausserdem haben die AVR keine vernuenftigen einstellbaren IRQ Prioritaeten. Man bekommt es zwar hin, aber das ist unoetiger Stress den man sich heutzutage nicht mehr antun will. << Ich denke, 16 bit sind nicht notwendig, um schnell genug zu regeln. In meiner Steuerung werden die Schrittmotoren 16000 mal pro Sekunde angesteuert, die Schritte werden mit 48 bit Genauigkeit gezählt und es ist noch fast die halbe Rechenzeit übrig. Encoder werden 64000 mal pro Sekunde ausgewertet. Das reicht nicht für schnelllaufende Motoren, aber dafür gibt es separate Chips zu kaufen, die Encoderauswertung in Hardware machen. Den 24bit-Zäherstand kann der AVR sich dann dort abholen. Die Drehzahlregelungen laufen wahrscheinlich mit 1-2 kHz, das sollte ein 8bit-AVR locker schaffen. Das Drehmoment könnte man extern regeln, indem man den Motorstrom vorgibt und den Sollwert einem Treiberbaustein übergibt. (Spulenstrom = Drehmoment) IRQ-Prioritäten braucht man nicht, denn der schnelle Interrupt für die Encoderauswertung und Motorsteuerung ist der einzige im System. Die Buskommunikation kann im Hauptprogramm gemacht werden (Polling-Betrieb). Gruß, Martin
Hier mal der link zum Inkrementalgeber: http://www.dunkermotoren.de/default.asp?id=16&sid=7&lang=1 Wie du schon richtig gesagt hast Olaf, haben die einen A und einen B ausgang die 90grad phasenversetzt sind. Die drehrichtung muss ich aber doch gar nicht auswerten, da ich die ja selbst vorgebe. Einde bewegung durch fremdeinwirkung ist unwahrscheinlich, da sich hinter dem Motor noch ein Getriebe mit hoher übersetzung befindet. Die genaue Übersetzung hab ich noch nicht rausgefunden, da ich absolut keine unterlagen zu dem Gerät hab. mfg Multikulti
Hallo, wenn du's nicht neu erfinden willst kannst du hier alles incl. Qellcode saugen. http://elm-chan.org/works/smc/report_e.html Ist genau das was du suchst. Dann kannst dir noch die Demo von mach3 saugen (geht als Demo bis 1000 Zeilen G-Code) und fertig. Gibt sogar ein teach-in Plugin für mach3. Gruss Gerhard
> Ich denke, 16 bit sind nicht notwendig, um schnell genug zu regeln. In > meiner Steuerung werden die Schrittmotoren 16000 mal pro Sekunde > angesteuert, die Schritte werden mit 48 bit Genauigkeit gezählt und es Wenn du Schrittmotore hast dann musst du nichts regeln, du steuerst dann. Ich habe schonmal in einem anderem Projekt drei Schrittmotore gleichzeitig an einem alten MCS51 betrieben. Ein Schrittmotor stellt wesentlich weniger Ansprueche da du ja im Prinzip nur die Rampen berechnen musst. Aber fuer einen Regler reichen 8bit nicht aus. Zum einen wuerdest du an manchen Stellen einen Ueberlauf bekommen, zum anderen musst du manchmal mit Kommazahlen rechnen, du musst also Festkommazahlen skalieren und shiften. Wie schon gesagt, man kann es hinbekommen. Ich hab soetwas laufen. Aber man kann sich auch eine Frikadelle ans Knie nageln. Ich wuerde empfehlen es nicht zutun. Zumal 16Bit Controller doch garnicht mehr kosten und hier wirklich mal ein paar Vorteile ausspielen. > Die drehrichtung muss ich aber > doch gar nicht auswerten, da ich die ja selbst vorgebe. Und was passiert wenn du mal gegen den Arm stoesst und den dabei bewegst? Das tust du nicht? :-) Dann ueberleg dir mal was passiert wenn dein Motor genau an seiner Sollposition angekommen ist. Dann wird dein Regler den Strom abschalten weil er ja da ist wo er hin soll. Dann wird sich aber dein Arm/Motor sicherlich ein Stueck in eine Richtung drehen. In welche Richtung? :-P Glaub mir, du musst die Drehrichtung wissen. Alles andere wuerde zu einem immer groesser werdenden Verlust an Genauigkeit fuehren. > Einde bewegung durch fremdeinwirkung ist unwahrscheinlich, da sich > hinter dem Motor noch ein Getriebe mit hoher übersetzung befindet. Das nuetzt nichts. Schon alleine deshalb nicht weil du Spiel im Getriebe hast. Nebenbei, das macht auch deine Regelung interessanter. Wenn du so genau positionierst das du dich jezt im Spiel befindest, also sich der Ausgang des Getriebes nicht mehr bewegt, wohl aber der Eingang, dann aendern sich naemlich die Parameter deiner Regelstrecke erheblich. > wenn du's nicht neu erfinden willst kannst du hier alles > incl. Qellcode saugen. Wuerd ich nicht tun, man kann an so einem Projekt eine Menge lernen! Ich empfehle Artikel 2 und ganz besonders 3: http://www.wescottdesign.com/articles.html Olaf
Bin ja mal gespannt, wie Du die Rampen programmierst und die Trajektorie und Kinematik umsetzt. Halte uns bitte auf dem Laufenden (auch mit deinem Code!).
Ich hab bei mir nen Gleichstrommotor an nem Mega16 hängen. Der angeflanschte Encoder liefert 500 Schritte/U. Die Schritte werden mit nem 16Bit Software-Zähler gezählt. Der Mega schafft ne PID Regelung für die Drehzahl (1- 6000 U/Minute) + ner überlagerten Positionsregelung mit Rampen (32 Bit Schritte). (Wird mal mein Jahrhundert-Projekt CNC-Fräse ;-) ) Der PID Regler rechnet mit 32Bit Werten, und trotzdem ist da noch ne Menge luft für die Kommunikation mit dem Master zwecks den Soll und Istwerten für die Achse.... (das ganze nichtmal in ASM sondern in C geschrieben) Also je Achse ein 8Bitter AVR reicht da völlig aus. Alles andere wäre mit Kanonen auf Spatzen schießen
Matthias Becher schrieb: > PID Regelung für die Drehzahl (1- 6000 U/Minute) > + ner überlagerten Positionsregelung mit Rampen (32 Bit Schritte). Da ich bis jetzt lineare Rampen genommen habe und einfach auf maximale Beschleunigung verzichtet habe, würde mich mal interessieren wie du das gelöst hast. Es gibt da ja tolle Sachen, wie Sinusähnliche Rampen etc. Aber bringts das?
Hallo Matthias, >>Ich hab bei mir nen Gleichstrommotor an nem Mega16 hängen. Der >>angeflanschte Encoder liefert 500 Schritte/U. >>Die Schritte werden mit nem 16Bit Software-Zähler gezählt. Der Mega >>schafft ne PID Regelung für die Drehzahl (1- 6000 U/Minute) 6000 U/min * 500 Schritte/U, das sind theoretisch bis zu 50000 Schritte pro Sekunde ? Oder sind es 50000 Signalwechsel, was 12500 volle Encoderzyklen bedeutet ? Wenn es 50000 volle Zyklen und damit 200000 Signalwechsel sind, würde mich die Auswertung in Software interessieren. Dann wären ja mehr als 200000 (IRQ-)Aufrufe pro Sekunde für die Auswertung nötig. Gruß, Martin
@ Alexander: Die Rampen sind nur für das genaue und schwingungsfreie Anfahren der Position gedacht. Sie funktioniern einfach nach dem Prinzip, daß bis 100 Pulse vor der Position mit 100 % Geschwindigkeit gefahren wird, und diese dann rein rechnerisch um 1% je Puls verringert wird. @ Martin: es sind dann natürlich 12500 komplette Encoderzyklen/s. Die Pulse werden übrigens mit 32 Bit Softwarezähler gezählt. War spät gestern abend. Hab das Programmchen mal angehängt. An dem Motor ist noch ein Getrieben 5,irgendwas : 1 angeflanscht. Darum ist die Maximaldrehzahl mit 1394 angegeben und es ist von 2765 Pulsen / U die Rede
Und falls sich's wer nachbasteln will noch die eagle dateien (.sch + .brd)
Die Sollwerte bekommt das Modul momentan per JTAG verabreicht. Später sollen diese per SPI vom Master-Controller kommen. Ist aber noch nicht eingebunden. Als Sollwerte braucht es nur die Position in 1000stel mm und die Drehzahl der Spindel in U/m
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.