Fortbewegungsstrategie gesucht

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

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

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

Mir würde sowas wie ne Art "Missionsplanung" vorschweben (also nix religiöses :pray:). 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.

Zitat:

---

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ß

Zitat:

---

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

Zitat:

---

Zitat von Moppi

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

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

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.

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

Zitat:

---

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.

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

Wenn ich DC-Motoren ansteuere, muss ich Werte in die PWM-Register schreiben. Das erzeugt in der Regel keinen Overhead. Das zyklische Regeln, also die Generierung der PWM-Werte sollte sicherlich zeitlich nicht den gesamten Zyklus beanspruchen. Wenn Du also alle 20ms einmal die PWM-Werte neu berechnest, dauert das in der Regel keine Millisekunde.

Wenn Du noch andere zeitkritische Operationen hast (der Interrupt eines US-Sensors riecht danach, aber auch die Bytes an der RxD-Leitung wollen bei 115kBaud alle 100µs abgeholt werden), würde ich Dir einen Controller mit mehreren Interruptprioritäten nahelegen. Das vereinfacht Vieles.

Letztlich nur eine Frage des Werkzeuges, was man parallel ohne Pausen in der Abarbeitung hinbekommt.

Zitat:

---

Zitat von Holomino

Wenn ich DC-Motoren ansteuere, muss ich Werte in die PWM-Register schreiben. Das erzeugt in der Regel keinen Overhead. Das zyklische Regeln, also die Generierung der PWM-Werte sollte sicherlich zeitlich nicht den gesamten Zyklus beanspruchen. Wenn Du also alle 20ms einmal die PWM-Werte neu berechnest, dauert das in der Regel keine Millisekunde.

---

Bei den AVR-Controllern z.B. läuft eine PWM ja einmal angestoßen hardwaremäßig im Hintergrund, ohne das Hauptprogramm zu belasten. Neue PWM-Registerwerte brauche ich eigentlich nur bei Drehzahländerung.

Ja, also laufend, weil die Drehzahlregelung ist ja eine Regelung. Sie regelt den Ist- zum Sollwert aus.

Zitat:

---

Zitat von Holomino

Ja, also laufend, weil die Drehzahlregelung ist ja eine Regelung. Sie regelt den Ist- zum Sollwert aus.

---

Stimmt natürlich. Eventuell wäre eine Auslagerung dieser Regelung in einen separaten "Antriebscontroller" sinnvoll. Der kümmert sich dann nur um die Belange des Fahrwerks.

Die Interruptgeschichte, was Holomino meint, spielt sich bei mir, wenn, dann (für das Fahrwerk) auf unterster Ebene ab. Ich habe drei Ebenen. Die AVRs für die Echtzeitsteuerung der Räder (Encoder auslesen, Motor steuern, auf Ereignisse mit Stillstand reagieren). Die zweite Ebende ist auch ein AVR, der soll Berechnungen anstellen, wie die einzelnen Räder zu steuern sind (also welche Daten die untergeordnete Ebene bekommt) und kann auch auf Ereignisse von außen reagieren; aber vor allem auf Ereignisse der Ebene drunter (also direkt von den Antriebseinheiten). Es gibt auf Ebene 2 noch einen AVR, der eigentlich nur dem Schnittstellenhandling dient. Der stellt vor allem Digital- und Analog-Pins zur Verfügung. Irgendwie muss ich ja noch was messen können. Da kommt es dann drauf an, was angeschlossen wird, danach richten sich dann die Funktionen in der Firmware und da kann ich z.B. auch noch Interrupts einbauen. Die oberste Ebene ist ein ESP-12E, als schnellste Recheneinheit. Der verteilt vor allem Programmcode an die darunter liegende Ebene und ist sonst noch nicht ausgelastet. Ich fürchte, dass ich vermutlich Funktionen der zweiten Ebene aus dem AVR am besten raus nehme und die auf den ESP-12E verlagere (zum Beispiel langwierigere Berechnungen); das muss ich dann mal sehen, wie das mit den Zeitfenstern überall so passt. Eigentlich soll die mittlere Ebene die Oberste entlasten. Der ESP muss vor allem Daten zusammensuchen, vielleicht Wege berechnen usw. Also so weit habe ich das durchdacht. Zurzeit übe ich noch mit der Fortbewegung, ich probiere noch aus, was auf Ebene 2 wie schnell geht und wie dort die Vorgänge optimal gestalten kann (also den Programmablauf zur Fortbewegung). Deshalb dieses Thema hier "Fortbewegungsstrategie gesucht".

MfG

Zitat:

---

Zitat von Moppi

.. Ich habe drei Ebenen .. AVRs .. Echtzeitsteuerung .. AVR .. Berechnungen .. AVR .. nur .. Schnittstellenhandling dient. Der stellt vor allem Digital- und Analog-Pins zur Verfügung .. oberste Ebene ist ein ESP-12E .. verteilt vor allem Programmcode an die darunter liegende Ebene ..

---

Drei "Ebenen" AVRs. Versteh ich.

Der AVR für Schnittstellenhandling stellt Digital- und Analog-Pins zur Verfügung? Wieso dann Schnittstellen? Das verstehe ich nicht, kann mir nicht vorstellen. wie gehts?

Und ESP verteilt Programmcode? An die AVRs? Wie geht das? Programmiert der at runtime die Controller neu?

Hallo muell-er!

Ja, wieso Schnittstellen?

Schnittstellen gibt es überall, in Software, Hardware und auch in Hardware selbst.
Bei mir gibt es nur einen AVR, wo man praktisch noch was anschließen kann. Alles andere ist intern auf der Platine verdrahtet und (fast) nichts mehr nach außen geführt. Da sind theoretisch noch eine USART, serielle Schnittstelle und I2C, die I2C-Schnittstelle nutzt er selbst. Aber auch durch Software auf einem AVR lassen sich zusätzlich Schnittstellen installieren, die man so gängig als das sehen würde, wie SoftwareSerial (wo die ganz normalen I/O-Ports genutzt werden). Oder man nutzt die Pins anderweitig, direkt selbst als Schnittstelle und zusammen mit anderen Pins, womöglich einen ganzen Port, als weitere Schnittstelle. Da aber noch nichts festgelegt ist: Schnittstellenhandling, als allgemeinen Begriff, für Schnittstellen zu externen Geräten.

Zitat:

---

Programmiert der at runtime die Controller neu?

---

Der Programmcode ist festgelegt und gespeichert auf SD-Karte. Aber es ist durchaus denkbar, dass die Software auf dem ESP in der Lage ist, diesen Programmcode auch zu ändern. Die AVRs haben ihre Firmware drauf, die die Funktionen beinhaltet, die ein AVR ausführen soll. Also Funktionsumfang ist damit festgelegt. Damit tut der AVR aber jetzt nichts. Einzige Ausnahme hier vielleicht die IR-Diode, die ich fest in der Firmware drin habe, die aber auch nicht ausgewertet wird, solange dieses Feature nicht aktiviert ist. Damit die AVRs was tun, brauchen die Code für den Programmablauf. Den fordern sie beim ESP an. Der ESP ist auch in der Lage, selbst mitzuteilen, wer was tun soll. Er kann direkt dem AVR mitteilen, dass dieser jetzt als nächstes Programmcode Nr. 14365 ausführen soll. Darauf hin wird der AVR schauen, ob er den schon gespeichert hat, wenn nicht, muss er ihn anfordern und der ESP schickt ihm den (per I2C oder USART). Zu diesem Zweck habe ich einen Bytecode-Interpreter eingebaut. Und um der nächsten Frage zuvor zu kommen: auf dem ESP ist ein Webserver installiert, worüber man diese Codeblöcke erstellen und verwalten kann.

MfG

Ich bin etwas weiter. Nachdem ich ein paar Korrekturen im Code vorgenommen habe, fährt das Chassis nun endlich zufriedenstellend per IR-Fernsteuerung. So konnte ich das jetzt mal ausprobieren, was ich benötigen würde, um in der Wohnung zumindest herum zu fahren und Hindernisse zu umfahren. Zurzeit habe ich 45°-Abschnitte zum Drehen. Das ist etwas zu wenig. Praktisch ist die Hälfte davon besser. Also 22.5°. Zum Fahren sind 30cm am Stück schon ganz gut. Aber auch hier manchmal etwas viel. Deswegen denke ich, 10cm-Abschnitte wären gut, vielleicht auch 15cm. Feinsteuerung ergäbe sich später per Abstandsmessung, auch genaueres Fahren, um z.B. eine Ladestation anzufahren.

MfG

Hallo!

Ich habe mehrere Themen zu dem, was ich noch hinzufügen möchte. Aber ich tu das jetzt mal alles hier drunter schreiben, weil es mit der Fortbewegung zu tun hat. Vielleicht interessiert es den ein oder anderen.

Aus gegebenem Anlass habe ich mir einen Saugroboter zugelegt. Extra mit Fernbedienung. Daraus konnte ich jetzt auch erkennen, wie dort die Fortbewegung stattfindet. Da mein Projekt mit der IR-Bedienung auch schon funktioniert, habe ich jetzt mit gekauften Roboter keine Probleme, den in Betrieb zu nehmen. Man kann den ebenfalls mit IR-Bedienung "herumschubsen".

1. Mir ist aufgefallen, dass die Radien, in denen er sich per Fernbedienung drehen lässt, für meine oder unsere Ansprüche hier im Forum, bei weitem nicht so genau zu sein scheinen. Entweder ist der Drehradius so gewählt, dass sich damit keine ganze Umdrehung ausführen lässt, so dass man ihn in die Ausgangsstellung bekommt. Oder Die Drehungen sind schlicht einfach zu ungenau.

2. Ein zweiter Punkt ist, trotz breiterer Räder, dass der auf meinem 1.5cm hohen Teppich (anderer Thread) ebenfalls nicht geradeaus fährt. Der Roboter zeigt hier ein vergleichbares Fahrverhalten. Den Teppich überfährt er regelmäßig nicht gerade, mal schlingert er (das sieht man dann an der Fahrspur, die er auf dem Teppich hinterlässt) oder er fährt eine Kurve, mal weniger, mal stärker ausgeprägt.

3. Die Bewegung per IR-Bedienung erfolgt so, wie ich es bei meinem Projekt auch schon gemacht habe: in jede Richtung in Schritten. Vorwärts fährt er etwa 20cm, dann hält er an. Die Teildrehungen fallen sehr grob aus, da hätte die Hälfte auch gut getan, um ihn besser manövrieren zu können.

4. Sensoren, auch Bumper, sind nur in Fahrtrichtung. Nach hinten scheint er blind zu sein und fährt dann einfach auf Verdacht, wobei er zur Not auch Stühle verschiebt oder andere Gegenstände. Kein Ultraschall, habe keinen gesehen. Das Gehäuse ist geschlossen, da gibt es offenbar nur IR-Sensoren seitlich und vorne. Und die sind auch nicht besonders ausgefeilt, mindestens 50% der Kollisionen werden mechanisch erkannt. Fährt er an einer Kante lang, geht das nur so.

5. Die Strategie, um außen an der Fußleiste eines Raumes entlang zu fahren, besteht darin, immer im Kreisbogen nach außen zu fahren, bis es zur Kollision kommt. Danach dreht das Gerät etwas nach außen (in den Raum hinein), um im Kreisbogen wieder auf die Wand zu zu fahren. So geht das in kurzen Abständen immer und immer wieder.

6. Meistens fährt er, nachdem er angestoßen ist, rechts herum. Dreht vom Hindernis etwas weg, und fährt dann eine Kurve, wobei der Drehpunkt das rechte Rad ist.

7. Beide Räder sind gefedert, der Antrieb mittels Zahnradgetriebe. Es gibt keine stufenlose Geschwindigkeitsregelung. Es werden 3 oder 4 Geschwindigkeiten genutzt, bei Beschleunigungen kann man das deutlich erkennen und hören.

8. Die Ladestation findet er nur, wenn er schon davor steht. Die wird mit zwei Kontakten realisiert, die Gegenkontakte zum Laden sind unter dem Roboter angebracht und liegen frei. Das Laden erfolgt per Netzteil über zwei Drähte. Um in die Ladestation einzufahren muss er irgendein Signal erkennen. Er dreht dann sehr langsam und fährt schräg zur Ladestation bis zu einem bestimmten Punkt, dreht dann bei und fährt gerade auf die Station zu, in der Hoffnung, sie zu treffen. Manchmal klappt das auch nicht so gut.

So weit soll das hierzu erst mal genügen.

MfG

hallo Moppi,
um die erfahrungen mit meinem saugroboter vergleichen zu können, könntest Du bitte einen link spendieren? Einiges, wie das auffinden der ladestation ist z.b. völlig problemlos?

Das Auffinden der Ladestation macht der, indem er immer außen am Raum lang fährt. Sind die Türen offen, kommt er irgendwann in den Raum, wo die Ladestation an der Wand steht. Ca. 1m davor erkennt er sie irgendwie. Da ist eine Helle, weiße LED oben dran verbaut, vielleicht da drüber. Dazu steht natürlich nichts in der Gebrauchsanweisung. Wenn er in einem weit entfernten Raum steht, hangelt er sich so mühsam über die Außenwände zur Ladestation. Das kann schon dauern.

Ich kann Dir einen Link zum Produkt geben.

Saugen tut er einwandfrei, gibt es nichts dran auszusetzen.

MfG

das macht der chinesische anders. wenn er fertig ist mit saugen, dreht er sich im kreis und sucht die ladestation. Finder er sie nicht, bleibt er stehen und meldet das. Und möchte an eine andere position gesetzt werden um noch einmal zu suchen. Wenn er sie findet, fährt er auf einer linie die die senkrechte (an der stelle wo die ladestation steht) von der wand schneidet, am schnittpunkt - ca 50cm von der wand entfertnt dreht er sich noch einmal im kreis und fährt dann die senkrechte zur wand und lädt. Und meldet das akustisch auch. Deutsch...