Think Modular

[Moppi]

Ich kann es nur aus meiner Sichtweise erläutern: Nachdem ich im Simulator eine befriedigende Lösung gefunden hatte, habe ich mir überhaupt erst die Mühe gemacht, eine Hardware dafür zu finden.
Selbst mit dieser Vorgehensweise liegen noch viele Irrwege und produzierter Schrott bis zum ultimativen Gerät vor Dir, das alle Fallstricke Deiner Wohnung oder Deines Gartens umschifft.

So kann ich das besser nachvollziehen, welcher Gedanke dahinter war. Wenn Du das so noch mal machen willst. Ich weiß nicht. Ist das sinnvoll?

wie unperfekt dieses System ohne Bezugspunkte zur Umgebung ist (einfach, weil sich Fehler während der Fahrt ohne Korrektur beliebig fortpflanzen).

Ja so ist das natürlich. Frage ist, ob das stört oder ob man auch mit Ungenauigkeiten arbeiten kann. Ob ein Fahrgestell mal ein paar Millimeter weiter links oder rechts fährt oder am Ende einer Strecke 3cm versetzt ankommt, ist u.U. gar nicht so wichtig. Da kommt es dann auf die Regelung an. Eine Positionsbestimmung in einem bestimmten Rahmen muss ja irgendwie gegeben sein, wenn sich das Gerät nicht rein zufällig selbst bewegen soll.

Ich sehe wohl die Vorteile einer Karte. Aber auch die großen Datenmengen, die in Echtzeit verarbeitet werden sollen. Allerdings mangelt es mir hier an Erfahrung mit Laserentfernungsmessung, bezüglich der Daten. Ich würde das glaub ich zielgerichtet und damit selektiv einsetzen. Nicht unbedingt in der Form, ein Rundumbild zu erstellen. Auch wenn das in Summe gesehen eine sehr gute Möglichkeit wäre. Weil man dann eben z.b. so eine Karte auch auslesen und sich selber anschauen könnte und weil ein Algorithmus, der einen Weg in der Karte zum Ziel findet, super ist, weil sich so eben insgesamt auch jeder Zeit die Position im Raum bestimmen lässt (bezugnehmend auf die Umgebungshindernisse). Ist eine Frage der Zielsetzung, mehr kann ich zurzeit dazu nicht sagen. Wenn Du das ohnehin schon so machst und weiterhin so vor hast, ist es so. Eine einfachere oder andere Lösung kann ich noch nicht präsentieren. Inkas Anforderung wäre, dass sich das Gerät selbst im Raum bewegt und Baken folgt, tifft es auf Hindernisse, werden die umfahren und eine Bake bspw. zielgerichtet verfolgt. Das Gerät muss nur die Richtung der Bake erkennen (drehbarer IR-Empfänger bspw. oder mehrere IR-Empfänger im Kreis angeordnet) und sich dann in diese Richtung drehen und drauf zu fahren. Mein Versuchsansatz ist ein anderer, der mich dann erst einmal mehr interessiert (dazu gab es aber einen längeren Thread, wo ich das Für und Wider in der Diskussion sehr hilfreich fand, mir klarzuwerden, ob das funktionieren könnte). Weil mich mehr interessiert, dass ein Gerät einen Punkt in einem Raum mehr oder weniger genau selber anfahren kann (oder auch in einer ganzen Wohnung mit mehreren Räumen eigenständig die Räume findet) im Grunde, ohne dafür direkt eine Karte einzusetzen, mit Wegberechnung. Aber auch möglichst ohne Baken oder anderes Künstlich aufgestelltes. Inwiefern weiter Hilfsmittel notwendig sind, um das Ziel zu erreichen, wird sich im Laufe der Experimente herausstellen.

MfG

[inka]

Das ist Schade. Kannst Du denn hier etwas mehr über die Technik (Funk/IR, Frequenz, Reichweite, Peilwinkelgenauigkeit) erläutern?

Die IR-baken wären natürlich reaktivierbar, ob sich das lohnt weiss ich nicht. Es wäre eine baustelle mehr, irgendwann werden es zu viele. Meine überlegungen und vorgehensweise von damals kann man hier nachlesen...

[Holomino]

Die IR-baken wären natürlich reaktivierbar, ob sich das lohnt weiss ich nicht.

Wieso nicht? So eine IR-Bake habe ich auch an der Ladestation.
Was mir nicht so gut gefällt: IR-Baken senden aktiv und wollen versorgt werden. Bei steigender Anzahl wird man im Dauerbetrieb eine Menge Steckdosen belegen.

[Moppi]

Standortbestimmung und Zielpunktvorgabe in lesbarer Form sollte es schon sein.

Vom Prinzip wäre ich dabei, aber ich würde das in möglichst kleiner Form realisieren. Als Beispiel würde ich einfach einen ESP-12 nehmen, weil davon welche habe und das damit ausprobieren. Ich könnte mir vorstellen, dass das passt. Fürs Wissen müsste ich es tatsächlich versuchen. Ich hatte schon mal mit LIDAR geliebäugelt, wegen einer genauen, alternativen Entfernungsmessung. Aber bei 200 EUR ... ich weiß nicht. Ich kenne mich auch mit den Softwarelösungen (Slam) nicht aus. Ich denke aber, ich würde es einfach so machen, wie ich es mir vorstelle. Kann so schwer nicht sein, eine Karte zu erstellen, also im Grunde einen Datensatz, in dem ich meine Hindernisse markiere. Eventuell braucht es ein paar Durchläufe, um die Daten zu überarbeiten und etwas länger würde es brauchen (weil ich so was ähnliches schon umgesetzt habe), um einen Pfad zum Ziel zu finden. Der Algorithmus wäre etwas umfangreicher vielleicht und würde auch einen Moment länger laufen (Rechenzeit). Hier würde mich mal noch interessieren, wie schnell denn so was sein soll? Wie schnell soll so eine "Karte" aktualisiert werden und wie schnell muss ein Weg gefunden werden? Also mal in Sekunden ausgedrückt vielleicht? Wenn man vorgibt: 30 bis 60mal pro Sekunde, ist es natürlich mit sehr viel Rechenpower verbunden. Also, wie sind die Anforderungen und vor allem, warum?

MfG

[Holomino]

Also mein aktuelles Lidar ist ziemlich langsam mit einem Rundumscan/s (das ist auch die Aktualisierungsrate der Lidar-Karte). Der Sensor (LidarLite V1) hat eine Messperiode von 13ms, also etwa 75 Messungen/Scan. Es kommt jetzt etwas auf die Robotergeschwindigkeit (->Scans/s) und die Größe der Umgebung (->Messungen/Scan) an. Mit 15..30cm/s lässt sich bei mir auf jeden Fall auch ein 5x6m Raum im 5cm-Raster auflösen.

Was bei mir in der Simulation und auch in der Praxis (https://www.roboternetz.de/community...enhals-im-Slam) auffällt: Die Reichweite ist wichtig. Andere Verfahren legen allerdings auf die Extraktion von Features (Ecken oder Linien) Wert. Da geht es dann eher um die Anzahl der Messungen/Scan.

[Moppi]

Ja gut, hätte ich jetzt nicht gedacht, dass die Reichweite doch so ausschlaggebend ist, aber das relativiert sich gleich (zwei Sätze weiter im Text). Die Rotationsgeschwindigkeit hatte ich auch schon im Kopf, muss man anpassen. Kommt ja nun drauf an, wie weit man vorausschauen muss. Das ist auch von der Bewegungsgeschwindigkeit abhängig (jedenfalls für mich logisch). Ein Roboter, der nur langsam in der Wohnung fährt, muss keine 10m vorausschauen oder gibt es dafür gute Gründe? Für mein Verständnis setzt sich eine Gesamtkarte zusammen, wenn der Roboter mehr und mehr Bahnen im Raum abgefahren hat. Die Messreichweite mit 50cm sollte ausreichen, wenn nicht sogar viel weniger. Ich vermute hier kommt es auch drauf an, wie schnell der Roboter ausweichen könnte und überhaupt sich bewegen würde. Wenn der ganz langsam fährt, genügt auch eine sehr geringe Reichweite. Allerdings muss er dann weitere Strecken fahren, um einen Raum zu erkunden, bzw. um festzustellen, ob es in eine Richtung überhaupt weiter geht oder da ein Hindernis auftaucht. Da kommt mir sofort der Gedanke, das hier etwas anders zu lösen. Nämlich nur das unmittelbare Nahfeld aufzuzeichnen und wenn mehrere mögliche Pfade zum Ziel berechnet wurden, hier dann jeweils die Messreichweite in genau diese eine Richtung zu erhöhen und also alle Pfade selektiv in einer höheren Reichweite zu scannen. Damit er eben nicht alle abfahren muss.

Also das war jetzt nur so, was mir dazu einfallen würde. Ich muss erst damit arbeiten. Aber mir ging es ja auch um die Geschwindigkeit, wie schnell das sein soll, mit den Scans und den Berechnungen. Um so direkter man den Weg zum Ziel ausspionieren möchte (um also direkt von Anfang an den passenden Pfad von A nach B zu finden) benötigt man eine vollständige Karte der Umgebung. Ich denke hier würde man die Pfadsuche ein Mal ausführen müssen, zu Beginn eben. Das dürfte auch etwas dauern, meinetwegen auch 5 Sekunden. Vermutlich würde man den Pfad dann in die Karte übernehmen und fertig. Damit sind die Punkte klar, die man immer wieder auf dem Weg zum Ziel ansteuern muss. Der Rest spielt sich nur im Nahfeld ab (mit einer tauglichen Reichweite). Aufgrund der geringeren Datenmenge sollten diese Algorithmen weniger Rechenzeit benötigen (womöglich sehr viel weniger).

Trotz allem würde mich interessieren, was Du als Anforderung siehst, welche Berechnungsgeschwindigkeit, bis die nächste Entscheidung getroffen werden kann, wo der Roboter lang fährt. Also wie oft pro Sekunde?

MfG