Fortbewegungsstrategie gesucht

[Moppi]

Hallo an alle,

ich bin am überlegen, wie mein Roboter fahren soll. Ich dachte jetzt, ich frage einfach mal hier nach. Es haben doch schon etliche Leute was gebaut, das auch fährt. Ich weiß noch nicht, welches die beste Strategie ist, könnte ich alles ausprobieren, aber vielleicht kann ich durch Eure Antworten etwas Zeit sparen.

Ich sehe zwei Möglichkeiten, aber vielleicht gibt es auch mehr:

1. der Roboter fährt so vor sich hin und nebenbei wird gemessen und die Richtung dann korrigiert. Also z.B.: zu naher an linker Wand, fahre weiter nach rechts rüber. Wenn der Roboter immer kontinuierlich voran fährt, müssen Echtzeitmessungen garantiert sein. Da dürfen keine längeren Pausen auftreten, sonst fährt er irgendwo gegen.

2. Der Roboter fährt ein Stück des Weges, von dem durch die vorherigen Messungen klar ist, dass der frei sein sollte. Stößt er an ein Hindernis -> Unterbrechung. Ist er die Teilstrecke gefahren, hält er an, orientiert sich neu und fährt die nächste Teilstrecke.

Mit Fortbewegungstechniken, in die auch das Vermessen der Umgebung integriert ist, muss ich mich beschäftigen. Noch nie gemacht. Wie werden Roboter (wie Staubsauger) normalerweise gesteuert, dort hat sich doch bestimmt ein Verfahren etabliert? Oder was verwendet Ihr, welche Vor- und Nachteile gibt es?


Danke schon mal, im Voraus!

Gruß
Moppi

[Rabenauge]

...kommt drauf an.
Wenn du nen Roboter willst, der mehr oder weniger "nutzlos" spazieren fährt, brauchst du weder ne Planung noch grosse Berechnungen.
Die machen die Fahrt sogar eher hakeliger.
Da reicht es, wenn du drei Sensoren hast (oder vier, dann is hinten eben auch noch einer).
Du kannst dann die Strategie benutzen: je höher das Signal vom linken Sensor ist, desto mehr wird nach rechts ausgewichen.
Das geht nahezu ganz ohne rechnen: je näher die linke Wand, desto mehr wird die PWM auf dem rechten Rad reduziert.

Zusätzlich könnte man sich solche Events merken ("links war eben ne Wand"), dann hat man eine Entscheidungshilfe für den Fall, dass vorne ein Hindernis auftaucht (" da drehen wir wahrscheinlich besser nach rechts").
Hier kann man aber auch Zufallszahlen zu Hilfe nehmen, oder aber auch mal anhalten, und mit den Langstrecken-Sensoren weiter schauen.

Bei dieser Methode muss man aber einiges abfangen: beispielsweise ist es oft nicht gut, die PWM auf einem Rad so weit zu reduzieren, dass es stehen bleibt- ggf. einfach generell nur "dreiviertel Gas" geben, damit man Reserve hat zum drehen (PWM rechts runter, links hoch).
Man kann auch beispielsweise die Länge des Signals "Wand links" mit einbeziehen, je länger dieses Signal da ist, umso mehr wird gedreht....

Im allgemeinen gibt die Methode ein schönes, weiches fahren, kann aber nicht alles handlen (z.B. in ne Sackgasse fahren).

[Moppi]

Ich wollte eventuell das "hakelige" etwas kompensieren. US-Messungen während der Fahrt werden wahrscheinlich eher ungenau, während sie im Stillstand ausgeführt sehr genau sein können; bspw. wenn einfach nach vorne auf eine Wand hin gemessen wird. Dazu fällt mir aber gerade selbst ein, dass ich u.U. keine genaue Messung benötige, sondern eventuell nur Grenzwerte und dass nur angehalten werden muss, wenn die Situation unklar ist und genauer geschaut werden muss.

Oder ich fange mit dem hakeligen Herangehen an, um erst einmal die Funktion hin zu bekommen. Später könnte ich das optimieren.

MfG

[Gerdchen]

Mir würde sowas wie ne Art "Missionsplanung" vorschweben (also nix religiöses ). Soll heißen, der Hauptrechner bekommt seine jeweiligen Missionsdaten von einem wechselbaren Speicher. Die Grundfunktionen, Sensorik, Bewegungsalgorithmen u.s.w. sind ja im "Kleinhirn" des Roboters implementiert. So ähnlich wird das auch im militärischen Bereich bei autonomen Drohnen gehandhabt.

[Moppi]

Grundfunktionen, Sensorik, Bewegungsalgorithmen

Genau da bin ich gerade dabei. Ich habe erst die Firmware drauf und die Oberfläche, um die Programme aufbauen zu können.
Als nächstes habe ich den IR-Sensor angeschlossen. Dafür brauch ich eine Funktion in der Firmware und dann geht es damit erst einmal weiter.

Ich habe keinen Staubsaugerroboter, dass ich den mal eine Weile beobachten könnte.
Wenn man fertige Roboter kauft, dann ist die Struktur schon vorhanden. Also irgendwie fährt und navigiert das Teil dann schon. Ich habe noch keine Struktur dafür.

Gruß

[oberallgeier]

.. Fortbewegungstechniken, in die auch das Vermessen der Umgebung integriert ist .. Noch nie gemacht ..

(M)Eine Lösungsmöglichkeit:
WALL R - als Geschwindigkeitstester für MiniD0
3 Sensoren, IR-Reflexlichtschranken, siehe hier und ausführlich in "Chirpen"
......vorn-li, vorn-re und rechts-unter-Beifahrersitz
Sensorabfragen reihum, mit wenigen 100 Hz (Durchläufen)
Zielabstand von der Wand rund 30 cm bis 40 cm
Geschwindigkeit nimmt stetig ab unter ca 50 cm (siehe Video)
......über 90 cm v=max (GibGummiStatus), ca. 1,5 m/s
Lenkeinschlag meist NICHT gerade aus,
leicht rechts über 50 cm, drunter zunehmend links
......mit sinkendem Wandabstand
Notlösung: Stillstand und GERADE ca 10 cm zurück, war nie erforderlich

[inka]

Ich habe keinen Staubsaugerroboter, dass ich den mal eine Weile beobachten könnte.
Wenn man fertige Roboter kauft, dann ist die Struktur schon vorhanden. Also irgendwie fährt und navigiert das Teil dann schon. Ich habe noch keine Struktur dafür.

mein Staubsaugerroboter dreht sich erstmal um die achse und macht mit dem lidar eine karte (kann man abrufen auf dem smartphone), dann teilt er den raum in teile, je nach grösse, dann fährt er die einzelnen teile nacheinander ab, erstmal den umfang, dann in regelmässigen linien von rechts nach links usw...
Es gibt aber auch roboter, die fahren das zimmer "chaotisch" ab...

[Moppi]

Hallo!


Holomino hatte im andern Thread auch schon mit so was ähnlichem geantwortet. Er macht das auch von Ereignissen abhängig.
Mir schwebt noch was anderes vor. Bei einer Lösung fährt der Roboter eine Strecke und hält an (oder wird angehalten - Hindernis), misst und kontrolliert die Position und / oder Pose, berechnet den neuen Wegabschnitt und dann fährt er weiter. Ich weiß noch nicht, ob ich bei bestimmten Messmethoden (wie US) brauchbare Messungen bekomme, wenn alles in Bewegung ist. Aber ich will mal davon ausgehen, dass das irgendwie machbar ist. Auf eine bestimmte Strecke müssen alle Messungen ausgeführt werden können, sonst wäre der Roboter zu schnell. Wenn ich dies so annehme, kann er doch immer in Bewegung sein, solange die Messungen und Berechnungen in einer bestimmten Zeit durchgeführt werden können. Dann kann ich den also in Bewegung lassen und während dessen einen neuen Pfad berechnen lassen, gleichzeitig müsste ich eine Voraussage treffen, wo der Roboter sein wird, wenn die Berechnungen fertig sind (ist klar, weil er ab dem Punkt einen neuen Pfad befährt und diesen Punkt muss ich für die Berechnungen als "Abzweig" annehmen). Sind die Berechnungen fertig, wartet man noch so lange, bis die berechnete theoretische Position erreicht ist (3cm in Fahrtrichtung bspw.) und dann bekommt der neue Kommandos. So könnte er fahren, messen und berechnen gleichzeitig.


Also ich weiß nicht, ob ich es durchsichtig erklärt habe. Aber so in etwa sollte es funktionieren können. Damit er flüssig fährt. Zwischenstopps treten dann auf, wenn Unerwartetes passiert (angestoßen, Räder drehen durch, Anstieg zu steil ....).


Jetzt habe ich erst mal die dösige IR-Diode eingebunden. Inka weiß noch, dass die mit den Fernbedienungen nicht so gut funktionieren (verlorene Codes, Fremdlicht usw.) Aber ich glaube, zurzeit habe ich eine brauchbare Lösung dafür gebastelt.


Ich denke, ich werde einen Ablaufdiagramm machen müssen, für die Steuerung (PAP). Damit ich später noch den Durchblick behalte.
Jetzt probiere ich noch ein wenig rum, will den wenigsten mal mit einer Fernbedienung steuern können. Etwas spielen muss ja auch mal drin sein. Natürlich nur, wegen dem Dazulernen...


Besten Dank!
Moppi

[Rabenauge]

Woher nimmst du denn das Ziel?
Ich meine-Wegplanung setzt ja voraus, dass es einen Zielpunkt gibt, der erreicht werden soll?

Flüssig fahren geht schon-dann aber dynamisch. Das Beispiel mit der Wand hatte ich ja schon, aber das geht nach vorne auch: US-Sensor nur grob abfragen. Solange da anderthalb Meter (das natürlich anpassen an die tatsächlichen Fähigkeiten des Roboters) frei ist, gibts keinen Grund, mit genaueren Messungen herumzutrödeln.
Erst, wenn es enger wird, mal vom Gas gehen, und genauer hinsehen...das lässt sich immernoch auf wenige Zeilen _einfachen_ Code eindampfen.
Beobachte dich mal, wenn du durch die Wohnung gehst- du schaust auch nich in jede Ecke, wenn du vom Bad zur Küche willst.
Du schaust nur grob, ob der Weg frei ist...alles links und rechts bekommst du eigentlich kaum mit, weil es gar nich wichtig ist.

[Moppi]

Es geht um die Fortbewegung, wie es im Titel steht. Nicht die Zielsuche. Das ist ein anderes Thema. Und auch die Wegplanung betrachte ich noch nicht. Jetzt gerade habe ich das Chassis pausenlos im Kreis fahren lassen - "hakelig". Da ist jetzt eine recht große Pause zwischen zwei Bewegungsabschnitten. Muss mal schauen, wie ich den Programmablauf gestalte. Jetzt (ujm überhaupt irgendwo anzufangen) warte ich, bis eine Bewegung beendet ist, dann kommen paar Programmteile dazwischen (Pause) und dann fährt es weiter im Kreis. Ich muss jetzt anfangen so zu denken, dass ich die Dinge parallel ausführe (der ESP-12E hat hier zurzeit noch nichts zu tun, außer dass der Programmpakete in seine Umwelt verteilt). Jetzt ist das alles noch etwas unbeholfen, weil es noch ganz am Anfang steht. Da sind noch nicht mal US-Wandler dran oder Bumper ... nichts. Ich muss sehen, wie ich mit den Ausführungszeiten zurechtkomme. Muss immer eins nach dem andern.

MfG