Think Modular

[Holomino]

Die sind inzwischen eingemottet, bin inzwischen umgezogen, also weiss ich nur, dass es damals ging, kann es jetzt aber nicht wiederholen...

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

Weil mir war noch was zu dem späteren "herunterstrippen" eingefallen: ich denke dieser Ansatz sitzt am falschen Ende.

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.

Unter dem modularen Aspekt spricht auch nichts dagegen, sich zuerst ein Fahrgestell mit einfachen Hindernisdetektoren zu bauen oder zu kaufen und es auf Herz und Nieren in der eigenen Umgebung per zufälliger Fahrt zu testen. Spätestens wenn man Odometrie anbaut und aufzeichnet, wird einem sowieso klar, wie unperfekt dieses System ohne Bezugspunkte zur Umgebung ist (einfach, weil sich Fehler während der Fahrt ohne Korrektur beliebig fortpflanzen).

Dann wird es Zeit, sich um die Anbindung der Umgebung zu kümmern. Neben den raster- oder vektororientierten 2- oder 3D-Karten gibt es sicherlich auch andere (featureorientierte) Lösungsansätze. Allerdings glaube ich nicht, dass ein Featureknotennetz bezüglich Sensorik, Parametrierung und Verifikation aus menschlicher Sicht einfacher zu behandeln ist. Auf eine Karte guckst Du nach Deiner Position und Du weißt, wo Du bist. Letztlich ist aus Sicht des Slams die Rasterkarte ein Abfallprodukt, das man als Mensch zufällig gut versteht. Man kann damit arbeiten, Dinge untersuchen (z.B. mal über die Wohnung ein Temperaturprofil oder die WLAN-Abdeckung aufzeichnen) oder auch etwas bedienen (der sophisticated Wecker, der morgens ins Kinderzimmer fährt und die Blagen solange mit pädagogischen Sprüchen vollquäkt, bis sie endlich aus den Betten hoppeln).

Also: Standortbestimmung und Zielpunktvorgabe in lesbarer Form sollte es schon sein.

[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

[Holomino]

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?

Das Update des Sollwertes für die Lageregelung (dem Punkt auf dem Pfad, den ich als nächstes in gerader Linie ansteuern kann) basiert bei mir auf mehreren Ereignissen:
- Die Auswertung des SLAMs (Takt 1s) korrigiert ja die Position. Wenn ich also nach dieser Korrektur sehe, dass der Roboter vom Pfad abweicht, muss ich ihm einen neuen Sollwert verpassen.
- Der Roboter gibt zyklisch (250ms) seine Odometrie-Pose zurück. Erreicht er dabei auf dem Pfad einen Knick, bekommt er einen neuen Sollwert. (Richtungsänderung und Strecke macht der Regler alleine)
- Nach Neuberechnung des Pfades (oder eines Teilstückes) wird der Sollwert instant aktualisiert. Ursache der Pfadänderung kann eine neue Zielvorgabe sein (fahre woanders hin) oder auch ein auf dem Pfad liegendes neu detektiertes Hindernis (Teilneuberechnung zum Umfahren des Hindernisses). Auf jeden Fall treten diese Ereignisse nicht zyklisch auf.

[Defiant]

Ein Roboter, der nur langsam in der Wohnung fährt, muss keine 10m vorausschauen oder gibt es dafür gute Gründe?

Bei SLAM braucht man Features, ohne kann der Algorithmus sonst nicht entscheiden ob er an Position x oder x+1 ist. Beispiel: Flur einer Uni, da sieht jeder m² identisch ist. Um so weiter man sehen kann um so höher die Wahrscheinlich das vielleicht eine Tür ist oder ein Stuhl den man als Feature nehmen kann.

[Moppi]

Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden. Wenn also ein Anforderungsprofil erstellt würde, sollte dann erster Stelle "SLAM" stehen. Das dafür Notwendige lässt sich daraus ableiten. Wie: zentrale Rechnereinheit (CPU/Board) und daraus folgend die Stromaufnahme. An der zweiten Stelle des Profils könnte stehen: Laufzeit xxx. Daraus kann man dann schon ganz grob zur notwendigen Akku/Batteriekapazität kommen und zum Gewicht des Akkus. Das Gesamtgewicht des Roboters sollte vielleicht dann schon an dritter Stelle des Anforderungsprofils stehen. Drum herum muss noch ein wenig Leistung für angeschlossene Peripherie eingeplant werden.