Alfred with Vision and AI (Approach)

[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

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 reation and 3D 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