Druckbare Version
Vielleicht doch nicht ganz so dumm.
Bisher haben wir die Wegbestimmung über Reflexkoppler (CNY70,...) und Gabellichtschranke mehr schlecht als recht verwirklichen können. Es entstand die Idee einen externen Zähler zu konstruieren.
Hat hier irgendjemand damit schon praktische Erfahrungen?
Auf die Idee kamen wir weil der Prozessor offenbar so ab und an vergisst einen Tick mitzuzählen; ein Schieberegister/Multiplexer nähme dem uC ein wenig die Arbeit ab.
REB
Besteht nicht die Möglichkeit Interrupts zu benutzen? Dann würde der MC auf keinen Fall ein Signal verpassen.
Ist das Signal getriggert?
MFG Moritz
Es lief bisher über externe Interrupts, die bei ansteigender Flanke getriggert wurden. Nur produzieren zwei solche Taktscheiben bergeweise Interrupts, und unser Controller hatte dann nicht mehr genügend Zeit für andere Aufgaben. Es wurden z.B. Zeichen am USART verschluckt...
So kamen wir halt auf die Idee, einen Hardwarezähler zu nehmen und ihn per SPI regelmäßig abzufragen.
Kann jemand Erfahrungen dazu posten? (wie baue ich die Schaltung so, dass beim Abfragen keine Impulse "verschluckt" werden? Hat jemand sowas schonmal gebaut und kann nen Schaltlan posten?)
mfG
cht
Schaltplan brauchst du eigentlich nicht. Nimm einen 8-bit-up-down-counter, dessen Ausgänge auf ein 8-bit-Schieberegister gehen. Der Takt, der Strobe und der Datenausgang des Registers gehen auf 3 µC-Ports. Zuerst gibst du den Strobe aus zum laden des Registers. Danach taktest du 8x das Register und liest VOR dem Takten das Output-Bit des Registers ein. Wenn du möchtest kannst du den Zähler nach einem Lesevorgang löschen, kannst aber auch die Differenz zum vorigen Zählerstand bilden um die zurückgelegte Teilstrecke zu messen (bei Kurvenfahrt z.B.)
Up-down-counter nur, wenn der Inkrementalgeber des Rades auch einen entsprechenden Ausgang hat. Sonst Vorwärts- oder Rückwärtsfahrt durchführen -> Impulse zählen und als positive oder negative Strecke in die Berechnung des Weges einsetzen. Dann reicht ein einfacher Zähler.
Es gibt auch Counter-shift-register als ein Schaltkreis, mußt mal googlen. Phillips hat die sicher auch
Zitat:
Hat hier irgendjemand damit schon praktische Erfahrungen?
Ich nehme an bei der Frage nach der Erfahrung und nach einem Schaltplan geht es um solche Details wie:Zitat:
Schaltplan brauchst du eigentlich nicht.
Soll der Zählereingang gesperrt werden, während das Schieberegister ausgelesen wird? Besser mit Latch? Synchronisation von Latch und Zählimpuls?
Soll/muß der Motor zum Auslesen des Zählers stehenbleiben?
Soll durch die Fahrt (während der Fahrt) ein bestimmter Zählerstand angesteuert werden?
Soll auch die Geschwindigkeit der Motoren verglichen werden können?
Manfred
ja richtig, Manfred, ich hatte aber sowieso mit weiteren fragen gerechnet. Da kann man dann auch Details besser klären. aber REB fragte so sachkundig, daß ich von mehr als Grundkenntnissen ausging.
Übrigens hab ich die gleichen Überlegungen angestellt, wie er/sie.
Wenn man den Prozessor von Zählvorgängen entlasten will oder mehrere Zähler abfragen muß, dann ist so eine Lösung mit einer Art Sensorbus gekoppelt garnicht schlecht.
Übrigens ein Latch braucht man bei meinem Vorschlag nicht. Gelatched wird eh im Schieberegister. Während des Strobes kann der Zähler locker weiterzählen. Dann wird der Impuls eben mit erfaßt. Einen digitalen Fehler von einem Digit hat man sowieso immer (auch bei ADUs usw.)
Statt Schieberegister ist natürlich auch ein PCF8574 I2C-Portexpander einsetzbar.
Nicht wirklich. Ich wollte eigentlich zunächst ein Mal wissen ob es schon Erfahrungen mit dem externen Auslesen von Encodern gibt (das Rad muss man nicht jedes Mal neu erfinden).Zitat:
Zitat von Manf
Ob der Motor stehenbleiben soll (wenn man mal die Taktfrequenz und Befehlszyklen eines Mega 32 oder 128 betrachtet und grob die Aufeinanderfolge von Impulsen abschätzt erübrigt sich eigentlich solch eine Frage) spielt keine Rolle.
Noch mal: Es geht um Odometrie, also um Korrektur von Fehlern, die durch unterschiedliche Motorengeschwindigkeit / Getriebespiele / ... entstehen. Ein angenehmer Nebeneffekt könnte sein, dass dann auch die Orientierung im Gelände leicht zu programmieren ist.
Wie man Takte synchronisiert - das interessiert mich nicht (weil bekannt).
Die Idee mit dem PCF8754 ist übrigens gut; danke dafür.
REB
Meinst du damit, wie man es macht, dass die Motoren gleich schnell laufen?Zitat:
Wie man Takte synchronisiert - das interessiert mich nicht (weil bekannt).
Wie machst du das denn? Würde mich interessieren, weil ich bald vor dem selben Problem sthen werde.
MFG Moritz
Nein, Taktsynchronisationen sind mir bislang nur bei bei Übertragungsprotokollen über den Weg gelaufen.Zitat:
Zitat von RCO
Um es vorweg zu sagen: Motoren laufen nie gleich schnell. Deshalb muss man ja den zurückgelegten Weg messen und je nach Messergebnis die Motoren unterschiedlich ansteuern. Und genau damit schlagen CHT und ich uns rum...
Für Odometrie ohne externe Counter: siehe seattle robotics org...
REB
Das wollte ich damit sagen, dachte du/ihr hättet einen schönen Lösungsansatz.Zitat:
Motoren laufen nie gleich schnell. Deshalb muss man ja den zurückgelegten Weg messen und je nach Messergebnis die Motoren unterschiedlich ansteuern.
MFG Moritz
Du hast Post!Zitat:
Zitat von RCO
REB
Also zu RCO ich glaube was du suchst nennt sich PI-Regler. Such mal hier im Forum. Wenn du C kannst gibts unter www.mc-project.de unter programme die Beispielsource für ne PI-Regler software.
Zu REB wieso benutzt ihr nicht nen ganz kleine AVR/PIC nur für die Motorsteuerung. Der müsste doch dann damit zureckt kommen.
Gruß Muraad
@muraad:
Danke für den Tip, ich kann leder kein C, aber es scheint so oder so eine relativ komplizierte Rechung zu sein mit zu vielen floats.
http://www.mc-project.de/Pages/Robotik/pi-regler.c
MFG Moritz
Geht so. Ich habe Dir erneut etwas zugesendet. Ist aber auch nicht viel einfacher...Zitat:
Zitat von RCO
REB
ganz einfach: das ist nicht in dem Regelwerk des Wettbewerbs, an dem wir derzeit Teil nehmen, erlaubt.Zitat:
Zitat von muraad
Es darf nur ein 8 bit Prozessor benutzt werden.
REB
Ja dann wird des um einiges schwieriger, nur ein Controller hmm... [-(
Ein up/down counter (mit reset zu Beginn) kann die Impulse von rechts und links aufnehmen und die Differenz abrufbar machen, nach der die Geradeausfahrt geregelt wird. (Entsprechend bei Bedarf auch das Drehen auf der Stelle. )
Manfred
gute Idee Manfred.
Wenn ein up-down-counter zyklisch auf einen mittleren Zählerstand geladen wird, dann kommen entweder regelmäßige down-overflows oder up-overflows jenachdem welcher Motor sich schneller dreht. Die kann man dann zum Nachregeln ausnutzen.
Liesse sich damit dann auch noch die zurückgelegte Strecke des Roboters berechnen? Ich glaube nicht, oder? Ansonsten gefällt mir die Idee sehr gut.
Den Zähler, der dafür noch nötig ist, müßte man halt zusätzlich spendieren.
Manfred
man sollte zuerst ausrechenen, wieviele Inkremente maximal auftreten können (aus raddurchmesser, Strichzahl, Übersetzung usw.) bei einer maximal vorkommenden Strecke (indoor). Danach kann man den Zähler auslegen. Soll er von mir aus, einige Kaskaden haben, soviel Platz ist immer. Damit ist die Absolutposition nach einem Nullabgleich immer ablesbar (im Rahmen der Fehlergrenzen). Ab und an mal nachnullen gegenüber einer Referenz schadet nicht.
Hat man zuwenig Zählerstufen, bleibt nur übrig, immer mal den Zähler auszulesen, bevor er überläuft. Dann muß der µC den Zählerstand aufsummieren.
genau so werden wir es wohl bauen: zwei 8bit U/D-Zählerkaskaden, je eine für linkes und rechtes Rad. Der Mikrocontroller muss dann - wohl timergesteuert- die Counter so oft abfragen dass sie im worst case nicht überlaufen können.
Im Controller kann man dann recht einfach die Position und den Winkel des Roboters im 2D-Koordinatensystem seiner Umgebung errechnen:
http://www.informatik.uni-leipzig.de...hepera/diffeq/
mfG
cht