Fortbewegungsstrategie gesucht

[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

[muell-er]

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 ..

Der Titel ist allgemein gehalten. Aber dir es geht um nur deine Strategie. Es gibt viel andere Strategie und nicht jede ist immer richtig. Und ich versuch meist möglichst das ganze Umfeld zu betrachten - sonst klappts eben nicht.

[Moppi]

Wie und wann der Roboter was tun soll, ist (noch) nicht festgelegt, selbst, wenn ich Vorstellungen habe, wie es in etwa funktionieren könnte. Das sollte aus meinem ersten Beitrag hervorgegangen sein.

Und da es viele Möglichkeiten gibt, wollte ich gerne einen Einblick haben, was sich bei den Usern so etabliert hat, die sich hier damit auch beschäftigen.

Wenn ich denke, dass ich aus den Beiträgen für mich was ableiten kann (und ich lese die sehr sorgfältig, jeden Einzelnen) oder wenn mir bei Lesen weitere Sachen einfallen oder ich dann sogar erst einmal eine Lösung zu haben meine, die auf mein Projekt passt (weil die technisch umsetzbar ist), dann schreibe ich diese meine Vorstellung hier mit hin. Ja, das ist dann "meine Strategie".

Ob meine Strategie richtiger als eine andere ist, kann und soll gerne weiter diskutiert werden, genau so, wie jeder andere Beitrag dazu.

Gruß
Moppi