Linie Folgen

[oberallgeier]

Hallo Sportsfreund,

Und? Was nutzt mir nun der y wert in hinblick auf die beiden Motoren? ...

Also um es mal ätzend trocken zu sagen: im Hinblick auf beide Motoren nutzt es nix.

Sieh Dir bitte (noch mal) das Bild oben an (ich will nicht den Thread mit ein und demselbem Bild zumüllen). Dieses Bild gilt nur für einen Motor. Und "das y" ist eben - nur für einen Motor. Der Regler sorgt dafür, dass die von Dir vorgegebene Geschwindigkeit dieses einen Motors eingehalten wird, egal ob der Motor ne schlechte Tagesform hat (Reibung u.ä.), ob der Untergrund "schlechter läuft" und ob die Versorgungsspannung höher oder niedriger ist (in Grenzen). Ein "y" für einen Motor. Deshalb habe ich auch eine erweiterte Bezeichnung, schau mal in meinen Code. Dort gibt es das "iy12" - das ist für den Motor 12, für den Motor 34 habe ich ein anderes y, das heisst dann iy34 - klar!. 12 bzw. 34 heißt das bei mir wegen des Motorcontrollers - das regelt eben z.B. die Ausgänge 12 des Controllers. Der Buchstabe i ist für mich eine Kennung dafür, dass das ein ganzzahliger Wert (integer) ist.

... dann kommt ein links Knick ...

Dann musst Du den entsprechenden Vorgabewert ändern. Schau bitte wieder ins Bild: dort ist das die Führungsgrösse "w" bzw. der Sollwert. Du änderst für den entstprechenden Motor, also nur für einen, die Vorgabe: entweder langsamer oder schneller, je nach Deiner Systemplanung. Bei mir heisst der Vorgabewert stupsi12 - Soll Timer Units Per Sensor Interrupt 12 - weil die Anzahl der timer units von einem Interrupt des Encoders bis zum nächsten ein Mass für die Motordrehzahl ist: je weniger timer units desto schneller dreht sich der Motor. Bei mir ist eine dieser Zeiteinheiten 50 µs lang. Sie wird sehr präzise in einer gesonderten ISR (Interrupt Service Routine) bereitgestellt.

Und ich kümmere mich nur um die Vorgabe - der Regler kümmert sich darum, dass der Motor diese Vorgabe erfüllt. Natürlich gibt es für jeden Motor eine gesonderte Regelungsroutine. Die laufen bei mir zwar im gleichen Rhythmus, aber zu unterschiedlichen Zeiten, sprich versetzt. Das liegt daran, dass ich diese Interuptroutinen sehr kurz halte, damit ich keine Schwierigkeiten mit anderen ISR bekomme. Aber das ist ein anderes Thema .

Ist das so klarer?

[BlackDevil]

Hey

Da sind doch direkt ein paar unklarheiten aufgetaucht und gelöst worden:
1. Habe ich deinen Code aufgrund der Variablennamen nicht richtig Verstanden
2. Habe ich die ganze Zeit den Code von seiner "Funktion" her misverstanden, ich dachte der sei ebenfalls zum Linienfolgen, aber er regelt lediglich einen Motor - das dieser IMMER die gleiche Geschwindigkeit fährt.
3. Wenn ich stupsi12/34 durch meinen Sensorwert ersetze, habe ich rein vom Prinzip her meinen Linienfolger, seh ich das richtig? Denn immer wenn mein Wert abweicht wird gegen geregelt. Nee irgendwie finde ich noch nich so ganz den Draht zwischen "Motor rechts langsamer drehen wenn eine Linkskurve kommt" und dem w bzw Sensorwert

Grüße

[oberallgeier]

... 1. Habe ich deinen Code aufgrund der Variablennamen nicht richtig Verstanden ...

Das liegt an mir, sorry, oder daran, dass Regelungstechnik nicht allzu einfach ist.

... 2. Habe ich die ganze Zeit den Code von seiner "Funktion" her misverstanden, ich dachte der sei ebenfalls zum Linienfolgen ...

Hmmm, ich hatte über Regelung aber nur deshalb geschrieben, weil

PD oder PID Algorithmus sagt mir relativ wenig aber der scheint zum Regeln ... gut zu sein ...

Macht ja nix. Jetzt scheint es Dir ja klar zu sein, dass Regelung der Geschwindigkeit und Linienfolgen nicht ein und dasselbe Ding sind.

... aber er regelt lediglich einen Motor - das dieser IMMER die gleiche Geschwindigkeit fährt.

Jein. "Der Code" oder besser gesagt "die Regelung" führt dazu, dass der Motor eine vorgegebene Drehzahl einhält. Die kann ich zu beliebigen Zeiten variieren. Korrekt müsste es also heissen: "... dass dieser IMMER die vorgegeben Geschwindigkeit einhält..."

(Nicht zum Lesen gedacht: Dies gilt nur im Rahmen der Betriebsgrenzen und der Zulässigkeit der Vorgaben. Wird eine zu hohe oder eine zu niedrige Geschwindigkeit vorgegeben, bekommt der Motor auch mit "Regelungscode" Probleme. Klar. Wer mit dem Auto oder Moped halbes Schritttempo fahren möchte, muss die Kupplung schleifen lassen, da reicht es nicht, das Gas wegzunehmen - dies ist nur ein ungefähres Beispiel, weil die Regelung hier vom Fahrer her gemacht wird - der kennt die Vorgabe und regelt mit Gasgeben die Geschwindigkeit.)

Es kann aber auch eine genügend langsame Geschwindigkeit vorgegeben werden und trotzdem funktioniert es nicht - weil z.B. die Steigung zu gross ist oder die Spannung des Akkus zu niedrig usf.

Stimmen aber die Betriebsgrenzen, dann kannst Du Dich darauf verlassen, dass Deine Vorgaben eingehalten werden. Genau dafür - und nur dafür - sorgt der Regelalgorithmus. Und warum soll das nützlich sein? Weil so die Bewegung doch "berechenbarer" wird. Ich weiß zum Beispiel, dass bei einer bestimmten Vorgabe (meines) "stupsi"-Wertes mein Gefährt eben 50 mm/sec fährt und nicht 51, 52 oder 49 und bei einem anderen Wert entsprechend anders. UND es fährt auch jedes einzelne Rad entsprechend gleich wie das andere => das Gefährt fährt bolzengeradeaus ! ! ! >>> Und ich musst mich dabei nicht darum kümmern, welchen genauen PWM-Wert ich für jeden einzelnen der beiden Motoren benötige - das macht der Regler "von alleine". Warum? Eben wegen dieser Regelungsschleife in der genannten Skizze oben. <<<

... 3. Wenn ich stupsi12/34 durch meinen Sensorwert ersetze, habe ich rein vom Prinzip her meinen Linienfolger, seh ich das richtig? ...

Na ja, ich wills nicht zu sehr ausbreiten aber wir müssen jetzt schonc mal unterscheiden.

A) Du braucht zum Linienfolgen keine Regelung wie oben beschrieben. Wie gesagt - die kam ins Spiel wegen Deiner Aussage . . . siehe oben. Es ist sicher möglich, die beiden Motoren (die PWM´s für den Motorcontroller) direkt aufgrund der Abweichungen vom "Soll" anzusteuern. Dies könnte so ungefähr wie folgt aussehen:

. Sensor .| PWM |PWM
. 1 bis 5 .| links |rechts
0 0 1 0 0 | 120 | 120 . . . . . . . Gib Gummi, gib Gummi . . . .
0 1 1 0 0 | 110 | 120 . . . . . . . Fahrzeug weicht leicht rechts ab oder Kurve li beginnt, li Motor langsamer als re => zieht nach links
0 1 0 0 0 | 080 | 100 . . . . . . . Stärkere Abweichung re od. Kurve links , insgesamt langsamer und linker Motor langsamer als rechts
1 1 0 0 0 | 070 | 100 . . . . . . . Aktion oben reichte nicht, links noch langsamer
1 0 0 0 0 | 060 | 100 . . . . . . . Aktion oben reichte nicht, links noch langsamer
...
0 0 0 1 1 | 100 | 070 . . . . . . . sinngemäß wie oben, aber Rechtskurve
...
Dies ist aber, genaugenommen, auch eine Regelung, denn es wird mit Rücksicht auf die Größe der Abweichung immer stärker gegengesteuert. Aber dies ist eben kein konventioneller Regler (der wäre hier auch möglich, aber dann müsste ich ein paar Stunden drüberhocken - und es ist ja Dein Problem).

B) Du kannst die oben genannten PWM-Werte durch konkrete Geschwindigkeitsvorgaben od. ä. (z.B. wie meine stupsi12/~34 - Werte) ersetzen. Dann werden eben die Vorgaben genauer befolgt. Und wozu soll das jetzt gut sein? Du könntest durch entsprechende Geschwindigkeitswerte (Vorgaben ähnlich wie oben für die li/re PWM) einfach ausrechnen, welche Geschwindigkeit Du für die beiden Räder bei welchem Kurvenradius vorgeben musst. Damit könntest Du vielleicht bei einem vorgegebenen Parcours sicherer auf die Abweichungen reagieren. Ein wesentlicher Vorteil, besonders bei langen Geraden wird es sein, dass das Gefährt besser geradeausfährt - weil eben die Geschwindigkeit der Räder geregelt wird - und der Regler - siehe oben - ohne mein Zutun die erforderlichen PWM-Werte ausrechnet. Dies ist im Beispiel A) nicht der Fall ! ! !


Ich vermute, dass ich in so einem Fall aber eher die erste Variante nehmen würde - ohne Regelung der Motordrehzahl oder -Geschwindigkeit mit einem der PD- oder PID-Algorithmus. Wenns so funktioniert - - - - -

... Denn immer wenn mein Wert abweicht wird gegen geregelt. Nee irgendwie finde ich noch nich so ganz den Draht zwischen "Motor rechts langsamer drehen wenn eine Linkskurve kommt" und dem w bzw Sensorwert ...

Da hast Du das richtige Gespür! Du musst bei der "Regelung" entsprechend der Abweichung vom Sensormuster, siehe oben, den Sollwert w einstellen. Du musst also den Werte w vorgeben. Getrennt für jeden Motor! Ähnlich wie die obere PWM-Liste.

Ich hoffe, dass dies jetzt verständlicher ist.

[BlackDevil]

Aaaaaaaaaaaaaaaaaaaaah jetzt ist der Groschen gefallen! Aber nicht in den Gulli

Wir haben die ganze Zeit ein wenig aneinander vorbeigeredet, ein wenig zumindest, und ich hatte einen Denkfehler.

Der Übergang zwischen Linie und keine Linie ist - logischerweise wie ic hfinde, nicht fliesend, sondern "abrupt", mehr oder weniger.

Dann dachte ich die ganze Zeit schon - wozu den Regelalgo. wenn es auch mit 1en und 0en geht.

Das heist: Ich leg mir eine art Tabelle zurecht in der ich die w-Sollwerte vorgebe. Gerade aus, leichte Abweichung, Starke Abweichung, Verfluchte Abweichung, Apokalypsische Abweichung und entsprechend mit der Vorgabe die PID-Algorithmen für die Motoren Füttern.

So hätte ich das die ganze Zeit auch gemacht, nur hatte ich die Diskussion die ganze Zeit so verstanden, dass der Algo. dafür gedacht ist, dass ich der Linie folge und nicht einfach nur die Geschwindigkeitsvorgabe einhalte.

Das heist:
- Linie "messen" und "Digitalisieren
- Drehzahl der beiden Motoren messen
- Gemessene, Digitalisierte Linie mit "Regeltabell" abgleichen
-- Entsprechend den Motoren einen neuen Sollwert vorgeben
-- Den Sollwert möglichst exakt mit PID versuchen einzuzhalten (PWM)

[oberallgeier]

Hi, BlackDevil

Aaaaaaaaaaaaaaaaaaaaah jetzt ist der Groschen gefallen! ...

Prima, dann ist unsere Mühe nicht vergeblich gewesen.

... Der Übergang zwischen Linie und keine Linie ist - logischerweise wie ic hfinde, nicht fliesend, sondern "abrupt", mehr oder weniger ...
- Linie "messen" und "Digitalisieren

Die Linie ist "mehr oder weniger abrupt". Das kommt darauf, an, welche Sensoren Du verwendest. Ein analoger Sensor wird eben ein analoges Signal ausgeben, und ein digitaler ein digitales. Also je nachdem, wie Du die Sache hardwaremässig anlegst!

... Das heist:
...
- Drehzahl der beiden Motoren messen
- Gemessene, Digitalisierte Linie mit "Regeltabell" abgleichen
-- Entsprechend den Motoren einen neuen Sollwert vorgeben
-- Den Sollwert möglichst exakt mit PID versuchen einzuzhalten (PWM)

Du musst Dich noch an diese Art von Programmierung gewöhnen! Die Verwendung von Interruptroutinen lässt Programme "im Hintergrund" laufen.

WENN Du eine interruptgetriebene Regelung hast, dann musst Du - um bei meinem obigen digialen Beispiel zu bleiben - die Linie beobachten und entsprechend dem Bit-Muster der Sensoren aus einer im Programm enthaltenen Tabelle zwei Sollwerte für Mot-li und Mot-re vorgeben.

Daneben laufen (bei mir) vier interruptgetriebene Routinen.

INT0 und ~1 wird aufgerufen, wenn der Encoder0 bzw. ~1 eine Unterbrechung meldet (weil der Motor eine Umdrehung gemacht hat). D.h. diese Routinen sind ereignisgesteuert. Die Routine stellt für den jeweiligen Motor den aktuellen Zeitwert fest und subtrahiert ihn von dem alten Zeitwert. Ergebnis: der Zeitbedarf für die Motorumdrehung.

Die Regelroutinen für Mot12 und Mot34 laufen zeitgesteuert durch einen entsprechenden Timer - bei mir im Takt von rund 400 Hz (das wird bei der Gesamtplanung eben in einem sinnvollen Raster festgelegt - und auch mit Rücksicht darauf, was grad verfügbar ist!). Diese Routinen gucken nach dem aktuellen Zeitbedarf und nach Deiner Vorgabe (wenn Du Drehzahlen ausgerechnet hast eben nach diesen). Dann wird entsprechend dem obenstehenden Bild verfahren - und "die Regelung" rechnet einen aktuellen PWM-Wert für den jeweiligen Motor aus.

Du - bzw. das sogenannte eigentliche Programm hat damit dann nichts mehr am Hut!

Wie Du das Ganze ohne Interrupts realisierst, steht im vorherigen Posting.

Ich glaube, dass wir das jetzt genug durchgehechelt haben. Wenn Du noch Fragen hast, dann arbeite mal den Abschnitt Regelungstechnik durch - siehe mein Link - und programmiere Dir so etwas. So im Trockenen ist es einfach - trocken.

Viel Glück und Adieu.

[BlackDevil]

Ach Diskussionen sin doch Super. Wir haben nur aneinander vorbeigeredet.

Ich werd mir jetz die Tage einfach mal Sensoren und kram kaufen und versuchen ins Studi Labor zu kommen und Testen.

Danke soweit

[BlackDevil]

Ich hab mal was kleines in C++ geschrieben um den Spaß zu Simulieren und zu versuchen es zu versthen:

#include <iostream>
#include "..\GITFrameworkW32.h"


using namespace std;

int main()
{
	int esum=0;
	int ist[6]={9,10,8,1,15,20};
	int e;
	int y;
	int Kp=5;
	int Ki=5;
	int Kd=5;
	int Ta=5;
	int soll=15;
	int ealt=0;

	for(int i=0;i<6;i++){
	e=soll-ist[i];
	esum += e;
	y=Kp*e+Ki*Ta*esum+Kd*Kd*(e-ealt)/Ta;
	ealt = e;

	git_printf("Soll Wert: %i\r\nIst Wert: %i\r\nRegel Wert: %i\r\n\r\n", soll, ist[i], y);

	}
return 0;
}

An dem GIT Kram nicht stören, das ist eine Oberfläche von der Hochschule, so ein kleines nettes Fenster das man nich immer in der Konsole arbeitet.

Ausgabe ist:

Soll Wert: 15
Ist Wert: 9
Abweichung: 6
Regel Wert: 210

Soll Wert: 15
Ist Wert: 10
Abweichung: 5
Regel Wert: 295

Soll Wert: 15
Ist Wert: 8
Abweichung: 7
Regel Wert: 495

Soll Wert: 15
Ist Wert: 1
Abweichung: 14
Regel Wert: 905

Soll Wert: 15
Ist Wert: 15
Abweichung: 0
Regel Wert: 730

Soll Wert: 15
Ist Wert: 20
Abweichung: -5
Regel Wert: 625

Wie interpretier ich das jetzt auf mein PWM Signal? Würde ich den spaß auf 8 bit begrenzen würde er ja immer 100% fahren Oder wo ist der denkfehler?


Edit: Mir fällt grad ein das Kd Ki etc. ausschlaggebend für den Regler sind und ich die willkürlich zum test auf 5 gelegt hab, das kann logischerweise Variieren. Das tu ich gerade mal

Edit2: Bzw wie stell ich den Spaß so ein das ein Sinnvoller PWM wert bei y herrauskommt (den ich ja ggf. Nach oben und unten je nach Bitbreite des Timers begrenzen kann)? Oder liegt der wurm noch wo anders? Ich bin bei "Ist" von einer Drehzahl ausgegangen die von einem Sensor kommt

[BlackDevil]

Niemand mehr? Das obige Schwingt ja noch, das muss man Korrigieren, das ist klar, aber wie Interpretier ich dieses allgemein?