Einfachen Servomotor aus DC-Getriebemotor umbauen?

Vorerst: es geht erstmal darum, ob, wie und wie gut das überhaupt machbar ist.
Angenommen, man nehme einen Getriebemotor wie diesen, setzt an den kurzen Stutzen der Motorwelle, der hinten noch herausragt, eine geteilte Scheibe an und da drum herum zwei Gabellichtschranken bzw. etwas derartiges aus Flach-Led und Fototransistor. Anordnung wäre damit wie folgt:
Anhang 20399
Das schwarze Teil soll dann die graublauen Lichtschranken auslösen. Zwei Lichtschranken deshalb, damit man die Drehrichtung erkennen kann. Zum Ansteuern müsste man dann allerdings 4 Pins opfern: einmal PWM für den Motor, einmal Richtung und zweimal Rückführung von den Lichtschranken.
Frage ist nun, ob es dafür praktische IC's gibt, die die Auswertung der Signale von den Lichtschranken erleichtern. Würde man die Signale direkt einlesen (vll. noch mit Schmidt-Trigger, damit der Pegel auch bei hohen Drehzahlen gehalten wird), müsste man aufwändig programmieren, um die ordentlich verwenden zu können. Würde eigentlich auf eine Flankenerkennung der einen Schranke, während die andere Schranke schon high ist, hinauslaufen, wenn ich mich nicht irre. Je nachdem, bei welcher Schranke das auslöst, müsste dann eine Variable rauf oder herab zählen. Obendrein bräuchte man auch noch eine Zeitmessung zwischendurch, um die Geschwindigkeit festzustellen. Würde es sich dabei lohnen, quasi einen ATtiny für einen einzelnen Servomotor abzustellen, der das Ganze erledigt und nur noch mit Befehlen gefüttert werden muss? Irgendwie hab ich da gerade nicht so die guten Ideen, wie man das alles geschickt miteinander verbinden könnte. Letztens hatte ich hier noch einen Thread gefunden, wo einer ein Servo zu einem Servomotor umgebaut hatte, find den allerdings nicht mehr wieder...
Hat das sonst schonmal jemand gemacht? Irgendwelche Erfahrungen?

edit: Thread wiedergefunden

Zitat:

---

Zitat von Geistesblitz

... Signale direkt einlesen (vll. noch mit Schmidt-Trigger ...) ... aufwändig programmieren ...

---

Den Aufwand mit Schmidt-Trigger und aufwändiger Programmierung habe ich nicht. Ich habe meine Gabellichtschranke, bisher nur je ein GP1S096HCZ - nur Drehzahl, so angeschlossen:

......Bild hier  


RV 330R - dabei ist die LED mit 5V Versorgung hell genug für ein gutes Signal vom Fototransistor. Fototransistor mit RL 10k - Sicherheit gegen spikes, Signal schaltet sicher zwischen über 4V und 0,2V - bei 5V Versorgung. Die Signale sind bei mir auf nem mega168/328-20MHz-INT0/1 bis > 100 kHz (4 Schlitze, > 700 Ups) sicher zu erkennen.

Kennst Du eigentlich diese site (klilck) ? Ich finde, open servo ist für Dein Thema sehr interessant.

Hallo,
falls deine Anordnung der Lichtschranken tatsächlich so vorgesehen ist wie im Schema dargestellt, wirst du damit Probleme bekommen.
Der Abstand zwischen den Sensoren muß viel geringer sein, als die Breite eines Flügelsegmentes. Sonst spielen tatsächlich geringe Impulsverzögerungen bei hohen Drehzahlen eine Rolle. Ich würde den Abstand von 1/4 auf 1/8 des Umfanges reduzieren.
Gruß
Bernd

Der Abstand der Sensoren sollte gerade halb so groß sein, oder die Scheibe am Motor nur halb so viele Segmente haben.

Einige µC haben bereits Schmidttrigger an den normalen Digitalen Eingängen - da braucht man nicht unbedingt externe.

Zitat:

---

Zitat von simi7

... Anordnung der Lichtschranken ... spielen ... Impulsverzögerungen bei hohen Drehzahlen eine Rolle ...

---

Ja, ein wichtiger Hinweis. Bei meinen Lichtschranken ist rise/fall time Standartwert aus Datenblatt ca. 50 µs - das reicht für meine Anwendung ohne Drehzahlerkennung (grad noch), weils bei mir doch etwas schneller geht. Zum Glück sind die INT0/~1 so hoch priorisiert, dass meine vielen Interruptroutinen, insgesamt ca. 5% CPU-Zeit, bei der Zeitmessung für die Drehzahl nicht so sehr stören können. Mit solchen Werten kann man aber auch halbwegs vernünftig abschätzen, obs und wie lange (bis in welche Drehzahlen) es funktioniert.

Hier lohnt sich ein Oskar, um "im System" die Dynamik der Ausrüstung zu testen:

Anhang 20401
2V+1ms/div, ca. 300 Ups

Siehe auch hier.

Ok, die Open-Servo-Seite werde ich mir mal noch näher anschauen, danke. Gehts da eigentlich nur um Servos oder auch Servomotoren?
Bei der Suche nach Gabellichtschranken bin ich auf diese hier gestoßen, in den Daten steht bei Anstiegs und Abfallzeit jeweils 10000ns, hieße das also, dass bei Frequenzen von über 50kHz das Signal nicht mehr sauber genug ist oder sogar schon vorher? Worauf muss man dabei sonst achten?
Die GLS näher beieinander zu legen bringt wirklich mehr? Kann ich mir gerade irgendwie nicht so recht vorstellen, woran das liegt...kann mir das jemand nochmal erklären?
Ich glaub, am besten wäre es, sich mal ein paar Komponenten zuzulegen und damit zu experimentieren. Probieren geht hat immernoch über studieren.

Die Lichtschranken müssen so angeordnet sein, das wenn die eine in der Mitte eines Segmentes ist, die andere gerade eine Kante sieht. Das kann man erreichen wenn die Lichtschranken weiter zusammen sind, oder auch etwas weiter auseinander.

Nur so wie gezeichnet sehen beide etwa gleichzeitig eine Kante - die 2. Lichtschranke liefert etwa das invertierte Signal der ersten und damit fast keine zusätzliche Information.

Ah, alles klar, jetzt seh ich es auch. Ok, dann stehen die halt nurnoch im 45°-Winkel.

Zitat:

---

Zitat von Geistesblitz

... Die GLS näher beieinander ... bringt ... mehr? Kann ich mir ... nicht so recht vorstellen ...

---

Lies Dir mal das hier (klick) zu Drehgebern durch, achte auf den Abschnitt "Zwei Lichtschranken liefern vier Informationen". Hilfreich ist für Dich sicher noch noch dies (klick) zu einem einschrittigen Code (Graycode). Da gibts ein bisschen Hintergrundwissen darüber, warum nicht beide Lichtschranken gleichzeitig an einer Kante sein sollen (klick hier), welche Probleme dabei auftreten können und wie/womit die zu beheben sind.

Jo, vielen Dank für die Links. Besonders der erste scheint sehr brauchbar zu sein, wieso hab ich den nicht schon gefunden, als ich mich im RN-Wissen umgesehen hab?
Der Gray-Code an sich ist aber auch nur von Bedeutung, wenn man Absolutdrehgeber nimmt. An sich eine feine Sache, allerdings sehr aufwändig zu machen/teuer zu kaufen.

Zitat:

---

Zitat von Geistesblitz

... Gray-Code ... nur von Bedeutung, wenn man Absolutdrehgeber nimmt ...

---

Jein. Denn die Theorie zum einschrittigen Code ist der Hintergrund für die Bedenken zur Postionierung Deiner Sensoren, die simi7 eingebracht hatte.

Hallo!

@ Geistesblitz

Ich wollte nur auf das aufmerksam machen, dass beim Servo eine absolute "ist" Position bekannt seien muss. Deshalb ohne Drehscheibe mit Greycode bzw. Potentiometer für benutzten Bereich kompliziert sich die ganze Steuerung. ;)

Kommt darauf an, wie die Getriebeuntersetzung und wie hoch die geforderte Ganuigkeit ist.
Mit einer hohen Untersetzung kann ein einflügeliger Geber am Motor ausreichend sein.
Man kann natürlich auch ein Zahnrad im Getriebe, das eh schon Löcher oder Speichen hat, als Unterbrecher für die Lichtschranken nehmen. Das bleibt dem Konstrukteur überlassen. Bei Druckern wird als Positionsgeber z.B. eine durchsichtige Folienscheibe mit dünnen aufgedruckten Strichen am Umfang verwendet. Soetwas könnte man auch fotografisch mit herkömmlichem Film selbst herstellen. Die passenden Sensoren dazu haben eine Maske im Lichtweg, die ebenfalls strichförmig ist. Wegen der dann geringen Lichtmenge stellt das natürlich gesteigerte Anforderungen an die Sensoren.

@Picture: Was willst du mir sagen? Hier geht es nicht um Servos, sondern um Servomotoren. Im Eingangspost wurde ein Getriebemotor und ein Konzept für einen einfachen Inkrementaldrehgeber erwähnt. Durch die hohe Übersetzung sollte am Abtrieb eine recht gute Genauigkeit vorliegen und obendrein ein sehr brauchbares Moment (wenn man dem Anbieter glauben darf ganze 0,9 Nm). Je nach Bdarf gäbe es dort ja auch noch andere Abstufungen für die Übersetzung. Schade, dass dort kein Übersetzungsverhältnis angegeben wurde, sondern nur die typische Abtriebsdrehzahl, wobei man dadurch aber schonmal in etwa die Größenordnung abschätzen könnte. Dass das Getriebe ein gewisses Spiel hat, bleibt wohl nicht auszuschließen, aber für einfache Anwendungen könnte das trotzdem brauchbare Ergebnisse liefern. Ich glaub, ich hol mir da einfach mal welche und untersuch die mal.

Andere Sache: ich hab in meiner Kiste noch die Elektronik von einer alten Maus gefunden, hieße also 2 Schlitzscheiben und 3 Optokoppler, wobei da die Led und die Fototransistoren extra sind. Die Encoderscheibe vom Mausrad scheint irgendwie verschollen zu sein. Die Transistoren haben sogar 3 Anschlüsse, deswegen gehe ich mal davon aus, dass die direkt schon gepaart vorliegen, wahrscheinlich sogar schon im idealen Abstand zu den zugehörigen Encoderscheiben. Weiß einer, wie bei den Dingern üblicherweise die Anschlussbelegungen sind?

Hallo!

Zitat:

---

Zitat von Geistesblitz

@Picture: Was willst du mir sagen? Hier geht es nicht um Servos, sondern um Servomotoren.

---

Sorry, dann habe es falsch interpretiert, weil ich keine Besonderheiten bei Servomotoren sehe. ;)

So, ich hab mich weiter belesen und noch ein wenig nachgedacht. Ich würde es wohl so realisieren, dass auf dem µC ein Timer und ein Counter laufen. Der Counter zählt die Inkremente, wobei durch Abfrage der zweiten GLS bestimmt wird, ob rauf oder runter gezählt wird. Die Zählvariable ist erstmal nur temporär und unabhängig von der Positionsvariable. Der Timer löst dann in gröberen Abständen aus, zB. alle 10ms, wobei dann die temporäre Zählvariable als aktuelle Geschwindigkeit gespeichert und auf die Position aufaddiert wird. Die Position sollte man wohl wirklich schon als Long wählen, während bei der Geschwindigkeit Integer reichen dürfte (gibts in Bascom eigentlich auch Short?). Wenn man schon dabei ist, wird dann auch gleich die Regelung in den kleinen µC integriert. Ich würde da wohl einen PI-Regler nehmen, um gute Positioniergenauigkeit zu erhalten. Für den Entwurf ließe sich wohl ein einfaches PT1-System heranziehen, das aus Zeitkonstante und Verstärkungsfaktor identifiziert wird. Bei hoch übersetzenden Getriebe soll ja meist die Motordynamik am einflussreichsten auf die Regelung sein. Sollwerte hatte ich vor, über UART zu übertragen, ist das sinnvoll? Wie wird bei sowas das Protokoll am besten aufgebaut?

Nun ist die Frage: welcher ATtiny hat einen Counter, einen Timer, einen PWM-Ausgang und UART?

Außerdem ist mir aufgefallen, dass die Teilung der Encoderscheibe aus der Maus wohl eine zu feine Teilung hat. Wenn man dann versuchen würde, eine Position anzufahren, die pratisch zwischen zwei Motorphasen liegt, würde das Teil nur die ganze Zeit herumzuppeln. Wäre es da dann praktischer, bei 3 Motorphasen auch nur 3 oder 6 Segmente auf die Scheibe zu setzen?

Zitat:

---

Zitat von Geistesblitz

Die Transistoren haben sogar 3 Anschlüsse, deswegen gehe ich mal davon aus, dass die direkt schon gepaart vorliegen, wahrscheinlich sogar schon im idealen Abstand zu den zugehörigen Encoderscheiben. Weiß einer, wie bei den Dingern üblicherweise die Anschlussbelegungen sind

---

Ich habe eine uralte RS232-Maus auseinandergenommen. Encoderscheibe hatte nur 20 Schlitze und die Fototransistoren mit drei Beinen passen natürlich ideal dazu. Müssen natürlich möglichst gleich wie in der Maus montiert werden.

Die Schaltung entsprach bis auf geringe Abweichung in der Dimensionierung der Bauteile dem Application Circuit aus dem Datenblatt zu dem HT6513 , Seite 8. Gemeinsamer Kollektoranschluß der beiden Fototransistoren in der Mitte - die beiden Emitter außen.

EDIT: IR-LED jeweils nur eine für einen Doppelfototransistor.

Um die Rechenarbeit im µC zur Auswertung der Signale zu reduzieren, hatte ich mal an eine HW-Erweiterung gedacht aber noch nicht die Muße gehabt, da etwas auszuprobieren. Wenn Du es noch nicht kennst (Manf hat dazu einen interessanten Link gepostet)

https://www.roboternetz.de/community...l=1#post528662

Gruß
Searcher

Hab die Lichtschrankenelemente gerade erfolgreich getestet. Um ein brauchbares Signal zu erhalten, musste ich hinter den Fototransistoren noch jeweils einen Transistor schalten. Hab mir eine Schablone mit 1mm Schlitz gebastelt und dicht vor der Lichtschranke entlang bewegt, die Transistoren haben einfache Leds geschaltet. Signal ist genauso, wie erwartet. Leider ist eine kleine IR-Led beim Ausbau kaputt gegangen :(

Beim Kramen hab ich noch eine optische Maus gefunden. An sich nicht so interessant, nur das Mausrad hatte einen interessanten Sensor: sieht ein bisschen aus wie ein Poti, nur mit einem durchgehenden Innensechskant. Lässt sich unbegrenzt drehen, hat drei Anschlüsse und eine Einrastmechanik, die alle 15° einrastet. Was ist das, wie steuert man es an und was kann man damit anfangen?

Das ist ein Inkrementalgeber (normalerweise mechanischer Kontakt). Ich habe gerade vor mir eine zerlegte Maus liegen, der Mausradsensor hat auch 3 Anschlüsse. Habe auf Mikrocontroller.net etwas gefunden http://www.mikrocontroller.net/topic/145257

MfG Hannes

Ich hab in demselben Ebay-Shop jetzt diesen Getriebemotor gefunden, aus dem vier Kabel kommen, zwei Stromversorgung und "Gelbe und blaue Kabel: Monitoring Prüfgeschwindigkeit Kabel.(Sie können sie ignorieren. Einige Kunden benötigen diese Funktion)". Wozu ist das bzw. was kommt da für ein Signal raus? Ließe sich das für eine Regelung verwenden? Irgendwie bin ich da nicht sonderlich optimistisch und wollte nur aus Neugier nachfragen, was das ist.
Ansonsten mal gucken, wann meine Bestellung ankommt, dann kann ich auch endlich mal ein wenig testen. Ich werd wohl erstmal den Inkrementalgeber anbringen und dann mal gucken, ob ich da irgendwie brauchbare Werte herausbekomm, um das dynamische Verhalten des Motors identifizieren zu können, also Zeitkonstante und Verstärkungsfaktor. Dürfte ja etwa PT1-Verhalten aufweisen, da ist dieser Teil ja nicht so besonders schwer. Für die anderen Reglerparameter werd ich dann wohl noch Matlab bemühen. Da ich ja eh eine digitale Regelung verwenden werd, könnte ich auch versuchen, einen Deadbeatregler zu entwerfen.

So, hab jetzt an einen DC-Motor eine Encoderscheibe mit IR-Diode und Fotoransistor angebracht und es funktioniert bisher scheinbar ganz gut. Nun muss ich nurnoch den Ausgangspegel etwas anpassen, damit auch klare High-Low-Signale erkannt werden können, und dann kann eigentlich schon die Programmierung losgehen. Nagut erstmal muss ich noch endlich mein µC-Board zusammenlöten, aber das sollte eigentlich weniger das Problem sein.

Ich habe heute mal die Möglichkeit getestet, über das Pololu Mini Maestro Board über den TTL-Port mit der UART des ATmega zu kommunizieren. Lief erst auch gut und ich konnte die Position auf meinem Bildschirm visualisieren. Nachdem ich dann ein Kabel gebastelt hatte, um das Pololu-Board und mein Controller-Board besser miteinander verbinden zu können, und dieses anschloss, funktionierte die Kommunikation nicht mehr. Auch mit den Kabeln, die ich vorher verwendet hatte, geht es nicht mehr. Zwischendurch hatte ich auch diesen typischen Geruch vernommen, der nichts Gutes verheißt. Ich befürchte, dass das Pololu-Board etwas abbekommen hat :(
Zu sehen ist nichts, aber das muss ja nichts heißen. Kann man denn so viel falsch machen, wenn man da die Kabel falsch anschließt?

Wenn man einen Kurzschluss verursacht kann es schon sein. Ich würde alles abschließen was möglich ist und jeden Teil (sofern möglich) einzeln testen. Was hast du genau für ein Pololu Board? Könntest du einen Link posten?

MfG Hannes

Ich hab dieses Board:
http://www.watterott.com/de/Mini-Mae...ller-Assembled

An sich funktioniert es noch, eigentlich hatte ich auch drauf geachtet, die Kabel richtig anzuschließen. Hab dem Händler auch schon eine Mail geschrieben, schließlich bieten sie Support an. Mal sehen, wann die antworten.

Funktioniert der Atmega auch noch? Hat der Atmega noch einen Pegelwandler (TTL-Pegel auf normale RS232 Pegel)?

MfG Hannes

Ich hatte den ATmega schon ausgewechselt und es hat nichts gebracht, an dem liegt es also nicht. Pegelwandler brauch ich nicht, da das Pololu-Board ja schon mit TTL-Pegel arbeitet. RS232 hab ich hier auch gar nicht zur Verfügung, außerdem hatte es ja schon funktioniert. Hab gerade nochmal ausprobiert, es kommen kommen keine Befehle an und es können auch keine gesendet werden. Irgendwo versickern die unterwegs, im Prinzip kann es nur am Pololu-Board liegen :(
Ganz schön ungünstig...

Wegen den Pegeln habe ich nur sicherheitshalber nachgefragt. Das wäre sehr ungünstig gewesen. Über USB kannst du das Board ansteuern? Geht das Signal vom USB und vom UART Signal auf den gleichen Eingang des µC (beim Pololu Board)?

MfG Hannes

Da versteh ich jetzt nicht, was du meinst. Das pololu Board hat eine Mini-USB-Buchse, die an den PC angeschlossen wird. Darüber lässt sich dann der TTL-Port des Pololu Boards als virtueller COM-Port verwenden. Ich hab halt den Rx-Pin des Boards mit dem Tx-Pin des µC verbunden und den Tx mit dem Rx.

Komischerweise funktioniert es jetzt wieder... keine Ahnung, was das Problem ist...

Edit: Nachdem sich das Board sich jetzt ja wieder eingekriegt hat habe ich mal versucht, ein paar Verläufe vom Motor aufzunehmen.
Anhang 20546
Im Diagramm steht die weiße Linie für den Winkel, die rote Linie für die Winkelgeschwindigkeit und die grüne Linie für die Winkelbeschleunigung. Anscheinend ruckelt die Drehzahl ein wenig, mal sehen, was sich daran machen lässt. Man sieht aber schonmal, dass der Motor ziemlich fix hochbeschleunigt. Was ich beim Regler wohl noch Bedenken muss: der Motor läuft erst ab einer Spannung von 1,5 bis 2V an, das müsste ich dann wohl noch irgendwie abfangen.
Hier noch ein paar Bilder vom hingefrickelten Encoder :D
Anhang 20545Anhang 20544

Schön wenn es jetzt funktioniert.
Es gibt 2 Möglichkeiten wie das UART Signal bzw USB Signal an den µC des Pololu Boards angeschlossen ist.
Hier sind Skizzen wie ich es meine:

Code:

---

entweder:
USB---USB/UART Wandler (z.B. FT232)---Pin des Pololu µC
UART--------------------------------|

oder:
USB--- USB/UART Wandler---Pin des Pololu µC
UART----------------------anderer Pin des Pololu µC

---

Die Skizze ist aber nur zur Erklärung. Wenn es nicht funktioniert hätte, hätte ich es über den USB Port versucht, wenn es auf den gleichen Pin des Pololu µC geht. So kannst du ausschließen dass das Programm am Atmega oder die Verbindung fehlerhaft ist oder nicht.

Aber das brauchst du jetzt ja nicht mehr (zumindest vorerst).

MfG Hannes

So, wenn ich jetzt in die Routine den PWM-Ausgang setze, dann verzählt sich dar µC komischerweise ständig, besonders, wenn ich nur lagsam drehe. Wenn ich das weglasse, zählt er wieder jeden Schritt genau. Hier der Code, den ich bisher zum Testen geschrieben hab:

Code:

---

regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 16000000
$baud = 9600

Declare Sub Serial0charmatch()

Config Serialin = Buffered , Size = 30 , Bytematch = 13
Config Porta = Output
Config Pinc.0 = Input
Config Portc.1 = Output
Config Portb.3 = Output
Config Timer1 = Counter , Edge = Rising
Config Timer0 = Pwm , Compare Pwm = Clear Down , Prescale = 8
On Timer1 Count
Enable Timer1
Enable Interrupts

Dim T As Long
Dim Preset As Byte

T = 0
Preset = 1

Waitms 500

Load Timer1 , Preset

Do
!nop
Loop

Count:
  Load Timer1 , Preset
  If Pinc.0 = 1 Then
    T = T + 1
  Else
    T = T - 1
  End If
Return

Sub Serial0charmatch()
  Local Incoming_data As String * 30
  Local Soll As Long
  Local E As Long
  Input Incoming_data Noecho
  Print T
  Soll = Val(incoming_data)
  E = Soll - T
  E = 10 * E
  'Compare0 = 127 - E                <---hier ist der kritische Term, auskommentiert bereitet er Probleme
End Sub

---

Kann es sein, dass dadurch die Sub zu lange dauert und daher das Programm blockiert? Ich weiß irgendwie nicht, woran das liegen kann...

Hallo,
ich kann nicht entdecken, wo die Sub Serial0charmatch(), in der der kritische Term steht, aufgerufen wird.

EDIT: Hab grad entdeckt, was die Sub macht.#-o

Zitat:

---

Kann es sein, dass dadurch die Sub zu lange dauert und daher das Programm blockiert?

---

Würd ich jetzt auch vermuten.

Vielleicht gibt es Probleme mit dem $hwstack. 32 ist wohl das absolute Minimum wenn Interrupts laufen:
http://halvar.at/elektronik/kleiner_...swstack_frame/

Gruß
Searcher

Hab jetzt die Ursache gefunden: das PWM-Signal für den Motor stört den Inkrementalgeber, selbst wenn der Strom für den Motor abgestellt wird. Wenn ich das Kabel vom Pololu-Board entfern (darüber läuft gerade die PWM) wird wieder richtig gezählt. Anscheinend muss ich dort die Schaltung noch etwas entstören, allerdings weiß ich nicht, wie. An den Bauteilen, wo die PWM anliegt, Kondensatoren parallel zum Gnd-Anschluss legen?

Edit: nun klappt es so halbwegs. Musste noch die Versorgungsleitungen vom Steckbrett und dem Pololu-board miteinander verbinden. Dachte, das wäre über die TTL-Schnittstelle, wo ich auch schon +5V und Gnd angeschlossen hatte, geklärt, aber nun läuft es.

Der Regler läuft, ist erstmal nur ein einfacher Proportionalregler, allerdings musste ich einen kleinen Versatz einbauen wegen der Anlaufspannung am Motor. Dadurch flattert die Welle relativ fix um die Nulllage. Außerdem passiert es hin und wieder, dass er sich verzählt und die Nulllage verschiebt sich. Mal gucken, was sich dagegen machen lässt.

So, jetzt gibts von mir auch mal ein kleines Video.
Zuerst spiel ich nur ein wenig mit der Sollwertvorgabe herum, nicht wundern, dann lenk ich die Antriebswelle ein wenig von Hand aus und im Anschluss ist nochmal die Bedienoberfläche, die ich in Labview erstellt habe, mehr schlecht als recht zu sehen. Ich verstell da auch wieder ein wenig die Sollwertvorgabe, sodass man gemessene Position (weiß) und Geschwindigkeit (rot) in dem Panel sehen kann.

http://www.youtube.com/watch?v=OKjAIZY8F0A

Bekomm das Video leider igendwie nicht eingebettet...

Gratuliere!

Bin selbst an etwas ähnlichem: Quadratursignal vom Mausencoder mit ATtiny24 auswerten und kämpfe gerade damit, ob meine gemessenen Werte bei Vorwärts- und Rückwärtslauf mit den tatsächlichen übereinstimmen. Wie hast Du das gemacht?

Gruß
Searcher

Ich hab jetzt die einfache Version gemacht: wenn die eine GLS einen High-Impuls bekommt, wird die andere GLS abgefragt und je nachdem die Istposition um einen hinauf oder herunter gesetzt. Die Methode 2 Signale=4 Informationen nutze ich bewusst nicht, da ich vermute, dass die Rechtecksignale nicht genau um 90° versetzt sind. Auflösung ist jetzt schon gut genug. Über die UART schickt LabView in regelmäßigen zeitlichen Abständen die Sollposition und erhält als Antwort die Istposition zurück. Die PWM wird dann durch Labview mit einem Soll-Istwert-Vergleich berechnet und über das Pololuboard eingestellt. Zukünftig soll das dann alles auf dem ATmega implementiert werden, zum Testen macht sich LabView aber besser.

Ah, danke, muß ich mir auch nochmal durch den Kopf gehen lassen.

Ich benutze aus dem RN-Wissen diese Methode: http://www.rn-wissen.de/index.php/Dr...ENCODER-Befehl

Die beiden Signale von dem Doppelfototransistor sind auf je einen Pin des gleichen Ports gelegt, maskiert für den gleichen Pin Change Interrupt und in der ISR läuft dann o.g. Programm.

Bei mir sind die Signale auch nicht 90 Grad versetzt, müssen sie auch nicht. Allerdings wird die Zeit für die Auswertung knapper. Ich habe gerade im worst case 40µs Zeit (Oszi) und das sind noch langsam laufende Motore mit wenig Schlitzen in der Encoderscheibe.

Gruß und weiterhin Erfolg
Searcher

Irgendwie kommt mir der Code komisch vor. Einige Syntax ist mir auch neu, vielleicht liegt es daran. Ich finds nur komisch, dass der Sensor nur jede ms abgefragt wird, hieße das, bei 1kHz wäre schon Schluss oder wie? Ich kann mir gut vorstellen, dass bei höheren Geschwindigkeiten gerne mal Schritte verschluckt werden könnten. Der Counter löst ja wirklich immer dann aus, wenn ein Schritt getätigt wird. Alternativ habe ich ach schon von der Methode gelesen, diese Auswertung in der Hauptschleife laufen zu lassen, sodass wirklich ständig abgefragt wird, und alles andere über Interrupts laufen lassen. Dann könnte höchstens ein Schritt verloren gehen, während gerade ein Interrupt ausgeführt wird, allerdings glaube ich, dass das schnell genug läuft. Vorteil ist natürlich, dass man keinen weiteren Timer dafür verbraucht, und wenn ich das auf nem ATtiny umsetzen will, muss ich da schon drauf achten.

Apropos ATtiny: die meisten von den Teilen lassen sich ja gerade mal über SPI ansprechen, allerdings habe ich damit noch keine Erfahrungen gemacht. Ist das ähnlich einfach wie UART oder muss man da mehr Arbeit reininvestieren?
Außerdem soll bei denen der HW-Multiplikator fehlen, wie führt man dann Multiplikationen aus? Geht das so wie sonst auch, nur, dass der Chip halt langsamer arbeitet, oder muss man da auch extra eine Funktion für schreiben?

Ich hab den Code aus RN_wissen schon ein wenig angepaßt. Die ISR wird bei mir nicht in festen Abständen angesprungen, sondern nur wenn ein PCINT auftritt. Wenn das vorzeigbar ist und ich entsprechende Kommentare eingefügt habe, werd ich ihn mal in meinem Blog zeigen.

Der ATtiny24 hat 2 Ports. PortA und PortB. Alle Pins eines Ports können einen zugehörigen Pin Change Interrupt auslösen. Also PinA.x kann PCINT0 und PinB.x PCINT1 auslösen. Im Maskenregister wird bestimmt, welche Pins tatsächlich scharf sind.

Ich beschränke mich nur auf PortA. Das klappt schon mit gewissen Einschränkungen. Wenn das ausgetestet ist kommt ein zweiter Encoder an PortB.

Der PCINT wird bei fallender und bei steigender Flanke ausgelöst. Die beiden Signale vom Doppelfototransistor lösen also in einer Periode vier Interrupts aus. Jedesmal werden also die Statusse (Stati ??) des Quadratursignals ausgewertet.

Ich erhalte damit Werte, die der doppelten Schlitzfrequenz entspricht, da der Algorithmus bei gültigen Übergängen immer Eins addiert, wenn beide Pins low und beide Pins high sind.

Bisherige Tests sind recht plausiebel. Da ich aber noch in Versuchen stecke, alles mit etwas Vorsicht genießen.

Ich denke gerade darüber nach, einen zweiten Tiny einzusetzen, nur um den Motor zu steuern und mit zusätzlicher Lichtschranke die Quadraturauswertung zu überprüfen.

Zur Anzeige benutze ich SW-UART mit 115000 Baud. Weil es aber trotzdem Timingprobleme gibt, speichere ich jede Sekunde die Werte ab (zB 4 Meßwerte) und lasse sie danach jede Sekunde ausgeben (ohne daß eine Messung läuft)

Der Tiny könnte auch SPI was wesentlich schneller wäre als UART. TWI hat er auch. SW-SPI hab ich schon testweise ausprobiert - gut und einfach.

Im Algorithmus wird mit 4 multipliziert. Das habe ich mit zweimal SHIFT LEFT ersetzt.

EDIT Multiplikation geht natürlich auch ohne HW Unterstützung. einfach x * y in Bascom schreiben - ist langsamer als shift.

Gruß
Searcher

So, ich hab jetzt ein wenig weitergemacht. Ich habe eine Vorsteuerung eingebaut, die aus den ersten beiden Ableitungen der Sollposition die benötigte Motorspannung errechnet. Dadurch bewegt sich der Motor im unbelasteten Zustand schon einigermaßen dem Sollpositionsverlauf entsprechend. Dort hab ich dann eine einfache Proportionalregelung gelegt, um die Abweichungen auszuregeln, und das Verhalten gefällt mir bisher schon ziemlich gut. Wesentlich glatter, als die reine Regelung. Allerdings mag er die Ableitungen von der Schiebeleiste nicht so recht, da das doch sehr verruckelt ausfällt. Müsste ich wohl noch ein wenig filtern, damit ein halbwegs glatter Verlauf entsteht.

So, hab mir mal paar von den im Eingangspost erwähnten Getriebemotoren geholt und bin erwartungsgemäß vom Getriebespiel enttäuscht :/
Vom Händler hab ich die Info, dass das Getriebe eine Untersetzung von 1:140 hat, also mal an der Motorwelle gedreht, bis sich der Abtrieb rührt, und ich konnte eine ganze Runde herumdrehen :(
Demnach müsste das Umkehrspiel bei 2,5° liegen, was wirklich beträchtlich ist. Nun bin ich am überlegen, ob es sinnvoller ist, andere Getriebemotoren mit weniger Spiel zu suchen (wo sollte ich da am Besten gucken?) oder als Rückführung nach Art des Servos ein Potentiometer an das tatsächliche Gelenk zu setzen und dessen Wert am Analogeingang zu erfassen. Allerdings wird die Auflösung vom normalen Analogeingang auch nicht so besonders toll sein (10 bit). 1024 Schritte über den gesamten Stellbereich empfinde ich irgendwie immernoch als ein wenig grob, wobei es auch schwierig sein dürfte, auf andere Art und Weise etwas besseres bei vergleichbarem Budget zu realisieren. Außerdem kommt es auch noch darauf an, wie gut die Linearität des Potis ist. Was meint ihr, welche Variante wäre da vielversprechender?