3D-sensing für ROS

[Ceos]

Die Idee eine 3D Abbildung zu verwenden hat multiple Vorteile

man kann zum Beispiel bewerten ob ein Objekt flach genug ist es zu passieren (Türschwelle) oder zu hoch (Rohr eines Klapp-Wäscheständers, SEHR populäres Beispiel und hab ich auch selber schon live erlebt wie sich der Saugrobo von nem Kumpel mehrmals daran festgefahren hat)

oder ob ein Hinderniss ausreichend hoch ist um darunter passieren zu können (Der Robo von meinem Kumpel hat tatsächlich einen LIDAR und hat sich auch schonmal unter dem Sofa festgefressen weil er leicht schräg nach Vorne unten guckt und das Sofa quasi nicht sichtbar für ihn war)

Allerdings brauch man auch den entsprechenden Beef im Prozessor um das auszuwerten

Leider scheinen meine Bemühungen mit dem LeapMotion wohl nicht von Erfolg gekrönt zu sein, der misst einfach Stereoskopisch und die Bereitgestellten APIs liefern nur die Daten von getrackten Händen aus aber keine Punktwolken -.-

ich kann mir zwar die Stereobilder holen aber dann müsste ich die Tiefenauswertung komplett selber schreiben und echtes ToF ist das dann leider auch nicht, aber Hände tracken kann das Ding echt klasse!

PS:

Ist es denn sehr aufwendig solch eine Applikation zu entwickeln?

ich habe den Kern deiner Frage garnicht erfasst ... sorry ... die Punktwolke zu erhalten ist die eine Sache und je nach verwendetem Erfassungs-Werkzeug nicht unbedingt schwer oder gar unheimlich simpel! (Es sei denn man muss den Sensor selber ansteuern um die Punktwolke zu realisieren)

Das andere ist die Auswertung der Punktwolke und ungefähr gleich schwer vorzustellen wie auf einem 2D-Bild eine Objekt mittel Algorithmen zu erkennen.

Wenn ich die Tiefeninformation im Bild als Grauskala speichere kann man sogar gezielt Bilderkennung verwenden.

Ich finde das beste daran ist, dass man jedem Pixel einem gedachten Lichtstrahl zuordnen kann und anhand der Ausrichtung des Lichtstrahls und dem gemessenen Abstand vortrefflich die Höhe des im Pixel reflektierten Objektes feststellen kann.

Ich würde vermutlich so heran gehen, dass ich die Kamera vorne leicht Schräg nach unten sehen lasse und pro Pixelzeile (unter der Annahme dass alle Pixel im Raum parallel zum Boden verlaufen) einen Grenzwert festlege. Überschreitet einer der Pixel (bis zur Zeile die leicht nach oben abstrahlt) diesen Grenzwert ist ein Objekt im Weg, habe ich eine hinreichende Bestätigung bei Annäherung (also einen zusammenhängenden Pixelcluster in der 2D Tabelle/Bitmap) welcher hinreichend groß ist, weiche ich aktiv aus. Für die Erkennung von flachen Hindernissen und flachen passiwerbaren Hindernissen müsste ich mir noch was einfallen lassen, aber das sollte auch mit ein paar geschickten Grwenzwerten (Gutbereich für Bodenschwellen z.B.) zu lösen sein.

PPS: Wenn jemand ein paar gute ToF Kameras < 150€ kennt, würde ich mich über entsprechende Links freuen Ich will nämlcih noch was gaaanz anderes damit machen

[Defiant]

man kann zum Beispiel bewerten ob ein Objekt flach genug ist es zu passieren (Türschwelle) oder zu hoch (Rohr eines Klapp-Wäscheständers, SEHR populäres Beispiel und hab ich auch selber schon live erlebt wie sich der Saugrobo von nem Kumpel mehrmals daran festgefahren hat)

Alles eine Frage der Abbildung in den 2D-Raum.

Objekt zu hoch: In die 2D costmap.
Objekt niedrig: Nicht in die 2D costmap.

[Ceos]

mit einem LIDAR hat man nur eine einzelne Pixelzeile und die Hinderniserkennung ist nur Zeitlich abhängig realisierbar, bei der 3D lösung kann man das Ojekt sofort udn als ganzes erfassen, denn beim ausweichen/drehen hat man die Randdaten ja nicht mehr und wo man gerade noch an einem Hinderniss vorbeigefahren ist, kann es pasieren dass ich mich jetzt drehe und das neue Hinderniss gerade in der Blinden Zone liegt

Auch ein live erlebtes Beispiel, fährt an einem Karton vorbei, der offen hängende Deckel des Karton ist gerade hoch genug um vom LIDAR beim vorbeifahren nicht bemerkt zu werden. Der Robo dreht dann als er beim Vorbeifahren ein Tischbein erkennt in Richtung des Karton und rammelt volles Mett gegen den Kartondeckel weil er ihn nicht sehen kann. Mit einer 3D Abtastung hätte er den Deckel als Hinderniss gesehen. Hindernisse die gerade hoch genug sind um sich einzuklemmen kanne r einfach nciht sehen weil der LIDAR eben nciht nach oben sondern schräg nach unten guckt! Und ein querliegendes 1.5cm Rohr kann er auch nur schwer abtasten, eine ToF Kamera jedoch kann recht deutlich und zu jeder Zeit das Rohr erkennen

[AstroRobot]

Ich sehe, das Schlüsselelement auch hierzu ist die layered Costmap. Jetzt muss ich nur noch die 3D Daten entsprechend verarbeiten und in die Costmap übertragen.

Wobei Ceos' Idee mit den Grenzwerten für jeden einzelnen Pixel sicherlich auch gut für einen ersten Test ist.

[Ceos]

ich bin eher der bare-metal typ, die ganze ROS sache ist zwar nett udn für größere Projekte gut ich bin aber eher jemand der mehr spaß dran hat funktionsweisen zu verstehen udn nachzubauen oder zu verbessern (treiberebene wäre dann mein favorisierter bereich)

ich will versuchen die punktwolke in eine VR umgebung zu projezieren, damit ich ein wenig mixed reality machen kann

[AstroRobot]

@Ceos: Da stimme ich dir zu! Erst wenn man es selber wirklich "from the scratch" aufgebaut hat, kann man es wirklich.

ROS ist ein tolles Tool, wenn man ein komplexes System aufsetzen will, wo viele Komponenten möglichst schnell zusammen funktionieren sollen. Wenn man ein wirklich stabiles, ausgereiftes und qualitätsbewusstes Produkt entwerfen will, würde ich auch zu einer Eigenentwicklung tendieren. Alleine weil man somit viel effizienter Hardwareressourcen nutzen kann, selbst wenn ROS bereits auf lightweight Design ausgelegt ist.

[Defiant]

Auch ein live erlebtes Beispiel, fährt an einem Karton vorbei, der offen hängende Deckel des Karton ist gerade hoch genug um vom LIDAR beim vorbeifahren nicht bemerkt zu werden. Der Robo dreht dann als er beim Vorbeifahren ein Tischbein erkennt in Richtung des Karton und rammelt volles Mett gegen den Kartondeckel weil er ihn nicht sehen kann.

Das halte ich für ein Problem der Sensoren bzw Umsetzung der Projektion in den 2D-Raum, nicht als Problem einer 2D-Umgebung. Es spricht nichts dagegen den Karton mit seinem kompletten Umfang in die 2D-Ebene einzufügen.

Wenn man ein wirklich stabiles, ausgereiftes und qualitätsbewusstes Produkt entwerfen will, würde ich auch zu einer Eigenentwicklung tendieren.

Genau hier möchte ich widersprechen. Gerade ROS ist stabiler und ausgereifter als jede Eigenentwicklung die ich oder sogar ein kleines Team in kurzer Zeit entwickeln könnte, zumindest für Anwendungsfälle die über das Folgen einer Linie hinausgehen.
Sicherlich lernt man viel, wenn man ein Verfahren wie SLAM selbst implementiert, aber die Alternative ist ROS zu verwenden und die selbe Entwicklerzeit in eigene ROS-Pakete zu stecken oder bestehende zu verbessern, wovon dann andere profitieren könnten.

Btw ROS ist alles andere als "lightweight", aber auf die Verwendung minimaler Ressourcen ist es nicht ausgelegt. (ROS2 hat hier ein paar Vorteile gegenüber ROS1 durch die Verwendung von DDS).

[Ceos]

Genau hier möchte ich widersprechen. Gerade ROS ist stabiler und ausgereifter als jede Eigenentwicklung die ich oder sogar ein kleines Team in kurzer Zeit entwickeln könnte, zumindest für Anwendungsfälle die über das Folgen einer Linie hinausgehen.

das ist gewagt, denn wenn es hart auf hart kommt, ist es besser zu wissen was genau jeder fetzen code macht als darauf zu vertrauen dass die open source quelle fehlerfrei ist (anhand unzähliger beispiele nachgewiesener maßen ist sie es nicht)

es sei denn man befasst sich mit der verwendeten codequelle udn macht sich begreiflich wie sie arbeitet um sie dann effektiv debuggen zu können. das wiederum setzt grundwissen voraus, das man sich erst durch eine low level implementierung erarbeiten muss oder eben durch intensive code review!

die aussage einen qualitativen code von hand zu bauen ist nicht falsch aber teuer und langwierig (hohe initialkosten) aber man zehrt ewig von der erfahrung

außerdem ist es interessensfrage, mein interesse ist, wie es so schön heißt, "zu wissen was die welt im inneren zusammenhält" ... und mein erfolgreichstes lernschema ist "learning by doing"

leichtgewichtigkeit ist natürlich der hauptvorteil einer manuellen implementierung und im sinne des kunden (stückpreis) nactürlich auch resourcen schonender

und solange sich die ersparnisse in hardware pro stück in absehbarer zeit über die menge gegen die initialkosten aufrechnen ist es das dann auch wert


aber wir reden hier über ansichten die einer persönlichen note unterliegen, daher sage ich nciht dass du falsch liegst aber dass man es auch anders betrachten kann und sollte

[Defiant]

Natürlich ist nichts in ROS fehlerfrei (Welche SW ist das?) und natürlich gibt es immer noch unzählige Bugs. Es spricht natürlich nichts dagegen alles selbst zu schreiben aber die Aussage, dass selbstentwickelte SW stabiler und qualitativ besser ist als eine, die 10 Jahre von mehreren Menschen entwickelt und noch viel mehr verwendet wurde halte ich für vermessen. Persönlich finde ich es schade, dass der ROS-Community dadurch eine wertvolle Ressource fehlt. Gerade ROS bringt mit Tools wie rviz und Anbindung an z.B. Gazebo auch wertvolle Werkzeuge zum Debuggen mit.

Es geht auch nicht darum alles selbst zu schreiben oder nur fertige ROS Module zu verwenden. ROS ist in erster Linie eine Middleware zur Kommunikation der einzelnen Module (Nodes) untereinander. So oder so wird man viele Algorithmen selber implementieren, aber gerade hier lässt ROS einem aufgrund der Modularität die Freiheit genau das zu tun. Und als Basis hat man bei ROS Software auf die man sich verlassen kann.

außerdem ist es interessensfrage, mein interesse ist, wie es so schön heißt, "zu wissen was die welt im inneren zusammenhält" ... und mein erfolgreichstes lernschema ist "learning by doing"

Ist natürlich auch wichtig, dass es immer Leute gibt die das durchziehen, nur halt Qualität ist genau der eine Grund den ich nicht gelten lassen möchte. Abgesehen davon kenne ich deinen Anwendungsfall nicht, vielleicht profitiert dieser ja wirklich nicht von der Verwendung ROS. Bin jetzt von "Standard Robotik" ausgegangen.

Aber lass und mal lieber zum Thema 3D Navigation zurück (Auf ROS oder nicht ROS habe ich nicht wirklich Lust

Mir ist da grad was im ersten Post aufgefallen, was ich übersehen habe:

Oftmals nutzen die Pakete lediglich eine einzelne Zeile des Tiefenbilds z.B. zur Navigation, um einen 2D Laserscanner zu imitieren.

Ich vermute du sprichst da depthimage_to_laserscan an, es gibt da den Parameter "scan_height", der die Anzahl Zeilen konfiguriert. Was leider fehlt ist die Option, z.B. nur die unteren 10 Zeilen zu verwenden. Aber für komplexere Anwendungsfälle gibt es ansonsten pointcloud_to_laserscan.

[Ceos]

Auf ROS oder nicht ROS habe ich nicht wirklich Lust

über geschmack lässt sich vorzüglich streiten, aber das wollen wir ja nicht

ich sehe im momnent ehrlich gesagt hauptsächlich das problem erstmal taugliche und bezahlbare 3D abtastung zu finden oder eine zuverlässige 2D abtastung zu konstruieren

zu deiner aussage vorher stellt sich mir die frage, wie du den karton denn erfassen möchtest wenn er nicht im scanbereich ist?! (falls es nicht klar rauskam, der offene deckel war zu hoch für den zeilenscanner aber tief genug um den robo zu blockieren und das querliegende rohr des wäscheständer war so niedrig dass er es erst nicht gesehn hat udn dann beim wenden drauf auffuhr und stecken blieb)

wenn cih nur einen einzeiligen zeilenscanner habe muss ich ihn so positionieren, dass er sowohl bodennahe objekte erfassen kann als auch objekte die sich sehr weit oben befinden, den scanner an der höchsten stelle des robo anzubringen und leicht schräg nach unten sehen zu lassen, erlaubt es dir einen relativ großen beerich abzuscannen, kann dann aber leicht unterlaufen werden, vor allem wenn sich der robo gerade dreht und seitlich ein niedriges hindernis ist oder das hindernis gerade tief genug hängt um nicht im strahl zu sein aber den robo zu behindern, eine volumentrische erfassung macht meiner meinung nach mehr sinn, benötigt aber eben eine bezahlbaren sensor und etwas mehr rechenpower ...


by the way ich bin bei meinen bisherigen suchen nur auf 3d ToF kameras im miniformat für 150$ aufwärts gestoßen, keine günstigeren technologien soweit leider

----------

also ich habe bisher nur 2 kameras gefunden wobei eine nur zeitweilig für einen ansehnlichen preis von 200€ mit 242x171 pixel zu finden war und eine von Seeed Studios mit 80x60 pixel für 175€, die 150€ lösung hat sich doch nur als überteuerter Rangefinder heausgestellt.

dann gibt es da noch realsense von microsoft die wesentlich günstiger ist aber mit projezierten mustern arbeitet und einen gewissen mindestabstand fordert