Pro Bot 128 / Projekt: Motorsteuerung verbessern

Mahlzeit!


Wie ich aus zahlreichen Posts in diversen Foren entnehmen konnte und letztendlich (glaube ich) selbst verstanden habe, ist die Motoransteuerung beim Probot 128 sagen wir mal „suboptimal“. Daher habe ich mir ein paar Gedanken gemacht, wie man die Ansteuerung (im ersten Schritt hardwareseitig, Software muss dann natürlich auch angepasst werden) verbessern könnte. (bin Elektro-Laie, also bitte nicht allzu sehr maßregeln, wenn ich etwas falsch erkläre)




++++++ Zum Bestand ++++++

Verwendete Bauteile:

1. C Control Pro Mega 128 (Microcontroller)
2. CD4093 (NAND-Gatter)
3. L293D (Motortreiber)

Schaltung:
2x PWM Signal (von Pin X1_2 = OC1B bzw. Pin X1_3 = OC1A) wird über ein NAND-Gatter (CMOS 4093) an die Input Pins 1+2 bzw. 3+4 vom Motortreiber L293D verteilt.
Ein PWM-Signal wird über jeweils 2 der 4 NAND-Gatter so invertiert, dass am Motortreiber IN1 High ist, wenn IN2 Low ist und umgekehrt. Das gleiche gilt sinngem. für IN3 und IN4.
Der Pin X1_1 (OC1C) schaltet beide Enable-Eingänge bei Bedarf permanent auf high.

Die Motorgeschwindigkeit ist im Bereich von 0-255 einstellbar; allerdings mit der Besonderheit, dass die Motoren bei einem Wert von 128 (50/50 Puls/Pause) stillstehen und bei Werten >< als 128 in die jeweilige Richtung drehen. Als ich die Funktionsweise endlich verstanden / nachvollzogen hatte, habe ich gestutzt, da die vorhandene Steuerung der Drehrichtung und der Geschwindigkeit über ein PWM-Signal pro Motor ja bedeutet, dass die Motoren quasi ständig im Wechsel vorwärts und rückwärts fahren. Je nachdem in welche Richtung sie dann drehen sollen eben mehr vorwärts als rückwärts oder umgekehrt.

Selbst mir als absoluter Laie war nach dieser Erkenntnis klar, dass das nicht effektiv sein kann. Ein Auto fährt man ja auch nicht 50m im Vorwärtsgang und dann wieder 5 oder 10m zurück, nur um langsamer zu fahren. Außerdem vermute ich, dass der permanente Richtungswechsel nicht grade materialschonend ist.

Diese Ansteuerung spart zwar (auf den ersten Blick) Pins am Controller, bedeutet aber, dass die Motoren nicht auf voller Leistung laufen (korrigiert mich, wenn ich falsch liege).


++++++ Zur geplanten Veränderung ++++++

1. IC-Sockel Adapter:
Um die Motorplatine im Originalzustand belassen zu können und die schon vom Controller zur Motorplatine geführten Pins weiter benutzen zu können, habe ich mir mittels Platinenstückchen und Stiftleisten bereits einen Adapter für die beiden vorh. IC Sockel zurechtgedengelt.

Vom Sockel des CD4093 greife ich über 4 Stifte die Pins X1_2 und X1_3, sowie VSS (inkl. Pufferkondensator auf Platine) und VDD (GND) ab. Vom Sockel des L293D greife ich den PIN X1_1 (im Bestand Enable 1), VSS (inkl. Pufferkondensator auf Platine), GND (4x) und Output 1-4 ab.

2. Motorsteuerplatine
Auf die beiden Sockeladapter klebe/stecke ich dann eine zweite Platinenebene, auf der ich dann die Schaltung mit einem CD4093 und dem L293D neu aufbaue.

Ich plane die beiden PWM-Signale (X1_2 und X1_3) an die Enable-Eingänge des L293D zu führen. VSS und GND wie im Bestand. VS (Motorversorgung) kommt dann direkt von meinem Akkupack mit 6x2/3 A Akkus (7,2V bzw. voll geladen ca. 8,4V / 1300mAh).
Die Richtungsansteuerung über die Inputs 1+2 bzw. 3+4 will ich über jeweils einen Controllerpin (X1_1 und einen beliebigen anderen) mit entsprechend vorgeschaltetem NAND-Gatter realisieren. Ich denke mal, dass ich auf die „Vollbrems-Option“ durch kurzschließen der Inputs gut verzichten kann. Den zusätzlich notwendigen Controllerpin könnte ich dann über die noch freie Leitung auf dem einen Wannenstecker auf die Motorplatine herunterführen.

Schaltbilder kann ich heute Abend nachreichen.

Viel Text, ich weiß…J

Ich bitte um Kritik und Verbesserungsvorschläge!
Danke!

Hallo

Bei meinem probot hatte ich das so gelöst:

Bild hier  

Im ersten Schritt habe ich die Enable-Signale getrennt. Hier ist das für meinen asuro-probot beschrieben:
https://www.roboternetz.de/community...l=1#post421099

Für einen orginalen probot würde ich dann noch empfehlen das Flachkabel zu manipulieren:
https://www.roboternetz.de/community...l=1#post423547

Gruß

mic

Das mit dem Auftrennen der Leiterbahnen und verändern der Flachkabel ist natürlich auch eine gute Idee. Hatte den Thread von dir sogar schonmal vor Augen. Jetzt wo ich mich etwas mehr mit dem Schaltplan des Probot beschäftigt habe, frage ich mich, warum ich da nicht schon selbst drauf gekommen bin. :-D
Danke für den Tipp!

Bzgl. der Motorversorgungsspannung:
Hast du eine Ahnung, wieviel die verwendeten Motoren abkönnen? Würde gerne die 7,2V (8,4 bei vollem Akku) vom Akkupack verwenden. Einfach mal testen und gucken wie warm die Motoren werden? Dann müsste ich nur die Leiterbahn zu Pin 8 ebenfalls trennen.

- - - Aktualisiert - - -

Grad nochmal auf das Platinenlayout geschaut. Du hast geschrieben Bahn zwischen IC1:1 und IC1:9 trennen, Pin 9 ist dann isoliert. Ist dann nicht eigtl. PIN1 isoliert und hat den zusätzlichen Pulldown? Ist ja nicht so wichtig, nur für mich zum Verständnis.

Und wenn ich Pin8 isolieren will, muss ich dafür 2 Leiterbahnen trennen. Einmal die dicke kurz hinter dem Abzweig zu D1 (IR LED) und die dünne in Richtung R7 bei T4 und R7 dann mit nem Draht wieder an +5V.

Leiterbahnenlabyrinth...

Update:
"Sockeladapterlösung" verworfen.
Viele Lötpunkte=viele potentielle Fehlerquellen.

Habe gestern dem Vorschlag radbruchs folgend die Belegung der Pfostenstecker von con1/con3 getauscht. Hat geklappt, aber die Pfosten und ich werden keine Freunde :-D

Leiterbahn zwischen IC1:1 und IC1:9 ist auch durchtrennt. Hatte nach der Fummelei mit dem Stecker aber keine Muße mehr weiterzumachen.

Heute wird dann der Pulldown R und die neue Enableleitung (Free) an IC1:1 angelötet.

Was mir noch nicht ganz klar ist:
wenn ich die Motorversorgung IC1:8 direkt vom 7,2v Akku speise. Fließt dann auch strom nach masse ab, wenn der l293d "aus" ist? Dann würde ich da nämlich auch noch einen Schalter anbringen.

Wenn die Hardware fertig ist, schreibe ich erstmal einen minimalcode um zu gucken ob alles läuft.

Hallo

Zitat:

---

Du hast geschrieben Bahn zwischen IC1:1 und IC1:9 trennen, Pin 9 ist dann isoliert. Ist dann nicht eigtl. PIN1 isoliert und hat den zusätzlichen Pulldown?

---

Ja, du hast natürlich recht. Pin 1 (mit dem quadratischen Lötpad) ist der zusätzliche freie Pin und bekommt den neuen Pulldown.

Zur Motorversorgung kann ich leider nichts sagen, weil ich das noch nicht probiert habe. Ein extra Schalter kann aber sicher nicht schaden, eventuell wäre sogar eine zusätzliche Sicherung sinnvoll.

Gruß

mic

Ok danke!

Habe noch eine testschaltung mit einem l293d auf meinem steckbrett. Könnte ja einfach mal messen. :-)
Theoretisch müsste dann ja wenn enable auf low ist kein potential zwischen massepin und Batterie minus anliegen.

Was für eine Sicherung meinst du denn?
Um den IC vor zu hoher stromstärke zu schützen? Habe woanders mal gelesen, dass ICs schneller braten als eine Sicherung auslösen kann. Die Motoren ziehen angeblich bei 5v um die 300mA Blockierstrom.

Die gemeinsame masse der 5V und der 7,2 Volt direkt an den massepins macht aber keine Probleme oder? Zusammenlegen muss ich die Massen ja sowieso. Als Laie frag ich mich nur, ob dadurch andere Bauteile zuviel bzw. negative Spannung bekommen. Ein Elektriker schlägt sich bei dieser Frage wahrscheinlich die Hand vor den Kopf.

Bei der Sicherung dachte ich eher an einen allgemeinen Schutz vor der Power des 7,2V-Akkupacks. So 2-4A vielleicht, damit bei einem Kurzschluss nicht alles verbrutzelt...

Gemeinsame Masse ist kein Problem, sollte allerdings möglichst nur an einer Stelle verbunden sein (an der Masse des L293D).

http://www.conrad.de/ce/de/product/5...10-St?ref=list

So etwas? Reicht eine flinke oder besser superflink? Die sind aber tlw. 10x so teuer...

Und mir stellt sich die Frage an welche Stelle? Ich gehe momentan mit 7.2 v über Mini tamiya Stecker und polklemme an Batt+, um die ladebuchse und den Schalter nutzen zu können. Die diode habe ich rausgenommen. Vom jumper aus zweige ich ab auf den spannungsregler (78s05) und dann mit 5v zurück auf die andere Seite des jumpers.

Würde die Sicherung glaube ich vor den spannungsregler setzen und dann evt noch eine für die Leitung zur motorversorgung. Ideal wäre natürlich eine sicherungshalterung direkt im akkukabel. Mal Onkel Google Fragen, ob es sowas gibt.

- - - Aktualisiert - - -

http://www.conrad.de/ce/de/product/8...f=searchDetail

Wenn flachsicherungen reichen, wär das doch ideal...

Hallo

Direkt im Akkukabel würde ich auch vorschlagen. Damit verhinderst du, dass bei einem Kurzschluss auf den Platinen die Akkupower zuviel zerstört. Flinke Sicherungen sollten da ausreichen:

Bild hier  
(Bild von: http://www.conrad.de/ce/de/product/3...-MM-SCHRAUBBAR)

Zitat:

---

Lieferumfang

2 A und 3 A Sicherung.

---

Prima?
http://www.conrad.de/ce/de/product/5...A-Inhalt-10-St

Zitat:

---

Die Hauptsicherung wurde von 2.5A auf 3.15A erhöht, da zusätzliche Stromversorgungsanschlüsse hinzugekommen sind..

---

Ein Zitat aus der Beschreibung der Veränderungen des RP6v2 gegenüber dem alten RP6. Wenn der bisher mit 2,5A abgesichert war sollten 2A für den probot ausreichen. Das ist aber nur geschätzt...

Gruß

mic

P.S.: Ob flink oder besser träg mußt du selbst ausprobieren...

Werde mir diesen hier zulegen, da vorrätig...
http://www.conrad.de/ce/de/product/5...AC-PTF80A-1-St

Sicherung verbaut, testcode (mit pwm) geschrieben... Motoren drehen kaum, nur mit Schwung geben.

Testcode geändert (enable High oder low) Motoren drehen kaum.

Multimeter rausgeholt. Hier und da gemessen. Logikspannung, motorspannung am l293d unter 1v, schwankend.

Am Kopf gekratzt, am veränderten pfostenstecker gewackelt. Zack! 5v kommen am ic an.

Motortest: drehen wie verrückt.

Funktionstest mit geradeaus vor und zurück, links/rechts drehen:
Fährt entweder nur geradeaus und dreht rechts oder nur zurück und dreht Links.

Tippe auch hier auf wackelige Kontakte im Stecker. Habe den Stecker beim auseinanderbauen demoliert und diesen "schneidleisten" als klemmen im Stecker traue ich sowieso nicht. Nach Ostern mal neue Stecker besorgen und das flachkabel tauschen.

Kann es noch an was anderem liegen?
Wenn ich die Motordrehrichtungsports auf Ausgang konfiguriere und dann entweder eine 0 oder eine 1 reinschreibe, müssten die doch zwischen High und low wechseln oder? Klappt bei den enable Leitungen ja auch.

Hallo

Du hast ja sicher auch den "Frei"-Pin neben dem Sockel oben mit dem Kontroller verbunden, oder?

Ärgerlich, dass die Stecker ausgerechnet vor einem langen Wochenende kaputt sind. Alternativ und zu Testzwecken könnte man die auch verlöten.

Gruß

mic

Jupp habe ich. Ja ist es. Aber diese Stecker schadfrei wieder zu demontieren ist so gut wie unmöglich. Daher rate ich dazu wenn die Kabel mittig zu trennen, drehen, anzulöten und verschrumpfzuschlauchen. Spiele außerdem kt dem Gedanken noch zwei pins zu opfern, da man anscheinend den b Kanal vom Timer nicht unabÄngig konfigurieren kann.


Frohe Ostern :-) !

Heute neue Pfostenbuchsen und nen Meter Flachbandkabel vom großen C geholt, neues Kabel "gebaut" mit den getauschten Leitungen. Kontakte sind nun alle einwandfrei.

Allerdings bleibt das Problem mit der Drehrichtung vorhanden.
Daher tippe ich darauf, dass das Problem vor dem Bildschirm sitzt.
Beide Motoren drehen sich, nur nicht in die gewünschte Richtung.

In meinem Programm definiere ich zuerst die Ports mit
#define Motor_Dir_Left 15
#define Motor_Dir_Right 11
#define Motor_Enable_Left 14
#define Motor_Enable_Right 13

In der Main setze ich dann die Ports auf Ausgang mit
Port_DataDirBit(Motor_Dir_Left,1)
Port_DataDirBit(Motor_Dir_Right,1)
Port_DataDirBit(Motor_Enable_Left,1)
Port_DataDirBit(Motor_Enable_Right,1)



Dann setze ich die Zustände der Ports auf High bzw. low
Port_WriteBit(Motor_Dir_Left,0) 'Richtung vorwärts / INVERTIERT über CD4093
Port_WriteBit(Motor_Dir_Right,0)
Port_WriteBit(Motor_Enable_Left,1) 'Motoren an
Port_WriteBit(Motor_Enable_Right,1)

Eigtl. sollte der Bot dann doch vorwärts fahren. Er fährt aber rückwärts!

Mit diesen Porteinstellungen müsste er ja dann in die andere Richtung fahren. Er fährt aber wieder rückwärts!
Port_WriteBit(Motor_Dir_Left,1) 'Richtung rückwärts / INVERTIERT über CD4093
Port_WriteBit(Motor_Dir_Right,1)

Bei Drehungen mit Ports 0 und 1 bzw. 1 und 0 dreht er immer nur links herum.

Muss ich am ersten Eingang vom NAND-Gatter vlt. noch einen Pulldown anbringen, weil die Zustände sonst nicht klar definiert sind? Aber eigtl. müsste er dann ja einfach iwas machen ohne reproduzierbares Ergebnis.

Ich hoffe jmd. kann mir hier die Erleuchtung bringen, was ich falsch mache... :confused:

- - - Aktualisiert - - -

Grad nochmal in den Schaltplan geschaut. Ja da müssen wohl Pulldowns an Pin 1+2 und 9+8 vom nand-Gatter, da wo die Controllerleitungen dran hängen. Ist ja mehr oder weniger dasselbe wie bei den Enable-Eingängen vom Motortreiber.

- - - Aktualisiert - - -

Pulldowns sind eingelötet. Keine Besserung :'(

Liegt es evt. am verwendeten Portbit für Motor_Dir_Left ? Habe den Bit Nr. 11 (X1_5 / MISO) verwendet. Kann man diesen Bit normal benutzen oder wird er evt. durch andere Funktionen überlagert?

- - - Aktualisiert - - -

Es geht doch nichts über ein gepflegtes Selbstgespräch...
Der Miso-Bit gehört zur SPI-Schnitstelle. D.h. ich muss entweder SPI_Disable() aufrufen um den Bit verwenden zu können oder einen anderen Bit benutzen. Hoffe das ist die Lösung. :-D

Hallo

Ich leide mit dir, kann dich aber leider nicht unterstützen, weil ich den orginalen Kontroller nicht besitze. Und die Zeit zum Einlesen habe ich im Moment leider auch nicht.

Zitat:

---

Es geht doch nichts über ein gepflegtes Selbstgespräch...

---

Jepp, da kann ich nur zustimmen :)

Gruß

mic

Geteiltes Leid ist halbes Leid :-D

Heureka!
SPI_Disable() hat den Durchbruch gebracht. Der Bit den ich für die Drehrichtung benutze ist sonst nicht programmierbar. Nun fährt er schonmal in die richtige Richtung.

Als nächstes geht es per try and error an die minimaleinstellung für das pwm Signal. Bei der Einstellung 50:50 Puls/Pause tut sich mal so gar nix.

Nach Tests mit diversen PWM-Frequenzen von 5kHz bis runter auf 222Hz hat sich gezeigt, dass ich den größten Einstellbereich (100-ca.35%) für die Geschwindigkeit bei 222Hz habe, da bei dieser Frequenz auch im niedrigen Drehzahlbereich noch genügend Drehmoment vorhanden ist, um den ProBot zu bewegen.
Außerdem ist so auch das nervige fiepen weg, dass im hörbaren Bereich zwischen 2-5kHz liegt.

Nun stellt sich mir die Frage, ob so eine niedrige Frequenz evt. schädlich für den Motor ist.

https://www.roboternetz.de/community/threads/25135-PWM-Motor-Frequenz
In diesem Thread heißt es unten, dass kleine DC-Motoren mit niedrigen Frequenzen (500-600Hz) gut laufen.
Je größer der Motor, desto höher sollte die Frequenz sein. Mit 500 Hz habe ich auch getestet; da ist dann allerdings schon bei 40% kein vorankommen mehr.
Oder sollte ich vlt. in den Bereich von 5-10kHz wechseln? Allerdings steht im Datenblatt vom L293D:
This device is suitable for use in switching applications at frequencies up to 5kHz.

http://www.mikrocontroller.net/artic...uerung_mit_PWM

Das ist ein sehr interessanter Artikel zur pwm Frequenz für Motoren.

Demnach sollte ich vlt. Doch mal den Bereich >5kHz testen.

Mal schauen, ob ich ne Max Frequenz für den l293d Iwo finde außer der Angabe von 5kHz im Datenblatt.

Nach langer langer Pause hier mal ein Update:
Vor Kurzem habe ich meinen zwischenzeitlich auf den Dachboden verbannten Probot rausgekramt, da mich die Bastellaune packte.

Wem der folgende Text zu lang ist bitte runterscrollen zu "Meine Vermutungen" :-)

Nach etlichen Stunden des Messens und Grübelns habe ich die Ursache gefunden, warum er keine Verbindung mehr zum PC herstellen konnte. Es lag an defekten Mikrotastern, die den Reset- und Boot-Pin des Controllers auf Masse ziehen müssen beim einschalten, um so die PC-Verbindung zu ermöglichen.
Von diesem Teilerfolg beflügelt habe ich mich wieder mit der Optimierung der Motorsteuerung und der Odometrie beschäftigt und bin auf etliche Probleme gestoßen.

Ziel ist es, eine Funktion mit PID-Regler zu programmieren, die es ermöglicht per Eingabe entsprechender Variablen den Roboter zu steuern. Eine Funktion, die mir als Grundlage dient, ist in der Originalbibliothek des Probots bereits vorhanden, "GO_TURN(Distanz, Drehung, Geschwindigkeit)".

In Anlehnung an den PID-Regler "nach Waste" für den Asuro habe ich das Programm umgeschrieben und auf meine Bedürfnisse angepasst. Generell funktioniert es so:

- Distanz (in cm) = abhängig vom Vorzeichen der Variablen vorwärts/rückwärts eine bestimmte Strecke fahren.
Die Motor-Dir Pins des Motortreibers L293 werden hierzu entsprechend auf High oder Low gesetzt.
Die Messung/Berechnung der Strecke erfolgt per Vergleich des SOLL- und IST-Wertes für die notwendige Anzahl an "Encoder-Ticks" der Odometrie des Probots, z.B. 100cm = 500 Ticks. Diese werden per ISR erfasst.

- Drehung (in Grad) = wie zuvor, jedoch für links/rechts auf der Stelle drehen

- Geschwindigkeit (0-255) = SOLL-Wert Startgeschwindigkeit, Ansteuerung des Enable Pins eines L293 per PWM, der die Motoren antreibt. Ab einem bestimmten Minimalwert wird nach unten begrenzt, da die Räder sonst stillstehen.

- Bedingt durch die Verbindung der einzelnen Komponenten ist aktives Bremsen durch kurzschließen der Motor-Dir Pins am L293 aktuell nicht möglich. Sollte es sich im späteren Verlauf zeigen, dass dies sinnvoll oder notwendig ist, kann ich am Controller problemlos weitere Pins nutzen.

Nun zu meinem Problem und den Lösungsansätzen:
Grundsätzlich funktioniert das Programm so wie es soll, allerdings fährt der Roboter keine Gerade, sondern einen betrunkenen Bogen, sprich die Korrekturwerte für den P, I und D Anteil passen nicht. Zum Testen und Debuggen habe ich in den Code der Mainfunktion Textausgaben eingefügt, um folgende Werte die innerhalb des Programmablaufes relevant sind im PC-Terminal anzeigen zu lassen:

- Encoder Count Left und Right (IST-Werte) / Encoder Count Gesamt (SOLL-Wert),
errechnet aus (Summe Left+Right)/2
- Error (Encoder Count Right abzgl. Encoder Count Left)
- aus Error berechnete Stellgrößen für P, I und D-Anteil
- Anzahl der Schleifen, sprich wie oft die While Schleife für den Regler insgesamt durchlaufen wurde bis der SOLL-Wert für die zurückgelegte Strecke erreicht wurde.

Hierbei trat nun folgendes Problem auf:
Es hat sich gezeigt, dass bei bestimmten PWM-Frequenzen, jedoch nicht wirklich reproduzierbar, die Odometrie des Probots falsche Werte liefert. Einer der beiden Sensoren meldet sobald die Motoren anlaufen direkt in der ersten Schleife z. B. einen Wert von 200-300 Ticks und der andere 0 Ticks. Die Räder drehen sich aber noch nicht einmal!
Dadurch wird die While Schleife verlassen und die Funktion als erledigt angesehen, da die Gesamtticks bereits den SOLL-Wert überschreiten.

Eine Recherche im C-Control Forum ergab, dass dieser Effekt anscheinend durch einen Konstruktionsfehler des Probots entsteht. Auf der Motorplatine verlaufen die Leiterbahnen für die Signale der Radencoder in Teilbereichen direkt über den Leitungen für die Motoransteuerung, auf denen das PWM-Signal übermittelt wird (Oberseite und Unterseite der Platine). Das PWM-Signal beeinflusst dadurch die Encodersignale und zusätzliche Interrupts werden hierdurch ausgelöst. Um das Problem zu umgehen wird vorgeschlagen, die Leiterbahnen zu kappen und ein geschirmtes Kabel direkt von den Sensoren zu den Pfostensteckern zu legen, die Motor- und Controllerplatine verbinden. Weiterhin wird u.a. auch in dem Probot-Buch empfohlen zwischen den Sensoren und dem Controller Schmitt-Trigger einzubauen, um die Signalflanken schön rechteckig zu formen.

Beide Tipps habe ich nun bereits umgesetzt. Die Signale der Encoder werden in ein IC vom Typ 4093 (HCF4093B) gegeben, dass an den Ausgängen 0 oder 5 Volt an den Controller überträgt.
Außerdem habe ich den originalen Encoder-Sensor bestehend aus einem Fototransistor und einer IR-Diode, die im 90° Winkel zueinander angeordnet sind und auf eine Schwarz-Weiß Zählscheibe mit 8er Teilung blicken, gegen einen CNY70 auf der Unterseite der Platine ausgetauscht. Auch die Zählscheibe habe ich gegen eine mit 32er Teilung aus bedruckter Transparentfolie mit einem Hintergrund aus Alufolie getauscht, um die Auflösung zu erhöhen. Um ein brauchbares Low-Signal für den Schmitt-Trigger zu erhalten musste ich außerdem den Vorwiderstand der beiden in Reihe geschalteten IR-LEDs aus den beiden CNY70 von 220 auf 100 Ohm reduzieren.
Wenn der Fototransistor durchsteuert zieht er den Eingang vom Trigger nun auf Low (ca. 1,2 Volt), wenn er sperrt liegt am Triggereingang >4,2 Volt an.

Durch Messen (Multimeter) und einen manuellen Check der Interruptfunktionen hat sich gezeigt, dass die Interrupts durch händische Drehen des Rades nun zuverlässig ausgelöst werden.

Ein Problem behoben, nächstes Problem folgte direkt im Anschluss:
Die oben beschriebene GO-TURN Funktion liefert mir nun nur noch Werte von 0 für alle Regel- und Stellgrößen!?
Der Encoder-Count links und rechts wird nicht erhöht und die Abbruchbedingung für die While Schleife somit nicht erreicht. Auch der Regler kann mit einem Error von 0 natürlich nichts regeln.
Sprich die Räder drehen sich permanent. Allerdings gibt es nun auch keine Störungen mehr durch das PWM-Signal.
Aber es würde ja auch keinen Spaß machen und man würde nichts dazu lernen, wenn alles auf Anhieb klappt.

Meine Vermutungen:
1. Ist es möglich, dass durch die 4-fach höhere Auflösung der Ablauf der Encoder-ISR (jeweils eine für das linke bzw. rechte Rad) gestört wird, da die Interrupts schneller ausgelöst werden als die ISR sie abarbeiten kann? Die Scheibe ist 32 fach (16x schwarz/16xAlufolie) aufgeteilt und der Interrupt wird bei jeder steigenden und fallenden Flanke ausgelöst, sprich bei jedem Wechsel von schwarz zu weiß und umgekehrt. In der ISR selbst werden nur die Variablen für den Zählstand um 1 erhöht und das Interruptflag gelöscht. Hat bei einer geringeren Auflösung mit Original-Encodern funktoiniert.

2. Kann es sein, dass durch die schnelle Drehung der Zählscheibe bei Antrieb per Motor keine brauchbaren Pegel mehr für den Schmitt Trigger verfügbar sind? Also der Pegel iwo im Bereich der Hysterese des Schmitt-Triggers dümpelt, so dass er nicht "durchschaltet". Als Laie stell ich mir das als "50% graue Scheibe" vor.

Für etwaige Denkanstöße und Winks mit Zaunpfählen danke ich im Voraus!

Werde heute Abend mal Scheiben mit geringerer Auflösung probieren und versuchen per Multimeter die Frequenz zu messen (habe in dem Ding eine Funktion für Anzeige in Hertz).

Meistens sitzt das Problem vor dem Rechner...
Habe übersehen, dass ich die Funktion PRO_BOT128_INIT() bei den diversen Versuchen mit Geschwindigkeit etc. aus versehen "auskommentiert" habe !!!
in dieser funktion werden am anfang alle variablen und ports definiert und auch die interrupts gesetzt... sprich ohne aufruf dieser funktion am anfang ist der probot nicht lebensfähig!

mein programm läuft nun soweit und die encoder zählen brav mit. versuche grad vernünftige werte für die PID anteile per try and error zu ermitteln.
problem dabei: der linke motor scheint zu schwächeln. werde mir mal anschauen, wie das andere leute hier für ihren asuro gelöst haben. der linke motor braucht länger um das rad in bewegung zu setzen. nach einer kurzen strecke fährt mein bot dann grade. aber eben nicht in die ursprüngliche richtung, sondern bedingt durch den frühstart des rechten motors immer mit versatz nach links. dieser effekt ist beim vorwärtsfahren deutlicher als beim rückwärtsfahren.

Lösungsansätze:
1. Regelgröße speed_left manuell vor Übergabe an den PWM-Timer um einen bestimmten wert erhöhen bzw. speed_right verringern.

2. rechter motor darf erst gas geben, wenn am linken motor der erste interrupt durch die zählscheibe ausgelöst wurde.

3. akkupack (6x1,2v hinten auf motorplatine) auf die experimentierplatine montieren, möglichst zentral zum drehpunkt. durch die masseträgheit übersteuert er speziell bei schnellen drehungen um die eigene achse. je kleiner der winkel, desto deutlicher die übersteuerung.

Ziele:
1. genauigkeit verbessern bei wegstrecke bzw. drehung um einen bestimmten winkel.
2. funktion für kurvenfahrten integrieren. z.b. drehung um 90° mit einem vorgegebenen bogenmaß um einen imaginären drehpunkt.

3. wenn das steht sehe ich mal weiter was mir dann einfällt. würde z.b. gerne ein lc-display einsetzen auch zum debuggen im gelände und nicht nur am pc.

4. ultraschallsensor auf servo montieren als umgebungsscanner

es gibt viel zu tun!

bin mir zwar nicht sicher, ob das hier überhaut noch jmd. mitliest aber ich schreib mal weiter (mein) tagebuch:

1. Motorsteuerung läuft soweit, aber gerade fährt der kleine noch nicht. muss wohl nich weiter an den PID Werten feilen...

2. Die Motorspannung am L293D kommt bei mir direkt aus dem Akku (6*AA Zelle, frisch geladen ca. 8,4v) Mir ist aufgefallen, dass hier durch die getrennte versorgungsspannung gar kein kondensator mehr im stromkreis ist. habe nun einen elko mit 100 microfarad parallel zu GND dazwischengeklemmt. nächste versuchsreihe steht noch aus.

3. mittels i2c portexpander pcf8574 habe ich ein 2x16 zeichen lcd auf der breadboard platine hinzugefügt. hat dank der vorhandenen i2c lcd lib (fast) auf anhieb geklappt. problem war anfangs ein zu kleines poti am kontrastpin, wodurch das lcd nichts angezeigt hat.

4. für erste gehversuche mit SPI habe ich außerdem 8 stück rote 3mm low current leds auf der vorderen hälfte der breadboard platine angeordnet und über ein 74hc595 schieberegister an den spi bus angeschlossen. hat auch (fast) auf anhieb geklappt. hab halt einfach mal den takteingang am falschen mc pin angelötet (bis 7 zählen ist schon schwierig)...
mittels byte arrays kann ich mir nun neben dem lcd auch über diverse blinkmuster der leds z.b. zustände oder aktuelle funktion anzeigen lassen.
oder ein nightrider lauflicht für den "coolness-faktor" ;-)

5. da die alten bumper, bestehend aus mikrotastern mit schaschlikspießfühlern bei den diversen probefahrten bzw. bei schnellen drehungen um die eigene achse zu nahe an einer wand gebrochen sind (schaltwippe) habe ich mir aus einem gebogenen eisstiel und zwei drucktastern einen neuen bumper gebaut, der hoffentlich stabiler ist. funktion allerdings noch nicht getestet.
brauchen ziemlich viel druck zum auslösen (ca. 250 g).

nächste schritte:
-zusätzlicher distanzsensor mit tendenz zu einem sharp ir auf servo
-stromversorgung überarbeiten
. aktuell gelöst mit 7805er für die logikspannung. besser wäre eine ultralowdrop variante oder schaltregler
-libraries nochmal sauber durcharbeiten
-programm mit subsumptionsarchitektur aufbauen und den bot mit ein paar aufgaben unter einbeziehung aller verfügbaren sensoren und aktuatoren rumfahren lassen
-selbständiges anfahren einer ladeschaltung
-weltherrschaft ^^

werde gleich mal ein paar fotos für interessierte einstellen.

- - - Aktualisiert - - -

Anhang 31501unterste Platine mit neuem Frontbumper (rechts), Spannungsversorgung (links), Schmitt Trigger Huckepack auf Motor Dir IC, um die Signale der Radencoder zu verbessern (Mitte)

Anhang 31503mittlere Platine mit "Front-Scheinwerfern" (rechts) Danke nochmal an den user bnitram für die Hilfe dabei), Anschlüssen für die Versorgungsspannung und dem 4 poligen Kabel für den SPI Bus zum Schieberegister auf der oberen Platine (SCK, SCLK, RCLK und OE)

Anhang 31506obere Platine ohne LCD mit Portexpander PCF8574 (Mitte), Schieberegister 74HC595 (oben), Pinleiste für das LCD (rechts) und den LEDs am Schieberegister (rechts außen)

Anhang 31507Anhang 31508so sieht er aktuell zusammengebaut aus...

Anhang 31502Stromversorgungsplatine mit 7805 und reichlich Anschlussklemmen
Anhang 31504Front-Scheinwerfer
Anhang 31505Radencoder mit Reflexlichtschranke CNY70 und selbstgedruckter Encoderscheibe (selbstklebende Folie mit Laser bedruckt auf Aluminiumfolie), Auflösung 32 Ticks

Ich les hier mit- ich mag solche "Tagebücher", auch wenn ich nicht alles nach vollziehen kann- hab keinen ProBot.
Und nen Tipp zur Stosstange: ich weiss nicht, wie du das Holz gebogen hast, hoffentlich nicht kalt und einfach verklebt?
Das wird gewaltig verkanten...
Nimm Kabelbinder, der NiboBee hat welche als "Fühler"- das ist unverwüstlich.
Guck dir mal an, wie das beim NiboBee gemacht ist (die Aufbauanleitung ist frei verfügbar), vielleicht kannst du daraus was entnehmen.

Generell würd ich aber auf berührungslos setzen (ich find es generell uncool, erst gegen ne Wand fahren zu müssen, um festzustellen dass da eine ist), bei Ebay gibts spottbillig fertige IR-Sensoren (Stückpreis um nen Euro), die ein digitales Signal liefern, Reichweite zwischen 10 und 20 cm, das sollte dem kleinen doch genügen?

Moin Rabenauge!

den tipp mit dem nibobee schau ich mir nachher mal an, danke dafür.

den eisstiel habe ich paar minuten in kochendes wasser gelegt und ihn dann um eine gut gekühlte bierflasche gebogen, sprich die rundung bleibt danach so. da die knöpfe der ein taster, an denen die stoßstange gestgeklebt ist, leichtes spiel haben verkantet da nix. wetd nachher mal testen, ob der bot genug "wumms" hat um den kontakt auszulösen.

der probot hat von haus aus je drei ir sendedioden auf der vorderseite der mittleren platine und mittig dazu ein tsop empfänger, beides gepulst mit 36khz.

meine größte baustelle aktuell ist die motorsteuerung. die motoren kommen egal mit welchem pwm takt erst ab 50 duty cycle auf touren. sprich ich muss bei meinem PID- Regler eine minimalgeschwindigkeit vorgeben, sonst dreht er sich fröhlich um ein blockierendes rad und die stellwerte spielen verrückt...

Eventuell auch eine interessante Variante, die Taster sind aus alten Mäusen (haben mich nix gekostet) Auslösung bei 55g.
https://www.roboternetz.de/community...164#post622164

Aktueller Baustand: (die Bumper bekommen später noch umgebogene Ränder damit sie sich nicht verhaken können)Anhang 31510

@rabenauge
Die fühlerkonstruktion vom Nibobee ist ja echt raffiniert mit den zwei wege tastern. werde ich mir für evt eigenbauten merken. für das design des probots als "monolithische" konstruktion finde ich es allerdings nicht ganz passend. ich will möglichst keine auskragungen an der karroserie.

@i_make_it
deinen thread zum roboterbau mit kindern habe ich tatsächlich vor kurzem gelesen. habe das auch mal mit dem neffen von meiner freundin angefangen. das problem mit der aufmerksamkeitsspanne ist echt nicht zu unterschätzen...

dahinter steckt aber ein weiteres problem und zwar, dass (nicht nur bei kindern) lieber "konsumiert" wird als "produziert". solange alles (z.b. sein iphone) funktioniert interessiert das WIE herzlich wenig. ich hab mich schon immer für die zusammenhänge interessiert, bin quasi nie so ganz aus der frühkindlichen WARUM phase rausgewachsen.

deine konstruktion mit den maustastern ist auch gut zum nachbauen geeignet. sind da eigtl. alle 4 taster beschaltet oder nur zwei bzw. 2x2 parallel? und hast du die federn in der mitte selber hergestellt?

Ich meinte auch gar nicht, dass du die NiboBee-Konstruktion nachbauen solltest (so gut, wie das aussieht, isses in Wirklichkeit nicht, weil die Fühler mit Drähtchen in die Platine gelötet sind, die bei jeder Betätigung in sich verdreht werden, irgendwann fällt das dann ab), aber du könntest anstelle des Kantholzes z.B. nen vorgebogenen Kabelbinder benutzen- der federt nämlich etwas.

Ja das Problem mit PWM und Billigst-Motörchen, kenn ich.
Da hilft es echt nur, den Regler so zu begrenzen, dass er nie unter eine gewisse Schwelle fallen kann- oder dann direkt auf "0".

Ich bau mir da immer Konstrukte wie diesen ein:

if((berechnetePwm < mindestWert)&& (berechnetePWM>0))
{
pwm=mindestWert+1)
}
Dirty, aber zuverlässig.

Zitat:

---

.. ich will möglichst keine auskragungen an der karroserie ..

---

Kein Problem. Ich habe in mehreren Threads meine Versuche mit selbst gebauten Reflexlichtschranken beschrieben. Die bestehen a) aus einer gepulsten UND gewobbelten (ge-CIRP-ten) IR-Sendediode passender Wellenlänge und b) einem IR-Empfänger SFH5110 (ähnlich TSOPxxxx), siehe hier (klick). Damit fährt mein MiniD0 prächtig rum. Hier die große Schwester vom MiniD0, Dottie bei der autonomen Fahrt die auch MiniD0 beherrscht.

Zitat:

---

.. meine größte baustelle .. die motoren .. erst ab 50 duty cycle auf touren ..

---

Das ist (bei meinen Gefährten) normal. Das kann der Regler ab, wenn man ihm Zeilen beibringt in der Art: wenn 0 < sollPWM < 50 dann sollPWM = 50 usf.

Verständnisfrage: wofür ist die abfrage, ob 0<pwm-wert ist wichtig?

frage in meinem von waste abgekupferten reglercode lediglich ab, ob motor_speed (pwm duty) kleiner min._speed (bei mir ca. 100 bei 255 periodendauer) ist. wenn der speed darunter fällt bleibt das entsprechende rad stehen und der bot dreht sich im kreis...

pulsdauer von 0 muss ich auf jeden fall vermeiden, da ein wert von 0 bei der c-control nicht zulässig ist und dazu führt, dass die pulsdauer auf 255 gesetzt wird. das war nämlich auch eine der Macken in meiner steuerung.

würde es aus eurer erfahrung heraus was bringen, wenn ich den motor aktiv abbremse durch kurzschluss am l293d?

das zwischenschalten eines kondensators in der versorgungsspannung für den motor hat schon mal was gebracht. allerdings fährt der bot nun gefühlt langsamer als vorher. ist das aus elektrischer sicht logisch?

würde es was bringen die motoren zu tauschen? liebäugle schon länger mit gehackten servos. aber dazu müsste ich dann auch neue radencoder installieren...

Zitat:

---

Zitat von Schmirk

sind da eigtl. alle 4 taster beschaltet oder nur zwei bzw. 2x2 parallel? und hast du die federn in der mitte selber hergestellt?

---

Aktuell 2x2 parallel. Eine höhere Auflösung, also jeder Taster einzeln, kann später aber eventuell noch kommen.
Die Federn sind aus versilbertem Messing Basteldraht selbst gewickelt und gebogen.
So kann man die schön an die jeweiligen Abmessungen anpassen (je nachdem wie man sich die Schalter baut).
Ich habe die Federn so gebogen, daß schon eine leichte Vorspannung auf die Taster vorhanden ist.

Ja, das mit Kindern Arbeiten ist nicht ganz einfach.
Eigentlich war geplant in der ersten Januarwoche weiterzumachen.
Aber ab dem 24ten waren alle anderen Spielzeuge wichtiger.
Ostern konnte ich dann nicht. Jetzt ist Pfingsten geplant um weiterzumachen.

Für den Probot könnte ich mir als Bumper auch eine Schürze wie beim MIT Rugwarrior vorstellen.
Runde, ziemlich zylindrische, Plastikschüssel die etwas größer ist als der Probot, Boden raussägen und ggf. den Rand nacharbeiten.
3 Löcher alle 120° am Umfang bohren und mit Hosengummies am Probot befestigen dann 3 Taster alle 120° am Probot (aber 60° versetzt zu den Hosengumies) anbringen.
damit hat man einen Bumper der einmal rundum geht und 6 verschiedene Kontaktzonen erkennen kann.

Zusammen mit deiner mechanischen Stosstange wiederum, hm. Probiers halt mal.
Aber pass auf, dass du dir dabei nicht die Getriebe schrottest-diese Zahnräder sind zwar nicht schlecht, aber nicht grade unverwüstlich.

Bessere Motoren bedeutet nen Totalumbau oder: ne Kiste dieser Spielzeugmotoren aus allen möglichen Quellen zusammenkaufen, und dann zwei "bessere" raus sortieren. die Dinger sind so billig, dass keiner nen ersthaftes Datenblatt für hat, und die gibts auch in diversen Varianten.
Es lohnt nich so wirklich....
Und mal ehrlich: braucht man wirklich 255 Fahrstufen?
Die meisten meiner Modellflug-Regler haben die nicht mal annähernd.

Also meine Stoßstangen-Konstruktion sieht zwar ganz gut aus und federt einen aufprall auch schön ab, jedoch werden die taster nicht zuverlässig ausgelöst. hab das iwie schon befürchtet.

das bumper-konzept vom rugwarrior find ich ziemlich gut. würde aber bedeuten, dass ich entweder die haube jedesmal abnehmen müsste, um an die taster zu kommen und diverse ausschnitte für die sensoren bräuchte oder ich muss alles auslöten und mit steckverbindern direkt an der karroserie installieren. beides keine schöne vorstellung, da aufwendig... aber generell für später denkbar.

die gefühlte verlangsamung der motoren kam durch zu niedrige akkuspannung. letzte nacht erstmal aufgeladen.

habe in einem artikel zur drehzahlregelung beim ct-bot gelesen, dass die dort einfach drei geschwindigkeiten (slow,normal,fast) vorgeben und die PID werte je nachdem differieren. das problem habe ich auch festgestellt. werte die bei langsamer fahrt gut regeln sind für vollgas ungeeignet und umgekehrt. werde wohl meinen code versuchen umzuschreiben.

zum einen will ich die regelung per timer-isr aufrufen und zum anderen nur drei grundgeschwindigkeiten zulassen mit entsprechenden PID-werten.

bei den neuen motoren dachte ich wenn halt an baugleiche, jedoch keine noname, sondern z.b. igarashi oder motraxx tuning motoren vom großen C.

mir würde es erstmal reichen, wenn der bot überhaupt einigermaßen geradeaus fährt. dieses festbeißen an einem thema ohne nennenswerte besserung führt bei mir dazu, dass ich iwann die lust verliere und andere baustellen stillstehen. bin leider nicht so ein crack wie z.b. waste der sprungantworten misst und den regler im simulator parametrieren kann. allerdings geht mir dieses empirische verfahren langsam auf den s***. besser, besser, besser aber nicht gut, schlechter, voll daneben.... :)

PID-Regler richtig justieren erforderd Geduld, wenn man keiner der genannten Cracks ist. ;)
Bin ich auch nicht.
Gibt da aber nen Trick: bastele mal vorübergehend drei Potis ran, und lies die von deinem Bordrecher aus- damit verstellst du zur Laufzeit einfach mal P, I und D und guckst, was passiert.
Falls du keine entsprechenden Eingänge frei haben solltest, leg mal was anderes dafür _vorübergehend_ lahm, das erleichtert die Sache extrem!
Fang mit P an-mit P alleine sollte die Regelung bereits halbwegs funktionieren, I kommt später (damit reagiert sie dann scheinbar schneller), und zuletzt kannst du Feintuning mit D betreiben.
Versuch trotzdem, gleich drei Potis _irgendwie_ ran zu bekommen, denn jeder Parameter beeinflusst die anderen auch wieder.
Mit der Methode hast du die Parameter in ner halben Stunde grob raus.

Ob es qualitativ hochwertigere Motoren in _dieser_ Bauform (weiss nicht, wie die genau im Probot verbaut sind, ob da "ähnlich" auch geht) gibt, weiss ich nicht, ich hab ne ganze Menge kleinerer, aber wesentlich besserer Motoren aus dem Modellbau da- keiner von denen würde wirklich passen ohne etliche Bastelei. Das hatte ich mir beim kleinen Lamborghini schon angesehen- zu viel Aufwand (und obendrein fraglich, ob das Ding mit mehr als der doppelten Leistung noch kontrollierbar wär, die Reifen taugen auch nix).
Wenn du welche bekommst, wieso nicht.
Bessere Motoren können nich schaden. Pass aber auf den Stromverbrauch auf, ich schätze, die Motorsteller wirst du nicht soo einfach tauschen können (wobei man die Dinger u.U huckepack aufdoppeln kann, hab ich auch schon mal gemacht).

gut das du es sagst!

das mit dem einstellen während der laufzeit hatte ich schonmal begonnen.
hab dazu einen fest verbauten taster an einem interrupt so programmiert, dass er einen der werte hochzählt bei tastendruck. hat aber durch das prellen des tasters und bis dato in ermangelung einer anzeige dazu geführt, dass ich nie genau wusste, welcher wert tatsächlich eingestellt ist. habe mir damals mit den 4 leds auf der mittleren platine und ner case abfrage eine 4 bit binär anzeige programmiert. da für den d anteil aber meist höhere werte gefragt sind und - wie du grad bestätigt hast - ein wert den anderen beeinflusst, bin ich damit nicht zum ziel gekommen.

deinem vorschlag folgend probiere ich nun folgendes in code umzusetzen:
1. endlosschleife für gradeaus fahrt
2. timer isr abfrage, ob einer der bumpertaster gedrückt ist. muss das dann wohl softwaremäßig entprellen.
3. button interrupt

mit dem button kann ich dann zwischen pid und geschwindigkeit wechseln.
mit bumper links jeweiliger wert -1 und bei geschwindigkeit -10
bumper rechts werte erhöhen

und das ganze gebe ich auf dem lcd aus. könnte auch noch error und die errechneten regelwerte bzw. den speed links und rechts anzeigen lassen. fürchte aber das dadurch die regelung ohne diese zusätzlichen aufgaben wieder anders reagiert...

- - - Aktualisiert - - -

werde auch nochmal den ansatz mit der drehzahlregelung testen. aktuell macht mein code folgendes:

funktion (strecke, drehung, speed)

encoder ticks für strecke in cm oder drehung in grad berechnen, z.b. 3500 ticks für 3m geradeaus.

schleife bis (ticks links+ticks rechts)/2=ticks strecke

error=ticks links-ticks rechts

d.h. beide motoren werden über eine größe geregelt. komme ohne last (aufgebockt) so auch bis auf wenige ticks bei beiden encodern an den ticks strecke wert. unter last im fahrbetrieb sieht das aber wieder ganz anders aus...

mit einer drehzahlregelung, die die soll-ticks pro geschwigkeit mit den ist-ticks vergleicht, könnte ich beide motoren unabhängig voneinander regeln bis die strecken ticks erreicht sind.

wie macht denn eun oberallgeier das bei seinen autonomen dosen? steht bedtimmt auch iwo im thread aber bin grad zu faul zum suchen ;-)

Der heutige Tag endet mit der Erkenntnis:

Ich hab zwar keine Lösung aber ich bewundere das Problem...

Habe die oben beschriebene Funktion zur Einstellung folgender Werte und Ausgabe über das LCD zum laufen gekriegt:

P, I, D Werte
Startspeed
Delay (nach Abarbeitung der Reglerfunktion)
Strecke in cm

Am Ende kann ich nun mit den voreingestellten Werten per Druck auf den linker oder rechten Bumper mit den voreingestellren Werten die entsprechende Strecke vorwärts oder rückwärts fahren.

Nach Beendigung der Fahrt zeigt mir das LCD außerdem diese Werte:

-berechnete Soll-Encoderticks gem. Strecke

-durchschnittliche IST-Encoderticks berechnet aus (Encoderticks links+rechts)/2

-IST-Encoderticks links und rechts

-Abweichung von IST-Encoderticks links und rechts zu SOLL-Encoderticks als Absolut- und Prozentwert.

Hat sich insofern schon mal gelohnt, als dass ich dabei viel gelernt habe im Hinblick auf eine spätere Menüführung über das LCD (Case Abfragen, Variablen als Flags setzen um das LCD zu löschen, Ausgabe von Variablen auf dem LCD etc.)

Allerdings bin ich bei der Einstellung der PID-Parameter nun mehr als ratlos und muss wohl meinen Reglercode bzw. die Radencoder in Frage stellen. Folgende (paradoxe) Entdeckung hab ich nämlich gemacht:

Das Delay habe ich testweise auf 0 gelassen. D.h. wenn die Regelschleife abgearbeitet ist, fängt sie direkt wieder von vorne an.

PID-Werte=0
Abweichung zwischen SOLL und IST-Ticks (links bzw. rechts) beträgt laut Auswertung bei 200cm Strecke und Vollspeed grade mal +0,04%, auch unter Last.
Allerdings fährt der bot eine Bananengrade...

PID-Werte ungleich 0
Sobald ich beginne die Reglerwerte hochzufahren entsteht bei den linken IST-Ticks eine gemessene Abweichung von +3 bis 10%.
Bei den rechten IST-Ticks verhält es sich anders herum, hier ist die Abweichung -3 bis 6%.
Jedoch fährt der Bot unter Last nun mehr oder weniger grade.

Sobald ich den I-Anteil erhöhe fängt der Bot an immer kleinere Kreise zu drehen. Das bedeutet doch eigtl. das der I-Anteil immer größer wird und der Regler dadurch übersteuert?

Hat jmd. einen Tipp für mich, wo ich mit der fehlersuche beginnen sollte?

Werde die Tage mal meinen Reglercode von "Altlasten" befreien und hier posten. Hoffe irgendwo steckt einfach nur ein dummer Denk- oder Programmierfehler der hier direkt jmd. ins Auge sticht... :-/

I ist der Integral-Anteil.
Der tut-erst mal nichts, ausser beobachten.
Tut sich eine Abweichung auf, dann schaut er auf die Uhr und, je länger die Sache nicht behoben wurde, umso stärker greift er ein.
Daher wirkt I auch immer erst verzögert, bei den heutigen Rechengeschwindigkeiten merkt man das allerdings nicht.

Meiner Meinung nach braucht man für so nen Roboterchen zum geradeaus-fahren lange keinen PID-Regler. Selbst ein Bogen mit, sagen wir, nem Meter Raduis dürft sich auch so beizeiten ausgleichen lassen. Ganz perfekt kann es ohnehin nicht gehen, da du dann nicht nur die encoder-Ticks zählen kannst (was ist nämlich in der Zwischenzeit?), sondern echt eben auch noch die Zeiten zwischen den Ticks möglichst genau messen müsstest.
Und auch dann gibts noch Abweichungen: lass eins der Räder nen paar Millimeter mehr Umfang haben, als das andere (nix neues bei Billigrädern, wie sie überall verbaut werden), schon nutzen die Encoder überhaupt nichts mehr-die können das nämlich gar nicht erkennen.
Dazu müsste man dann schon was unabhängiges haben-Kompass, Gyroskop oder so.
Wenn dein Roboter immer in die selbe Richtung abhaut, dann würd ich im übrigen mal in genau die Richtung schauen: mechanische Ungenauigkeiten. Eventuell verpasst einfach einer der Encoder hin und wieder nen Tick?

Und: du sagst, mit I-Anteil fährt er ne Spirale: bist du sicher, dass die Regelung richtig herum regelt?
Sowas kann nämlich tatsächlich "kippen"- dann kann auch falsch rum gesteuert werden (durch Übersteuern z.B).
Das _kann_ durchaus extrem werden- bei meinem Mini-Segway war das mal so schlimm, dass ich das Ding mit den Händen nicht mehr halten konnte.

das mit der mechanischen ungenauigkeit ist auf jeden fall ein teil des problems. die räder sind mit einem ring an der achse befestigt. ein paar millimeter mehr oder weniger spiel und schon läuft das eine rad tlw. nicht mehr an. weiterhin muss ich die encoderscheiben nochmal überarbeiten. die cny70 "schleifen" nach und nach die markierung ab.

Beim Reglercode muss ich mur meine Variablen nichmal genau anschauen. nicht, dass dort eine überläuft oder die falschen vorzeichen hat.
dabei fällt mir ein: hab gestern den übergabeparameter für den speed an die funktion von integer ( mit vorzeichen) zu byte (OHNE vorzeichen) geändert. ich depp... war nochmal den ganzen code durchgegangen und hab mir gedacht: der speed kann ja sowieso nur 0-255 annehmen. wird aber glaub ich intern auch als regelvariable verwendet. vlt. denk ich aber grad auch nur falsch, weil meine neuronen noch kein koffein bekommen haben. heute abend mal schauen.

Hm-kann man das Ding aufrüsten?
Dir scheint ja eine Menge dran zu liegen, dass er wirklich präzise geradeaus fährt.
Da würd ich kurzerhand nen Gyroskop hinzufügen. Damit sind mechanische Unzulänglichkeiten Geschichte. Ist nämlich so: wenn sich eins der Räder minimal weiter aussen als das andere befindet, kannst du das mit reiner Drehzahlmessung _nicht_ mehr ausregeln, spätestens Kurven werden dann immer schief.
Wenn du nen I2C-Bus hast, wäre ne MPU 6050 preiswert zu haben- die tut den Job, und hat zudem noch ein Acclerometer drauf- kann man auch immer mal brauchen.