Archiv verlassen und diese Seite im Standarddesign anzeigen : Virtueller Bot [KINEMATIKMODELL]
Hallo,
weil mich die Regeltechnik interessiert, aber ich keine Ahnung davon hab, musste ich mir jetzt eine virtuelle Experimentierplattform basteln.
Als erstes hab ich eine Bahnsteuerung programmiert. Es wird ein vierrädriges Fahrgestell simuliert mit einer Trapezlenkung. Das Ziel ist, in dieser ersten Aufgabe, einer Linie zu folgen. Das ist ja eine leichte Aufgabe. Aber für mich war es recht aufschlussreich, mit Algorithmen und Parametern zu experimentieren.
http://i4.ytimg.com/vi/oAYmpLgOi0M/default.jpg
VIDEO (http://www.youtube.com/watch?v=oAYmpLgOi0M)
grüsse,
Hannes
Hallo Hannes,
sehr schöne Idee mit der virtuellen Reglerstrecke.
Kannst du bitte etwas mehr über die Hindergründe erzählen. Also zB mit was du programmiert hast und welche Ereignisse du behandelst um den Regler zu füttern?
Mich würde mal interessieren warum er bei Kreuzungen nicht einfach mal abbiegt ;-)
sast
Hallo sast,
da kann ich gern mehr drüber schreiben:
Programmiert hab ich das in Object Pascal, sprich Delphi.
Das ganze soll im Lauf der Zeit noch andere Aufgaben bekommen und für die Aufgaben dann auch unterschiedliche Algorithmen.
Der gerade implementierte Algo fragt nur periodisch ab, was das Fahrzeug unter 2 Testpunkten hat. Es werden sozusagen 2 optische Liniensensoren simuliert. Die liegen ca einen halben Achsabstand vor der gelenkten Vorderachse und sind mit dem Fahrgestell verbunden. Sie passen knapp in den Leitstreifen hinein, wenn das Fahrzeug ausgerichtet ist.
Ist ein Sensor draussen, wird um eine Stufe in die andere Richtung gelenkt. Sind beide drinnen,wird um eine Stufe Richtung Neutralstellung gelenkt. Die letzte Vorschrift ist wichtig, damit das Ding nicht übersteuert und wie besoffen herumeiert. Als nächste wird dann noch eine Vorschrift für beide Sensoren draussen hinzugefügt.
Für die Einfachheit lenkt der Algo doch recht geschmeidig und weich. Interessant ist, dass da 3 Stufen für jede Seite ausreichen. -36,-24,-12,0,12,24,36 Grad Lenkausschlag beispielsweise. Wichtig ist aber das häufige Abfragen, und das rechtzeitige Neutralstellen der Lenkung. Hier frage ich die Sensoren ab und lenke nach, wenn er die Wegstrecke von einem Pixelabstand zurückgelegt hat.
Das Reagieren auf die Kreuzungen, hast sicher gesehen: Vorausgesetzt, das Fahrzeug ist ausgerichtet, beeinflusst die Kreuzung die Fahrt überhaupt nicht. Es setzt ja nur für eine kurze Strecke die seitliche Führung aus. Bei der Kreuzung rechts oben, von oben kommend, ist das Fahrzeug nach der Kurvenfahrt noch nicht ganz gerade ausgerichtet. Drum fährt es leicht schräg auf die Kreuzung zu und richtet sich erst aus, wenn die Sensoren die Kreuzug überquert haben.
Am besten gefällt mir an dem Miniprojekt, dass man so schnell zwischendurch was testen kann.
grüsse,
Hannes
Hi Hannes,
sieht sehr gut aus, aber eine wichtige Sache fehlt glaube ich... Im Mom. ist es wahrscheinlich so, dass zu jedem Zeitpunkt zu dem sich das Fahrzeug bewegt auch die Sensoren abgefragt werden. Das wird in der Realität leider nie so sein. Probier doch mal was passiert wenn dein Fahrzeug sich die ganze Zeit bewegt, die Sensoren aber nur alle 10ms abgefragt werden. Oder füge mal ein bisschen Rauschen hinzu, das macht die Optimierung noch viel spannender ;-D
Hi William,
das wird dann nochmal so spannend. Rauschen gehört unbedingt dazu, sonst bleibt das alles zu theoretisch. Die Sensoren gehören mit Rauschen beaufschlagt, aber das Fahrzeug selbst auch.
Bei der Videoaufnahme habe ich bei der langsamsten Fahrstufe alle 40ms abgefragt, und bei der schnellsten alle 7 ms. Ich werde testen, was sich tut, wenn ich seltener abfrage.
Interessant, da tun sich echt vielversprechende Perspektiven auf. Ob DAS ein Miniprojekt bleibt?
grüsse,
Hannes
jcrypter
13.08.2009, 14:45
Ein sehr interessantes Projekt!
Wie ich deine Projekte kenne wird es bestimmt auch nicht so "mini" bleiben :)
Kannst du ein bisschen was zur Umsetzung in Object Pascal sagen?
Also konkreter auf die Programmierung eingehen, Quelltextauszüge evtl.?
Wie hast du das ganze gelöst? Objektorientiert?
Danke für dieses schöne Projekt :)
edit:
Du hast je mehrere Einzelprojekte die sich mit der Steuerung von Fahrzeugen unterschiedlicher Art befassen, hast du vor daraus mal ein "großes" Projekt zu machen?
Crypi
Danke erst mal für die Erklärungen.
Um es realistischer zu machen, könntest du zB aber sicher noch Massenträgheit und Verarbeitungszeit (nicht so häufige Abfrage) mit einrechnen.
Wenn du bei 1 Sensor draussen nur um eine Stufe nachregelst, wann kommen denn dann überhaupt die anderen Stufen ins Spiel? Da hab ich irgend wie noch eine Verständnislücke. Wäre schön wenn du die noch schließen könntest.
Bei der Kreuzungsquerung wollen wir mal hoffen, das kein Sturm von der Seite drückt [-o< . Da kann man sicher noch viel zusammenspinnen an Störgrößen. Dafür ist so eine Simulation hervorragend geeignet.
Vielleicht kannst du ja auch mal ein Bild deiner Gesamtapplikation zeigen. Wie man da Parameter ändern kann usw. Mir würde da noch einfallen, dass man beliebig Störer auf die Strecke setzt und denen bestimmte Eigenschaften mitgibt. Einer könnte zB ganz helles Gelb verschütten, was eine Sichtverschlechterung der Sensoren bedeutet und und und...
Tja ich schweife ab, sorry.
Als konkrete Frage noch, wie hast du die Sensor-Daten-Aufnahme gestaltet? Kann man da eine beliebige Strecke zeichnen. Ist doch sicher ein Canvas auf dem ein Rechteck rumwackelt. Wäre interessant zu sehen wie das Fahrzeug bei zu dünner Leitlinie gebändigt werden kann.
sast
Hallo,
das ist ja ein Menge von Anregungen und Ideen! Super, danke!
@ Programmierung:
Im ersten Anlauf ist bei mir sowas nicht wirklich objektorientiert, sondern prozedural geschrieben. Aber die Aufteilung der Aufgaben in Prozeduren hat schon eine Struktur, dass es dann nur ein formales Überarbeiten ist, um aus den Prozeduren ein Objekt Fahrzeug zu erstellen.
So ist die Source auch nicht sehenswert. Zudem bin ich nur ein Hobbyist.
Mein Interesse liegt mehr bei den Algorithmen und der Diskussion darüber.
Da beantworte ich konkrete Fragen gerne auch mal genauer.
@ Andere Fahrzeuge:
Das was ich mir hier mit dem Simulator erarbeite, soll in die realen Fahrzeuge einfliessen.Das Landfahrzeug soll eine verbesserte Bahnsteuerung bekommen. Und beim Solarboot weiss ich noch überhaupt nicht, wie das Regelverhalten sein wird. Der Autopilot funktioniert am Trockenen, aber das Verhalten des Geamtsystems in der Zeit kenne ich noch nicht. Das werd ich mir anschauen und dann Verbesserungen simulieren.
@Trägheit:
für so kleine Spielzeugfahrzeuge auf dem Land spielt die Trägheit meistens kaum eine Rolle, wohl aber beim Schifferl. Da wird das ganz wichtig sein.
@Zeit:
bei jedem Update ist definiert, wieviel Zeit vergangen ist. Das ist voll berücksichtigt. Entsprechend der vergangenen Zeit, der Geschwindigkeit und dem Lenkwinkel wird die Translation oder Rotation berechnet.
@Mehr Stufen:
Wenn der rechte Sensor vom Leitstreifen geraten ist, lenke ich um eine Stufe nach links. Wenn beim nächsten Update der Sensor immer noch draussen ist, dann lenke ich eine weitere Stufe nach links, wenn er aber schon wieder auf dem Streifen ist, lenke ich eine Stufe zur Mitte. Und so weiter.
@Seitenwind:
Bei Fahrzeugen, die mit dem Algo fahren, gibt es keinen Seitenwind. Bei Fahrzeugen, für die Seitenwind relevant ist, muss man sich was besseres einfallen lassen. Aber jetzt ganz im Ernst: für die Kreuzungen der Pfade mit sich selbst könnte man den Bereich in der Mitte intensiver einfärben. Ohne viel Änderung in der Verarbeitung könnte man ohne Aussetzer in der Führung über diese Kreuzungen fahren. Bei Kreuzungen vollständig unterschiedlicher Pfade könnte man unterschiedliche Farben für die Wege und Mischfarben auf den Kreuzungen verwenden. Durch Filten der Farbbits, tritt dann die Kreuzung gar nicht in Erscheinung.
@Ansicht der Applikation:
Da gibts noch nicht viel zu sehen. So lange noch am Code gearbeitet wird, ändere ich Parameter als Konstanten im Code. Wenn der Code in diesem Bereich stabiler wird, dann lege ich die Steuerung auf die Oberfläche. Das wird jetzt für Maximalausschlag und Inkrement der Lenkung gerade gemacht. Während der Entwicklung sind immer auch jede Menge obsoleter Steuerinstrumente zu sehen, mit denen getestet wurde, und die noch nicht beseitigt wurden.
@Sensordatenaufnahme:
Das Ganze sind 2 Images übereinander liegend. Ins untere ist das Bild mit dem Pfad, Hindernissen, usw. geladen. Das darüber liegende hat einen transparenten Hintergrund. Da übermale ich das alte Rechteck weiss und das Rechteck an der neuen Position wird schwarz gemalt. Was unter den Sensoren liegt, das wird im Pfadbild nachgesehen. Und schon gleitet das Fahrzeug elegant über die virtuelle Landschaft. (Nix wackeln ;) :) 8) )
grüsse,
Hannes
Hihi, sowas ähnliches hab ich vor vielen Jahren auchmal geschrieben: https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11934 (nicht mehr alle Links aktuell..[und ich hab nichtmal geantwortet..schlimm schlimm ;) ])
Wie hast du das mit den Schnittpunkten gelöst? Hat das Gefährt eine Art Dynamik, oder gibt es ein internes Abbild der Spur?
Hallo äh,
ist ja auch eine gute Idee, soetwas zu simulieren. Hast du Animationen auf Video? Da könnte man gut den Einachser mit dem Zweiachser vergleichen.
Der Umgang mit den Schnittpunkten ist weiter oben im Thread beschrieben. Die Kreuzungen dienen nur dazu, einen längeren Testkurs unter zu bringen, drum hab ich da nichts besonderes ausgearbeitet, sie funktionieren recht gut.
Was meinst du mit Dynamik und innere Spur? Weiter oben steht, wie die Lenkung und der Algo gestaltet sind. Daraus ergibt sich das Verhalten. Auch wie die Sollspur vorgegeben wird, ist beschrieben.
Hi all,
Den Algo hab ich noch weiter ausgearbeitet. Der Lenkausschlag ist jetzt proportional zur Geschwindigkeit. Wenn mehr Zeit vergangen ist, muss ich grössere Fehler ausregeln können Wenn wenig Zeit vergangen ist, dann sollen sich die Steueraktivitäten auch nicht zu starkt aufsummieren.
Zusätzlich hab ich, wie geplant eine Regel eingefügt, die nach Verlassen der Spur mit BEIDEN Sensoren für einen sinnvollen Lenkausschlag zurück sorgt. Es wird auf die Seite gelenkt, wo zuletzt der Leitstreifen gesehen wurde. Wieder zunehmend bis zum Volleinschlag.
Bei der folgenden Demo habe ich das provoziert, damit man es gut sieht. Der Lenkeinschlag wurde auf 30° begrenzt, was für 2 Kurven deutlich zuwenig ist.
http://i1.ytimg.com/vi/4aTh4w9SoZY/default.jpg
VIDEO (http://www.youtube.com/watch?v=4aTh4w9SoZY)
grüsse,
Hannes
Gefällt mir sehr gut!
Könnte man, in der Grafik für das Fahrzeug,
noch die Lage der beiden Sensoren darstellen?
GeoBot
Hallo Geo,
die Lage der Sensoren ist oben beschrieben. Eine automatisierte grafische Dokumentation wird bei Bedarf später implementiert.
Hallo alle,
zum vorigen Video gibt es noch die Dokumentation der IST Spur:
http://www.jbergsmann.at/Trace-3max.gif
bei jeder Runde wurde der Lenkeinschlag auf einen anderen Wert begrenzt.
NEUER ALGORITHMUS
Nachdem ich mir die heftigen Lenkbewegungen angesehen habe, dachte ich mir, das muss ja so nicht sein und habe einen neuen Algo verwendet. Jetzt werden die Sensoren mit der Lenkung geschwenkt. Wieder liegen sie ca. einen halben Achsabstand vor der Vorderachse.
Das führte dazu, dass die Kreuzungen nicht mehr zuverlässig überfahren wurden. Das hat man also davon, wenn man seinen Bot zur Seite sehen lässt. Naja, da hab ich eben, die oben bereits diskutierte Variante umgesetzt, und die funktioniert wieder gut.
Dann erwies sich das System mit den mit geschwenkten Sensoren als weitaus besser als das mit starren Sensoren. Die Lenkausschläge sind kleiner, gleichmässiger und das Fahrzeug folgt dem Soll Streifen perfekt:
http://i1.ytimg.com/vi/0Ot_jskPdRI/default.jpg
VIDEO (http://www.youtube.com/watch?v=0Ot_jskPdRI)
Das sieht man auch an der dokumentierten Ist Spur:
http://www.jbergsmann.at/Trace-algo2.gif
grüsse,
Hannes
icebreaker
14.08.2009, 14:19
Mach mal in deine Strecke nen rechten Winkel rein das erhöht dann noch den Schwierigkeitsgrad
Hallo Lukas,
das wäre auf mehrere Arten leicht zu lösen, Hast du auch schon eine Idee dazu? Wie würdest du das lösen?
grüsse,
Hannes
icebreaker
14.08.2009, 15:17
Ich weiß es nicht genau warschenlich mit 4 Sensoren. Und wenn dann die Sensoren ganz außen sagen das sie eine Line sehen soll der so doll einschlagen wie es geht.
oder gibts noch ne lösung ohne zusätzliche Sensoren??
Und was passiert mit vier Sensoren an einer
Kreuzung? Links voll einschlagen - rechts voll
einschlagen - Je nach Winkel der sich
kreuzenden Linien wird dann abgebogen?
Aber die Frage mit dem rechten Winkel ist GUT.
Was passiert wenn der Wagen wirklich längs der
Linie fährt und beide Sensoren gleichzeitig keinen
Strich mehr sehen.
Dann weis er bei zwei Sensoren nicht ob es links
oder rechts weitergeht. Oder?
GeoBot
Doch, das weiss er. Schau die Viedeos an, man sieht das. Oben ist auch beschrieben, warum er das weiss.
Ich hatte das so verstanden :
Verlässt ein Sensor die Linie wird gegegesteuert.
Verlassen beide Sensoren die Linie, wird in die
Richtung weiter gegengesteuert, in die gegenge-
steuert wurde, als der erste Sensor die Linie verließ.
Die Frage die sich bei dem rechten Winkel stellt,
(rein hypothetisch versteht sich :-) ), was passiert
wenn beide Sensoren wirklich gleichzeitig den Strich
verlieren.
Geht es dann links oder rechts herum? Oder habe
ich eine Regel übersehen?
Hallo Geo,
jetzt versteh ich die Frage besser. Der rechte Winkel ist nicht vorgesehen, darum gibt es auch keine Regel dafür. Das ist ja ein 2Achser mit beschränktem Einschlagswinkel. Da macht es keinen Sinn eine Leitlinie mit Haken vorzugeben.
grüsse,
Hannes
In dem Fall sollte man die Entscheidung entweder dem "Zufall" oder dem Programm überlassen. Oder der Kontrollfetischist gibt einfach eine Richtung vor in der gesucht wird. Behandeln sollte man das auf jeden Fall.
sast
icebreaker
14.08.2009, 21:47
Nee man kann es mit 3 Sensoren regeln die dann im Dreieck angeordnet sind eine Ganz vorne Eine andere weiter hinten links und eine auch weiter hinten rechts und wenn der vordere Sensor sagt das er keine Linie mehr sieht wird dann voll in die Richtung gelenkt in die die Linie hingeht (Das sagen dann die Sensoren Weiter hinten) .
Ich hoffe ich bring euch nicht komplett durcheinander^^
Hallo,
zurück zum gegenwärtigen Thema: Linienverfolgung ohne Ecken und Haken.
Der Algo, den ich gerade untersuche kennt die Richtung der Linie nicht und steuert doch recht vernünftig. Warum er das macht, erkennt man, wenn man sich die 7 Zustände ansieht, die berücksichtigt werden.
http://www.jbergsmann.at/8-Kurs.GIF
Man erkennt, welche Farbe zu welchem Zustand gehört.
grüsse,
Hannes
Hast du Animationen auf Video? Da könnte man gut den Einachser mit dem Zweiachser vergleichen.
Nein, aber der Download geht ja noch. Bei einem speziellen Video wär das auch nur beschränkt vergleichbar. So könntest du sogar deine Linie mal in mein Programm einbauen, wenn du willst. ;)
Der Umgang mit den Schnittpunkten ist weiter oben im Thread beschrieben.
Da hab ich wohl etwas zu schnell gelesen :)
Na da bleib ich doch lieber bei meinem Thema.
http://www.jbergsmann.at/8-Trace-Angle.GIF
Jetzt sieht man an der Breite der Ist Spur den jeweils aktuellen Lenkeinschlag.
Die Fahrt beginnt ganz rechts mit Richtung nach oben.
grüsse,
Hannes
Hallo,
jetzt möchte ich einen ganz anderen Algo vorstellen. Bisher habe ich mich an den Lienienverfolgern orientiert. Das ist von der Spurerkennung sehr einfach, da nur 2 Testpunkte untersucht werden. Die resultierende Bahn ist auch recht ruhig und zielführend, aber wenn man sich anschaut, wie da hin und her gelenkt werden muss, dann ist das Verfahren doch nicht so elegant.
Der neue Algo funktioniert wie die Deichsel von einem Handwagen: In einem Abstand vor der Vorderachse, der ungefähr dem Achsabstand entspricht, wird festgestellt, wo genau die Soll Spur liegt. Die Räder werden in diese Richtung gestellt. Das Fahrzeug folgt dadurch sehr ruhig der Spur. Es werden keine unnötigen Lenkbewegungen mehr ausgeführt.
So sieht mal die erste Animation aus:
http://i2.ytimg.com/vi/Yr30TPMIMDY/default.jpg
VIDEO (http://www.youtube.com/watch?v=Yr30TPMIMDY)
Die Kreuzung hab ich diesmal ganz anders gelöst. Das Fahrzeug bleibt einfach auf der farbigen Spur und ignoriert andere Farben. Nur eine graue Spur wird zu Koppeln verwendet.
grüsse,
Hannes
Um denn Algo jetzt beurteilen zukönnen, habe ich diesmal bei 2 verschiedenen Updatefrequenzen die Lenkausschläge grafisch protokolliert.
Zuerst mit hoher Updatefrequenz: 1 Update pro 1 Pixel Wegstrecke.
http://www.jbergsmann.at/Drawbar01-Highspeed.gif
Die hellen Farben im Hintergrund zeigen die Soll Spur, die dunklen Farben im Vordergrund zeigen die Ist Spur. Die Breite zeigt den Lenkausschlag. Schaut gut aus, aber bei der Frequenz ist das keine schwierige Aufgabe.
Darum hab ich die Updatefrequenz auf ein mal pro 30 Pixel Wegstrecke herabgesetzt:
http://www.jbergsmann.at/Drawbar01-Lowspeed.gif
Und das schaut auch nicht wesentlich anders aus. Man sieht deutlich die selteneren Updates und die grösseren Korrekturen. Der maximale Lenkausschlag musste grösser sein um diese Korrekturen auch zu ermöglichen.
grüsse,
Hannes
Hallo,
nachdem der Deichselalgo so zufriedenstellend funktioniert, hab ich die Bewegung der Deichsel am Fahrzeug noch animiert. Und das Fahrzeug bewegt sich auf einem Kurs mit vielen Kreuzungen.
http://i1.ytimg.com/vi/h2oD9hybaQ0/default.jpg
Fürs Video bitte das Bild anklicken (http://www.youtube.com/watch?v=h2oD9hybaQ0)
grüsse,
Hannes
nachdem der Deichselalgo so zufriedenstellend funktioniert, hab ich die Bewegung der Deichsel am Fahrzeug noch animiert. Und das Fahrzeug bewegt sich auf einem Kurs mit vielen Kreuzungen.
Finde ich sehr interessant, wie verschiedene Regealgorithmen, Fahrzeuge usw. virtualisierst und die Ergebnisse anschaulich darstellst.
Wenn dein virtualisierter Linienfolger die verschiedenen Farben der Strecke auswertes, hast du den Kreuzungen allerdings das was ihren Schwierigsgrad bei der Linienerkennung ausmacht genommen.
Hallo Hannes,
kannst du mal eine Legende zu den einzelnen Zuständen anlegen? Dann lässt es sich besser nachvollziehen.
Danke
sast
Edit: Hab wieder mal ganz verpennt, dass es schon eine 2. Seite gibt. Meine Frage bezieht sich noch auf die erste Seite
... hast du den Kreuzungen allerdings das was ihren Schwierigsgrad bei der Linienerkennung ausmacht genommen.
Hi,
genau das war meine Absicht. Die Anwendung ist das Fahren nach einer Karte oder das Fahren nach auf dem Boden aufgemalten Linien bei Transportaufgaben. Das Fahren nach einer Karte macht mein Landfahrzeug schon hier: https://www.roboternetz.de/phpBB2/viewtopic.php?p=433275#433275 Das werde ich im Winter verfeinern und jetzt hab ich mal zwischendurch die Simulation geschrieben.
Der Vorteil liegt weniger im geringeren Schwierigkeitsgrad der Kreuzungen, sondern in der Stabilität der Linienverfolgung auf Kreuzungen. Selbst wenn unmittelbar vor der Kreuzung die Spur verloren wurde, wird die richtige Ausfahrt wieder gefunden.
Die Orientierung im Labyrinth ist eine ähnliche, aber grundsätzlich andere Aufgabe.
grüsse,
Hannes
So,
eigentlich wollte ich Pause machen, aber ich war zu neugiereig. Jetzt habe ich die Updatefrequenz weiter herabgesetzt: 1Update pro 50pix Wegstrecke.
Eine Verbesserung wurde als notwendig erkannt und durchgeführt:
Wenn die Spur kurz mal veloren ist, dann wird mit gleichem Lenkwinkel weiter gefahren, wenn das über mehr als 10 Pixels Wegstrecke der Fall ist, dann wird der Maximalwinkel verwendet, in die Richtung des alten Lenkwinkels.
Das Ergebnis ist erstaunlich gut:
http://www.jbergsmann.at/reorientierung.gif
blau = Spur verloren
grüsse,
Hannes
Hallo,
das Gute an einem Simulator ist bekanntlich das einfache Testen. Bei einem realen Fahrzeug wär die Testerei schon zu aufwändig geworden, aber so wars einfach, noch weiter zu gehen. Also hab ich am Algo gearbeitet, um die Updatefrequenz herab setzen zu können. Die gezeigte Linie verbindet die Lage des Fahrzeugmittelpunkts bei den Updates. Das Fahrzeug bewegt sich aber im Allgemeinen auf Kreisbogen zwischen den Updates.
http://www.jbergsmann.at/extrem.gif
Das geht beim vorliegenden Testkurs bis zum Updaten nach jeweils einer Fahrtstrecke von 2.5 Achsabständen zuverlässig.
Wenn man öfter Updatet, dann schauts so aus:
http://www.jbergsmann.at/Stabil.gif
Der Algorithmus kennt Form und Richtung der Linie nicht. Das wäre zu aufwändig. Es wird nur entlang einer 2x geknickten Linie abgetastet, ob der Leitstreifen zu finden ist. Wenn er gefunden ist, wird zum Schnittpunkt hin gelenkt. Wenn der Winkel über dem Maximum der Lenkung liegt, wird eben bis zum Maximaleinschlag gelenkt.
http://www.jbergsmann.at/algodemo.GIF
Damit man das gut sieht, habe ich den Lenkwinkel auf 20° begrenzt. Ein Verlieren der Spur ist nicht mehr Vorgesehen. Dafür gibts keine Lenkregel mehr, nur eine Fehlerbehandlungsregel.
Nebenbei hat sich ergeben, dass dieser Algorithmus von einem wendigen Fahrzeug auch auf einem Parcour mit Knicken gut verwendet werden kann.
grüsse,
Hannes
Kenny5020
19.08.2009, 14:35
Hi
Schönes Projekt. Was für eine Progrsmmiersprache nutzt du dafür?
Hast du dir schon mal den Bildsensor bei Pollin angesehn? (Best.Nr. 100 997 ). Wenn der schnell genug wär, dann würdest du ein besseres Regelverhalten bekommen, als diese hackelige 2-Punkt-Regelung.
Viel Spaß noch beim proggen.
Kenny
Hi Ken,
Danke für die Blumen.
Programmiersprache steht oben im Thread: Object Pascal.
Wie passt jetzt ein Bildsensor in einen Simulator?
Was erscheint dir hackelig?
Wo siehst du einen 2 Punktregler?
grüsse,
Hannes
Kenny5020
19.08.2009, 16:56
Hi
Wie passt jetzt ein Bildsensor in einen Simulator?
War nur als Anregung gedacht. Bei einer Simulation gehts ja auch immer um die Machbarkeit.
Was erscheint dir hackelig?
Das hin und her zwischen den 2 Punkten.
Wo siehst du einen 2 Punktregler?
Das ist von der Spurerkennung sehr einfach, da nur 2 Testpunkte untersucht werden. Die resultierende Bahn ist auch recht ruhig und zielführend
Wenn du nur 2 Punkte betrachtest, dann hast du ja praktisch nur einen 2-Punkt_regler. Ich seh grad, das du bei deiner letzten Simulation eh sowas wie einen Liniensensor eingebaut hast.
Kenny
Hi Ken,
da hast du einiges gründlich missverstanden. Ich versuchs nochmal zu erklären.
In eine Software werde ich wohl kaum Sensorhardware einbauen können. Wie du diese 'Anregung' meinst, ist nicht nachvollziebar.
Welches angebliche Hin und Her zwischen 2 Punkten du meinst, müsstest du schon hinschreiben. Der Bahnverlauf ist doch ruhig und und geschmeidig. Also ist das Regelverhalten fliessend und nicht 'hakelig'.
In diesem Thread wurden 2 Regler beschrieben und keiner davon ist ein Zweipunktregler. Schau dir im Wiki die 2 Punktregelung an, dort siehst du was das ist: Der hat 1 Sensor mit 2 Zuständen.
Hier im Tread der 1. Regler kennt 7 Zustände und nicht 2 wie der 2 Punktregler. Wenn du dir die Abläufe ansiehst, dann könntest du erkennen, wie die Integration die Verläufe noch weicher macht.
Und der 2 Regler der beschrieben ist, der arbeitet überhaupt kontinuierlich. Fliessender gehts ja nicht.
Wenn noch immer etwas unverständlich ist, bitte einfach konkrete Fragen zu stellen.
grüsse,
Hannes
Hallo,
zurück zum Algorithmus: durch die Optimierung hat der eine Fähigkeit erhalten, die gar nicht geplant war: Jetzt kann er um die Ecke Fahren.
http://www.jbergsmann.at/Squarepath.GIF
Hier sieht man 2 Kurvenscharen. Das sind die Spuren von 2 verschiedenen Fahrzeugen.
1. hoher Einschlagwinkel möglich (60°) und Liniensuche knapp vor der Vorderachse: Die Bahn schmiegt sich richtig in die Ecken der Leitlinie hinein.
2. mässiger Einschlagwinkel (bis 40°) und Liniensuche weiter voraus: Die Spur folgt etwas lockerer der Leitlinie, aber die Abweichung nach innen und nach aussen ist gut ausgeglichen. Es treten keine überschiessenden Relungen auf.
Der Algo scheint mir jetzt einmal gut geeignet als Verbesserung für mein bestehendes Fahrzeug.
Damit die Bahnregelung auch wirklich komfortabel in andere Programme einzufügen geht, schreibe ich gerade die Regelungsprozeduren in ein Regelungsobjekt um. Das ist aber recht wenig Aufwand vor Allem, wenn man den Nutzen in Rechnung stellt.
EDIT:
Die Hauptschleife im Programm, wo ursprünglich alles dringestanden ist, ist aufgeräumt. Hier der Teil mit Simulation, Linienerkennung und Steuerung:
uses unit2;
// ...
steer1:=tsteer.Create;
steer1.init(log,image1,imagemap,l,realedit(editmax ),realedit(editvoraus),realedit(editview));
// ...
// ...
getnewposition(newx,newy,neworient); // Simulate Movement
// ...
steer1.getlinepoint(newx,newy,neworient,xfound,yfo und,foundline);
if foundline then
begin
steer1.CalcAngle(xfound,yfound,newx,newy,neworient ,sa);
editsteering.text:=inttostr(round(sa));
end
else
editv.text:='0' // emergency stop
;
// ...
So einfach gestalten sich dann der Einbau und der Aufruf im Hauptprojekt: https://www.roboternetz.de/phpBB2/viewtopic.php?t=36497
Grüsse,
Hannes
Hallo,
Nachdem das Finden der Ansteuerpunkte auf der Leitlinie recht gut geht, hab ich mir nun die Regelung selbst vorgenommen. Bis jetzt habe ich einfach den Lenkwinkel auf den Ansteuerpunkt ausgerichtet. Das geht bei hoher Updatefrequenz perfekt wie das Ziehen eines Wagen mit Deichsel, aber nicht bei niedriger Updatefrequenz. Im letzteren Fall übersteuert dieser Algo fürchterlich.
Jetzt habe ich mit die Geometrie der Lenkungskinematik in die Regelung eingebaut. Da wird jetzt invers vom gewünschten Ansteuerungspunkt zum erforderlichen Lenkwinkel zurückgerechnet. Beide Varianten hab ich mal in ein Spurbild geplottet:
http://www.jbergsmann.at/Regelung-Modell-lenkung.GIF
Die Updatefrequenz liegt in beiden Fällen gleich niedrig: 1x alle 60 Pixels Wegstrecke (=1 Radstand).
Wenn man die Regelung ohne Modell bedämpft, indem man den Lenkeinschlag begrenzt wird das Verhalten zwar noch besser, aber doch nicht so gut, wie mit Modell. Bei der Regelung mit Modell ist die Winkelbegrenzung irrelvant. Bei starker Begrenzung wird die Istspur stark ausgerundet, aber sie ist in jedem fall glatt und variiert nicht von Runde zu Runde.
Jetzt beginne ich langsam das, was ich tue, zu verstehen. Interessant und erstaunlich ist es auch. Ich hoffe, die Berichte interessieren noch jemanden.
grüsse,
Hannes
Hi Hannes!
Ich hoffe, die Berichte interessieren noch jemanden.
Ich finde das sehr spannend und die Idee mit der "Deichsel" sehr gut. So wird der Sensor immer dort hin bewegt, wo sich mit hoher Wahrscheinlichkeit der Sollpfad befindet.
Allerdings geht es mir mit diesem Projekt so wie mit vielen anderen Projekten hier: Wenn ich es nicht selber mache, verstehe ich nur die Hälfte.
Moin Vohopri,
natürlich interessiert noch was du hier experimentierst. An Reglung kommt man nicht vorbei, wenn man sich für Roboter interessiert.
Schön ist auch, dass du mal etwas Code sehen lässt. Dadurch lässt sich dann das Ganze auch nachvollziehen. Vielleicht kannst du uns ja mal TSteer öffentlich machen, damit auch die ganzen Funktionen transparent werden.
Danke für deine Mühe
sast
Hi,
danke für das Echo.
@ Deichsel:
Beim jetzt verwendeten Algo zum Finden eines Punktes auf der Sollspur, bewegt sich der Sensor nicht mehr mit der gedachten Deichsel mit. Der Sensor ist ein Balken mit 2 Knicken. und ist fix mit dem Chassis verbunden. Der Abstand nach vorne ist minimal ein halber Radstand. Wenn schneller gefahren wird, dann schaut der Sensor bei jedem Update ungefähr so weit voraus, wie das Fahrzeug bis zum nächsten Update voraussichtlich fahren wird. Diese Abstimmung hat sehr viel gebracht.
http://www.jbergsmann.at/algodemo.GIF
Die graue Linie ist der Sensor.
@ Code:
Die Schnittstelle hab ich mal aufgeräumt und habe sie gezeigt. Im Inneren sieht es noch recht unübersichtlich aus. Darum wäre es recht nutzlos, darin lesen zu wollen.
Wenn bestimmte Funktionen interessieren, dann kann ich schon einen Teil aufräumen und meine Lösungen zeigen. Allerdings warne ich: Das ganze ist skalar programmiert und nicht vektoriell. Der Grund ist, dass ich vom CAD her die ebene Trigonometrie mit Skalaren gut beherrsche, aber bei Matritzen schon aussteige, weil ich sie mir nicht vorstellen kann.
grüsse,
Hannes
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.