camera-based lane mowing (cm-precise)

[AlexanderG]

Hello,

The principle of the TerraMow lawn robot impressed me so much that I will try to try out this concept myself ("learning by doing" / "Open Source TerraMow ;-)").

Principle: A stereo camera (monochrome global shutter cameras, 80 degree FOV, e.g. Realsense D435i or SVPRO synchronized global shutter consumer stereo color camera 3200x1600) should be used to calculate the 3D points (point cloud).With an RGB camera (e.g. the one built into the Realsense), the 2D points are segmented via AI (i.e. each pixel is given semantics, in the simplest case two classes: lawn/no lawn). The semantics are then transferred to the 3D points ("point cloud segmentation").


Image left: 2D segmentation, right: 3D point cloud segmentation

Global localization is done via the 3D points and, if necessary, RGB images. The RTAB-Map-ROS software is to be used for this (and for calculating the 3D points).


3D pointcloud creation and 3D global localization

The robot should automatically recognize the lawn boundaries (perimeters), exclusions and obstacles. For example, 3D points that are too high from the ground should not be crossed or 3D points on the ground whose semantics have resulted in "no lawn". In a 2D map ("world from above", simple bitmap file), additional points can be drawn where the robot should not drive or which it should use ("overwriting the automatic"). There will be no UI (only start, stop and the bitmap file ("top view") to draw in).


Creation of top view bitmap, additional manual drawing of places/points for "not mowing" or "mowing"

The hardware will initially be a small PC (i7) with a modified Alfred ("quick prototyping"). Energy consumption is not the main focus, but rather implementing the "as fast as possible" concept. RTAB-Map-ROS is running on an Intel core i7 with 40% CPU load already. This could be running later on a RPI (with a lot of optimization), however my focus is to get it running first (optimization is stage 2).



Roadmap:
1. 3D calculation and 3D localization with RTAB-Map-ROS [done]

2. Relocalization in the point cloud map at different times of day
3. 2D segmentation (lawn/no lawn) with RGB camera (use ready-made AI model, do not train yourself)
4. Color 3D points with 2D segmentation
5. Robot logic: automatic mapping (find boundaries, create TopView bitmap)
6. Robot logic: mowing based on TopView bitmap ("find unmown points, take into account where it is allowed to drive, drive parallel paths, path angle is the one set when starting off")

Cheers,
Alexander

 

[KadaverJoe]

Hallo Alexander,
das sieht schon sehr interessant aus! Ich bin gespannt, wie es weiter geht! Wird es in Zukunft also nur noch Lidar/Kamerabasierte Roboter geben?

 

[AlexanderG]

Hallo, das ist eine sehr gute Frage - weitere Tests werden zeigen wo die Schwachstellen von optischen Systemen sind (Genauigkeit, Robustheit, Preis, ...). Grundsätzlich lassen sich die Systeme auch kombinieren (Semantik durch Optik/Vision, RTK zur Verbessung der Lokalisierungsgenauigkeit / in bestimmten Abständen werden dafür z.B. bei RTABMap-ROS die 3D-Punkte auf RTK-Koordinaten gesetzt ) - im Idealfall stellt man sich also seine Sensorik passend zusammen für sein "Projekt" (verwinkelte Gärten unter Bäumen versus riesige Frei-Flächen)... Es wird auf jeden Fall spannend werden!

 

[AlexanderG]

Exciting new progress...

1. The 3D curvature for all points in the 3D pointcloud can be computed:



This gives us the curvature (or in other words the radius) for each 3D point. A high curvature is more or less an obstacle (bushes, tress etc.) and not normal ground slope - example (blue means high curvature):





2. All 3D points can be segmented (filtered) by color - here we filter all green-like 3D points:



Finally, if we combine both methods (color and curvature), we get all lawn that is not bushes etc.:






Of course, automatic detection can never be perfect. This detection will be transferred to a 2D bitmap (top-view) where I can paint extra mowing areas or paths or no-go areas. This will allow the transition over the pavement into the bottom area...

Recording of a lawn detection session:

 

[Jensens]

Ist es möglich das als Testprojekt über zb Github zur Verfügung zu stellen? Ich würde damit gerne mal rumspielen!

 

[AlexanderG]

Ja, das kann ich gerne machen. Derzeit läuft das nur auf meiner Entwicklungsplattform (Core i7 mit Ubuntu 18.04) und daher ist das (derzeit) nur etwas für übermotivierte Leute ;-)
Es gibt so vieles was schief gehen kann wenn man das gezeigte ausprobieren will:
1. Benötigt ROS1 Melodic (läuft nur unter Ubuntu 18.04), läuft evtl. auch unter ROS2 (wenn man ganz viel Code ändert, ich hab bisher keine Erfahrung mit ROS2)
2. Benötigt eine kalibrierte Stereo-Cam (d.h. man muss sich ein grosses "Schachbrett-Muster" basteln zum kalibrieren der Kamera...)

Details wie das geht werde ich beschreiben. Geht evtl. auch mit Realsense-Kamera (die hat 2 Monochrom-Stereo-Cams und 1 RGB-Cam) aber dann muss man noch herausfinden wie man die RGB-Farben der Farbkamera nachträglich auf die Monochrom-Stereo-3D-Daten bekommt. Ich bin von der Realsense weggegangen weil mein Linux-Kernel damit immer abstürzt (5.4.0-150-generic #167~18.04.1-Ubuntu SMP).
PS: Gibt es hier "Gleichgesinnte" die ähnliche Projekte (Kamera, ROS, Lidar etc.) bereits durchgeführt haben oder bin ich der einzige der sich an solche Projekte heranwagt ;-) ?

 

[Jensens]

Ich habe zwar viel mit IT zu tun (Softwareentwickler), aber ROS treibt mich zum Wahnsinn.
Habe es jetzt auf dem MAC in Docker mit ROS Melodic am laufen, wegen der Reproduzierbarkeit. Nur ordentliche Launch Files und eine Gazebo Umgebung zum spielen fehlen noch.

Hier die Docker Umgebung, welche ich als Start genutzt habe:
https://github.com/HoverMower/ROSGazeboDesktop

 

[AlexanderG]

OK, dann werde ich mir den Docker-Container auch mal einrichten. Den Code (Link) muss ich noch aufräumen und an den Docker anpassen. Zuletzt habe ich 'rtabmap_ros' selber kompiliert (2 kleine Änderungen im Launch File) um SURF-Bildpunkt-Features testen zu können (dieses Paket selber kompilieren ist aber nicht notwendig und verkompliziert nur alles).

Die Kamera-Pipeline ist wie folgt:


Die Stereo-Bilder der USB-Kamera (=ein Bild) werden in links und rechts aufgeteilt, anschließend mit den Kalibrierungsparametern entzerrt (damit Punkte vom linken Kamerabild auf derselben Zeile wie vom rechten Kamerabild liegen um den Punktversatz und damit die Tiefe eines Punktes bestimmen zu können). Die entzerrten Bilder gehen in die visuelle Stereo-Odometrie und das Ergebnis der Odometrie geht zusammen mit den entzerrten Bildern in das Mapping.



Unter 'vision_robot' ist dann der Code aus den Videos. Zuletzt ergänzt wurde ein rviz-Plugin ('select_tool') womit man Bodenpunkte nachträglich einfärben kann (hier mähen/hier nicht mähen). Das Abspeichern der so gewonnen Benutzerdaten wird noch ergänzt.

Wenn das Mapping einmal durchlaufen wurde erhält man eine Pointcloud. Diese kann man eigentl. wunderbar verwenden um ohne extra Simulator (Gazebo) zu testen. Man ergänzt einfach eine 3D Bounding-Box welche den Roboter darstellt und welche mit einem einfachen Roboter-Modell (Differentieller Antrieb) bewegt wird. Dieses Modell braucht man auch wenn man auf 3D Kollision in der Pointcloud prüfen will oder wenn im voraus berechnet werden soll wie sich der Roboter bewegen kann (Bewegungs-Planung). Code für ein einfaches Roboter-Modell (welches auf "Gas/Lenkung" reagiert) werde ich noch ergänzen (sind 5 Code-Zeilen).

stereo_vision_paint.mp4

drive.google.com

(Eine Pointcloud als Simulation wäre realistischer als Gazebo - natürlich kann man so nicht die Stereo-Pipeline testen aber zum Testen der Stereo-Pipeline ist echte Hardware viel besser und auch wieder realistischer...In der Realität müssen oft Erkenntnisse aus dem Simulator angepasst oder sogar verworfen werden - der Simulator ist idealisiert - die Realität ist verrauscht, fehlerhaft, unvollständig etc. ;-) )

 

[AlexanderG]

Die Docker-Installation (ich arbeite unter Ubuntu 18.04) scheint noch nicht ganz zu laufen:

git clone https://github.com/jbnunn/ROSGazeboDesktop
cd ROSGazeboDesktop/
docker build -t ros-gazebo-desktop .
.....
Step 6/27 : RUN apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
 ---> Running in 587eb65e096c
Warning: apt-key output should not be parsed (stdout is not a terminal)
Executing: /tmp/apt-key-gpghome.oiTc57fXDy/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
gpg: keyserver receive failed: Cannot assign requested address
The command '/bin/sh -c apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654' returned a non-zero code: 2

Ich wiederhole einfach die letzte Zeile und es läuft weiter.... hier muss ich nochmal genauer untersuchen was da schief geht...

.....
Step 9/27 : RUN rosdep init && rosdep update
 ---> Running in 2829adf30a3c
/bin/sh: 1: rosdep: not found
The command '/bin/sh -c rosdep init && rosdep update' returned a non-zero code: 127

 

[AlexanderG]

Nächste Aufgabe die der Roboter später meistern soll: Hinderniserkennung - dabei soll nicht die zuvor aufgezeichneten Punktwolke verwendet werden (global map) sondern natürlich die aktuelle (local map). Hierbei reicht es sich die nähere Umgebung anzusehen ("local map"). Betrachtet wird (als Beispiel) der Bereich 2m vor dem Roboter/der Kamera in der Gösse des Roboters (Bounding-Box). Befindet sich dort ein Hindernis geht die Farbe der Bounding-Box auf "rot", sonst bleitb sie "blau". Hinweis: im Video wurde die Kamera mit der Hand durch den Garten geführt, daher ist die Bounding-Box nicht am Boden sondern in der Luft (Prinzip ist aber dasselbe)...

Erkannt werden:
- Rasen (kleine grüne Punkte), kein Rasen (kleine rote Punkte bzw. weisse Fläche) in der vorher aufgezeichneten Punktwolke
- Hindernis (Roboter käme nicht durch, rote Bounding-Box) oder kein Hindernis (blaue Bounding-Box) in der aktuellen Punktwolke

 

[flyfast]

Was ist wenn das Gelände sehr uneben ist....so wie bei mir?
Sehen die Kameras immer noch das was sie sehen sollen wenn es zwischen Himmel und Erde schwankt (leicht übertrieben)?
UWE

 

[skippa1978]

Das ist eine gute Frage. Uneben ist es hier auch, es wird auf verschiedenen Ebenen gemäht. Es gibt viele kleine Rasenflächen mit Wegen und Mauern dazwischen, die auf unterschiedliche Höhen führen. Da kann RTK mittlerweile sehr gut.

 

[AlexanderG]

Huckelrasen, Löcher im Rasen, viele Mauflwurfshügel, Hügel etc. haben wir auch, der Roboter fährt alles andere als sanft bei uns - da sehe ich kein Problem. Die Kamera hat einen Öffnungswinkel von 100 Grad und wird nicht am Boden sondern relativ weit oben und weiter zur Mitte am Roboter angebracht (genau wegen dieser "Problematik").

 

[AlexanderG]

Kurzes Update: die oben eingesetzte Lokalisierungs-Software ("RTAB-MAP") kann nicht mehr korrekt mit der Stereo-Kamera lokalisieren wenn sich die Umgebung geändert hat (z.B. im Sommer die Kartierung durchgeführt und im Herbst soll in dieser 3D-Punktwolken-Karte lokalisiert werden). Da identische 2D-Punkte gefunden werden müssen (für die 2D-Kamera-Punkte-zu-3D-Triangulation), besteht die Schwierigkeit in der Wiedererkennung genau dieser 2D-Punkte. RTAB-MAP findet falsche Punkt-Zuordnungen zu anderen gespeicherten Kamera-Bildern des Gartens und dadurch entstehen falsche Lokalisierungen. Zunächst muss dieses Problem also gelöst werden. Ansätze sind z.B. das Auffinden von identischen Punkten mit KI-basiertem "SuperPoint". RTAB-MAP unterstützt SuperPoint, dies muss aber extra hineinkompiliert werden.
Hier ein Beispiel wo ich SuperPoint als Python-Skript teste (identische Punkte werden gefunden):


Solche Ansätze benötigen allerdings einen KI-Coprozessor. Das Raspberry AI-Kit (Hailo) wäre evtl. so ein Kandidat. Im TerraMow z.B. werkelt eine 8-fach Core-ARM-CPU ("RK3588S" von Rockchip) mit integriertem KI-Coprozessor. Diese CPU findet sich auch auf diversen Fertig-Boards (z.B. Orange PI 5 Pro).

Es wird also noch ein paar Tage dauern bis genanntes Problem gelöst ist

 

[senil]

Kurzes Update: die oben eingesetzte Lokalisierungs-Software ("RTAB-MAP") kann nicht mehr korrekt mit der Stereo-Kamera lokalisieren wenn sich die Umgebung geändert hat (z.B. im Sommer die Kartierung durchgeführt und im Herbst soll in dieser 3D-Punktwolken-Karte lokalisiert werden). Da identische 2D-Punkte gefunden werden müssen (für die 2D-Kamera-Punkte-zu-3D-Triangulation), besteht die Schwierigkeit in der Wiedererkennung genau dieser 2D-Punkte. RTAB-MAP findet falsche Punkt-Zuordnungen zu anderen gespeicherten Kamera-Bildern des Gartens und dadurch entstehen falsche Lokalisierungen. Zunächst muss dieses Problem also gelöst werden. Ansätze sind z.B. das Auffinden von identischen Punkten mit KI-basiertem "SuperPoint". RTAB-MAP unterstützt SuperPoint, dies muss aber extra hineinkompiliert werden.
Hier ein Beispiel wo ich SuperPoint als Python-Skript teste (identische Punkte werden gefunden):
Anhang anzeigen 7673

Solche Ansätze benötigen allerdings einen KI-Coprozessor. Das Raspberry AI-Kit (Hailo) wäre evtl. so ein Kandidat. Im TerraMow z.B. werkelt eine 8-fach Core-ARM-CPU ("RK3588S" von Rockchip) mit integriertem KI-Coprozessor. Diese CPU findet sich auch auf diversen Fertig-Boards (z.B. Orange PI 5 Pro).

Es wird also noch ein paar Tage dauern bis genanntes Problem gelöst ist

Hallo,
Ich belege derzeit einen einfachen KI-Kurs und habe gesehen, wie der Jetson Nano Wunder wirkt. Abgesehen davon gibt es viele Bibliotheken, die in diesem Fall nützlich sein könnten.
Für diese Entwicklung fehlen mir die Kenntnisse, aber vielleicht ist es eine gute Alternative, die man untersuchen könnte.

NVIDIA Jetson Nano

Bring incredible new capabilities to millions of small, power-efficient AI systems.

www.nvidia.com

Embedded Systems - NVIDIA Jetson Success Stories

AI and edge computing are transforming every industry, including manufacturing, healthcare, retail, logistics, transportation, construction, agriculture, robotics, and more. Forward-looking companies are using NVIDIA Jetson to improve and accelerate their product development, proving every day...

resources.nvidia.com

Grüße.

 

[AlexanderG]

Hi, mit KI habe ich auch schon einiges gemacht - für eigene KI-Lösungen fehlt mir momentan die Zeit (das wäre ein eigenes Projekt "Grundlagenforschung") und daher suche ich eine fertige Lokalisierungssoftware die das Problem löst - Das "Problem" auf das ich aktuell gestossen bin wird in diesem Video gut erklärt und eine fertige Lösung wäre z.B. eine fertige Lokalisierungssoftware (RTAB-MAP) mit dem "SuperPoint"-Plugin laufen zu lassen - das werde ich versuchen auszuprobieren (über das dort gezeigte Docker Image). Die Software an die Hardware anpassen (Raspberry, Jetson etc.) werde ich hinbekommen, zunächst muss ich allerdings eine Lösung finden die das Problem auf irgend einer Hardware löst

 

[AlexanderG]

Update: nachdem ich das Thema "Stereo-Kamera-Lokalisierung mit RTAB-MAP und SuperPoint Plugin testen" etwas nach hinten verschoben habe (kommt dran, aber etwas später) habe ich mich dem Thema "Abarbeiten der Fläche" zugewandt. Ich habe ja schon oben angedeutet dass ich ein neues Konzept (TerraMow-like) ausprobieren will für die Roboter-Ablaufsteuerung: der Roboter soll nicht mehr von einem grossen "Masterplan" gesteuert werden sondern selber entscheiden wo er als nächstes hinfahren soll, wo noch freie, abzuarbeitende Flächen sind etc. Hier einige Ergebnisse (in dem Video-Beispiel Reinigen, funktioniert aber prinzipiell genauso für Mähen):

1. Der Roboter führt die Arbeit und Erkunden der Umgebung (Umgebungs-Karte erstellen) gleichzeitig durch:

2. Der Roboter führt die Arbeit nach dem Erkunden der Umgebung durch (Umgebungs-Karte ist schon erstellt):

Die weiteren Schritte sind:

• Benutzerinteraktion mit der Umgebungskarte, so dass der Benutzer "No-Go-Areas" hineinmalen kann
• Randmähen, also das Abfahren der Ränder an Hindernissen/No-Go-Areas

 

[AlexanderG]

Mal wieder ein Update: wir sammeln immer mehr Erfahrungen mit ROS und im ROS-Simulator laufen viele unserer Ideen schon prototypisch (

)

Dann bin ich heute auf diesen Roboter gestossen (ECOVACS Goat O500 Panorama) welcher nur mit Fischaugen-Kamera lokalisiert - bei der Recherche bin ich dann auf Details gestossen:
- basiert auf RK3588 (also gleiche CPU mit 8 Kernen wie auf dem OrangePi5Pro - diesen SBC/diese CPU setzen wir aktuell auch für ROS ein)
- 2MB/3MB Bildsensor (2052 x 1540 Pixel mit Rolling-Shutter, also 10 EUR Kamera )
- basiert auf ROS Melodic
- nutzt ROS VSLAM (vermutl. stella vslam ?)
- kann gerootet werden ( https://robotinfo.dev/detail_ecovacs.5xu9h3_0.html )
interessant, interessant

 

[Starsurfer78]

Hast du dir schon den Anthbot Genie angeschaut?

 

[AlexanderG]

ja, ein ebenfalls interessanter Roboter (der nutzt nach wie vor RTK zur Lokalisierung wenn ich das richtig verstanden habe)- ich hatte diesen Thread eröffnet mit der Motivation eine universelle Lokalisierungs-Technologie mit Kameras zu finden die überall funktioniert (Indoor, Outdoor, sehr grosse Flächen ohne Objekte drauf, kleine Flächen) und da scheint LiDAR immer noch das Non plus ultra zu sein - inzwischen verstehe ich: die (präzise) Lokalisierung über Kamera funktioniert leider nicht auf sehr grossen Flächen (z.B. leere Halle 100x100m oder Fussballplatz 100x60m) - auch eine Stereo-Kamera oder eine 360 Grad Fischaugen-Kamera ändert daran leider nichts. Für KI-Hinderniserkennung sind die Kameras hingegen gut geeignet. Kurzum: Für bestimmte Umgebungen sind RTK oder Kamera gut geeignet - für eine universelle Lokalisierung (eine Lokalisierung für beliebige Anwendungen) sehe ich inzwischen das LiDAR ganz vorne

Als "Bild" ausgedrückt In etwa so: