3D-sensing für ROS

**Defiant** · 01.02.2018, 07:49

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.

Zitat von Ceos

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:

Zitat von AstroRobot

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** · 01.02.2018, 08:17

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

**Defiant** · 01.02.2018, 19:23

Da hab ich mich wohl unklar ausgedrückt. Natürlich muss ein Hindernis durch einen Sensor erfasst werden, damit dem ausgewichen werden kann. Mein Punkt ist aber das ich zum Ausweichen die Wegplanung in 2D machen kann. Ich kann z.B. eine 3D Kamera nehmen und den Raum um mich rum in de 2D-Ebene abbilden. Um beim Karton zu bleiben: Man nimmt seine Umrisse inkl. Deckel und bildet den kompletten Umfang in die Ebene ab.

Bei dem PR2·sieht man übrigens einen Laserscanner der vertikal geschwenkt wird. Also auch eine Variante die den Deckel eines Karton sehen dürfte.

P.S.: Kleine Korrektur: Realsense ist von Intel und anscheinend kein normales structured light wie die Primesense Kameras (Kinect v1) sind.

**Ceos** · 02.02.2018, 06:59

Realsense ist von Intel und anscheinend kein normales structured light wie die Primesense Kameras (Kinect v1) sind

ja das sieht viel mehr nach dem konzept aus dass auch das iphone x verwendet aber das hat wohl definitiv einen zu kleinen mindestabstand

habe gerade ncoh ein angebot für eine 3te kamera bekommen, die angeblich "VGA" kann also wenn der begriff stimmt 640x480 aber ich tippe mal auf weniger, habe mich jedenfealls für diese entschieden und bestelle sie mir, ist aber auch n ganzen schwung teurer

**Andre_S** · 02.02.2018, 10:06

Hallo zusammen,

es ist sehr interessant zu lesen, dass ROS nicht wirklich effektiv einen Sensor wie Kinect unterstützt. Simulation und Visualisierung besitzen in ROS ja einen hohen Anteil, allerdings dass es scheinbar nicht vernünftig möglich ist die Werte des Kinect Sensors für eine 3D Hinderniserkennung einzusetzen lässt mich mein Projekt (Umstellung auf ROS) erneut überdenken.
Aber dies ist nicht das Thema.
Die Berechnung passiert ja auf Triangulation, also einfachen Dreiecksberechnungen. Positiv dabei ist das die Entfernung immer die gerade vom Bot zum Objekt darstellt. Um mein damaliges Vorgehen grob darzustellen:
Ich prüfe kontinuierlich in Bewegungsrichtung das Deph-Image auf gültige Entfernungswerte, die dem Umriss meines Bot entsprechen. Größe des Bot und Position der CAM ist ja bekannt und somit auch die notwendigen Bereiche. Tritt innerhalb des Bot-Bereiches ein gültiger Entfernungswert auf, wird in einem Array genau dieses Element erhöht. Das Array besteht also aus genau der Anzahl maximal möglicher Entfernungswerte. Nach Analyse des Tiefenbildes wird das Array ausgewertet. Der erste Arraywert, welcher eine Mindestanzahl von Punkten beinhaltet, (Mehrere gleiche Entfernungswerte sind notwendig um Fehlmessungen nicht als Hindernis zu interpretieren und auch auf eine Mindestobjektgröße zu prüfen) entspricht der Entfernung zum Hindernis.
Bei meiner Botgröße und der damaligen Position/Winkel des Kinect Sensors konnte ich aber nur bis auf 5cm Bodenhöhe abtasten um nicht diesen situationsbedingt als Hindernis zu erhalten.
Dieser Prozess geschieht kontinuierlich und aktualisiert zyklisch den Entfernungswert zu einem Hindernis mit welchem der Bot kollidieren würde.
Ich hatte dies hier auch mal grafisch im unteren Bild visualisiert, an welchem man erkennt, dass er mit dem Drehstuhl unten und oben in ca. 110cm Entfernung kollidieren würde.
http://home-robotics.de/Seite22.html

Gruß André