Think Modular

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

[Defiant]

Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden.

Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?

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

Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.

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.

Bedingt sich natürlich alles gegenseitig. Ich würde mit dem Antrieb anfangen, dann kommt die Laufzeit und damit die Akkukapazität. Aber nochmal: Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?

[Moppi]

Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?

Die Diskussion geht doch darum dass es SLAM sein soll?

Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.

Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.

Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?

Irgendwo benötigt man doch eine Mindestanforderung, um entwicklungstechnisch darauf aufzubauen? Muss man erst mal durchspielen, so Pi*Daumen und sehen, was dabei heraus kommt. Dann erfährt man was über die Mindestgröße die das haben soll. Auch evtl. über die Baugröße der Module und deren Leistung (Akku/Batterie). Dann sieht man, ob das irgendwie unter einen Hut zu bringen ist. Wenn allein der Akku am Ende 500g wiegt, braucht man u.U. stärkere Motoren im Antrieb oder einen anderen Antrieb. Damit ändert sich evtl. die Größe des Antriebs und damit des Roboters und wieder das Gewicht. Modularität hat ja auch Grenzen. So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter. Und der Akku vom Staubsaugroboter wird keinen Toyota-PKW antreiben können.Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein. Wel dann kann man Bereiche festlegen, wie Akkuleistung von .. bis .. mAh. Mal kleiner, mal größer. Aber ich glaube, ich mache mir da jetzt zu viele Gedanken. Mal sehen, wie Holomino das sieht.


MfG

[morob]

Ich will bei meinem Weihnachtsprojekt weg vom SLAM, sondern fahren nach Farben machen, das heißt mit Tiefenbild. Ich werde berichten wie es läuft, fest montierte Lidar Sensoren, will ich nur wegen der Kollision verwenden.
Wie gesagt ich werde berichten.

Ich hatte auch schon mal an ein ES gedacht, mit Einsatzparameter, bin da aber irgendwie abgekommen.

[Defiant]

Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.

Manchmal frage ich mich in welchen Dimensionen du denkst. Du kannst natürlich auch LTE anstatt W-Lan verwenden oder den W-Lan AP mit einem Ethernetkabel mit dem Rest der Welt verbinden. Du musst ja nicht den ESP32 per Wlan anbinden, du kannst gerne einen Core I7 verbauen für Slam, ich glaube niemand hält dich dabei auf. Aber wenn andere einen ESP32 verwenden wollen und SLAM dann irgendwo in der Cloud rechnen wollen, wieso nicht?

So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter.

Das ist der zweite Satz weswegen ich mich frage in welchen Dimensionen du denkst.

Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein.

Nein, wichtig ist nur wie ich den Akku anschließe. Ob der Akku 1000kg wiegt und damit 500kW Motoren antreiben soll oder 500g wiegt und 1kW antreibt ist egal wenn du in deinem Moduldesign des Akkus spezifizierst "Spannung wird per I2C in Register 0 ausgelesen" dann kann dein Mikrocontroller ohne Änderung beide Akkutypen auslesen.