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?
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
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
