ullisun58
Well-known member
Thx for this helpful guidePerimeter sender (English) – www.wiki.ardumower.de
wiki.ardumower.de
RoπLawnMow
- Thread starter ullisun58
- Start date
ullisun58
Well-known member
Nun gibt es noch was Neues in 2024 von mir:
Vor Weihnachten hat Aisler noch meine PCBs für die Perimeter Erkennung geliefert. Da habe ich gestern eine bestückt und heute gestestet.
Das Ergebnis seht ihr hier in dem Video
View attachment Perimeterboard.mp4
Ich muss noch dazu sagen, dass im Video der rote Draht nur zeigen soll wo in etwa mein Draht unter meinem Teppich her läuft. Das passte nun nicht zu 100%. Ich hoffe dass es im Frühjahr dann auch seinen realen Test draußen besteht.
Das kleine OLED Display habe ich nur für Testzwecke vorgesehen, Die eigentliche Auswertung der Daten erfolgt dann über de I2C Schnittstelle oben rechts im Bild aif meinem Pi. Der D1 MINi macht m.E. einen guten Job. Das lesen und Auswerten der Daten im D/A Wanderler erfordert ca 91us und reicht gerade so aus, um einen Zyklus auszuwerten.
Da ich im Pi alle 200ms meine Sensoren abfrage, habe ich noch genügend Zeit die daten dann auf dem D1 zu glätten und auf plausibilität zu prüfen.
Euch allen einen Guten Rutsch und "Happy new Year"
Vor Weihnachten hat Aisler noch meine PCBs für die Perimeter Erkennung geliefert. Da habe ich gestern eine bestückt und heute gestestet.
Das Ergebnis seht ihr hier in dem Video
View attachment Perimeterboard.mp4
Ich muss noch dazu sagen, dass im Video der rote Draht nur zeigen soll wo in etwa mein Draht unter meinem Teppich her läuft. Das passte nun nicht zu 100%. Ich hoffe dass es im Frühjahr dann auch seinen realen Test draußen besteht.
Das kleine OLED Display habe ich nur für Testzwecke vorgesehen, Die eigentliche Auswertung der Daten erfolgt dann über de I2C Schnittstelle oben rechts im Bild aif meinem Pi. Der D1 MINi macht m.E. einen guten Job. Das lesen und Auswerten der Daten im D/A Wanderler erfordert ca 91us und reicht gerade so aus, um einen Zyklus auszuwerten.
Da ich im Pi alle 200ms meine Sensoren abfrage, habe ich noch genügend Zeit die daten dann auf dem D1 zu glätten und auf plausibilität zu prüfen.
Euch allen einen Guten Rutsch und "Happy new Year"
Attachments
ullisun58
Well-known member
Hallo zusammen,
ich will hier einmal einen kleinen Status abgeben, was in den letzten Monaten sich bei mir und meinem RoπLawnMow so getan hat.
Ich denke dass er seit Dezember schon im Gartenhaus steht und auf seinen ersten Einsatz in der neuen Saison wartet. An den ersten Stellen wächst der Rasen schon ganz gut, aber das Mähen lohnt sich bei mir definitv noch nicht.
Mit dem von mir erstellten Perimeter Board wollte ich eigentlich noch ein paar Tests mit meinem MINI-Modell machen. Das war aber nur bedingt Möglich, da ich noch viele neue Funktionen an der PiMowBot-SW getestet habe. Etwas was ich schon lange vor hatte habe ich dann aber doch noch in den letzten Wochen umgesetzt.
Mit der Kamera im RoπLawnMow und meiner SW will ich mehr machen. Meine SW erkennt wertet den Grünanteil von Sektoren im Bild aus und stößt dann Ausweichmanöver an. Diese Auswertung will ich intelligenter gestalten. Neben den 3 Sektoren die im Moment die Manöver anstoßen will ich noch 6 weitere nutzen. Also nicht nur das was unmittelbar vor dem Mäher passiert erfassen, sondern auch das was bis zu 1-2 m vor ihm ist in die Auswertung einbringen. Alles soll sich aber nur auf die Auswertung der grünen Pixel beziehen, ich will da keine Objekterkennung implementieren. Dazu habe ich mir noch ein kleines experimentier Modell gebaut. Es hat eine Kamera, einen MPU und einen ToF Sensor. Das eigent sich gut um Im Zimmer ein wenig hin und her zu fahren. Warum habe ich dazu nicht mein anderes Testmodell genommen? Nun hier kann ich mal schnell die SD Karte Wechseln, ein anderes OS nehmen und die Unterschiede zwischen Lagacy Kamera Stack und libcam Tools ergründen. Oder auch zusätzliche Beleuchtung für die Fahrt im Dunkeln testen.
Im Moment lerne ich ganz viel im Umgang mit dem HSV Farbraum und der Erkennung von Farben. Um das auszutesten soll das kleine Modell (Projektname "OneEye" automatisch die Farbe des untergrundes erkennen und sich darauf bewegen. Das klappt mittlerweile recht gut. Ich will aber noch das Standard Fahrprogramm und die Ausweichmanöver verbessern.
View attachment OneEyeCV2.mp4
Hier seht ihr wie er sich schon sehr sicher auf dem roten Karton bewegt, Rot geht im Moment besser als Grün, weil sich dieses Rot viel intensiver vom Teppich im HSV Farbraum abhebt als grüner Karton. Mein Ziel für die kommenden Tage ist, das genau so sicher au fGrün hinzubekommen. Mittlerweile habe ich auch die Beleuchtung in Betrieb genommen. Auch ein schöner Test mal mit den LED Strips zu "basteln"
Video folgt dazu sicher bald.
ich will hier einmal einen kleinen Status abgeben, was in den letzten Monaten sich bei mir und meinem RoπLawnMow so getan hat.
Ich denke dass er seit Dezember schon im Gartenhaus steht und auf seinen ersten Einsatz in der neuen Saison wartet. An den ersten Stellen wächst der Rasen schon ganz gut, aber das Mähen lohnt sich bei mir definitv noch nicht.
Mit dem von mir erstellten Perimeter Board wollte ich eigentlich noch ein paar Tests mit meinem MINI-Modell machen. Das war aber nur bedingt Möglich, da ich noch viele neue Funktionen an der PiMowBot-SW getestet habe. Etwas was ich schon lange vor hatte habe ich dann aber doch noch in den letzten Wochen umgesetzt.
Mit der Kamera im RoπLawnMow und meiner SW will ich mehr machen. Meine SW erkennt wertet den Grünanteil von Sektoren im Bild aus und stößt dann Ausweichmanöver an. Diese Auswertung will ich intelligenter gestalten. Neben den 3 Sektoren die im Moment die Manöver anstoßen will ich noch 6 weitere nutzen. Also nicht nur das was unmittelbar vor dem Mäher passiert erfassen, sondern auch das was bis zu 1-2 m vor ihm ist in die Auswertung einbringen. Alles soll sich aber nur auf die Auswertung der grünen Pixel beziehen, ich will da keine Objekterkennung implementieren. Dazu habe ich mir noch ein kleines experimentier Modell gebaut. Es hat eine Kamera, einen MPU und einen ToF Sensor. Das eigent sich gut um Im Zimmer ein wenig hin und her zu fahren. Warum habe ich dazu nicht mein anderes Testmodell genommen? Nun hier kann ich mal schnell die SD Karte Wechseln, ein anderes OS nehmen und die Unterschiede zwischen Lagacy Kamera Stack und libcam Tools ergründen. Oder auch zusätzliche Beleuchtung für die Fahrt im Dunkeln testen.
View attachment OneEyeCV2.mp4
Hier seht ihr wie er sich schon sehr sicher auf dem roten Karton bewegt, Rot geht im Moment besser als Grün, weil sich dieses Rot viel intensiver vom Teppich im HSV Farbraum abhebt als grüner Karton. Mein Ziel für die kommenden Tage ist, das genau so sicher au fGrün hinzubekommen. Mittlerweile habe ich auch die Beleuchtung in Betrieb genommen. Auch ein schöner Test mal mit den LED Strips zu "basteln"
Video folgt dazu sicher bald.
ullisun58
Well-known member
Und heute habe ich es doch noch hinbekommen, dass er sogar bei künstlichem Licht sehr zuverlässig auf dem Karton bleibt. Ihr könnt auch die "Bremslichter" sehen die sind "Knallrot" also fettes (255,0,0) für die LEDs. Wenn das "Fahrlicht" eingeschaltet ist leuchten die hinteren LEDs mit (50,0,0) so kann man auch sehr schön den Unterschied sehen wenn gebremst wird. Eben wie im echten leben 5x heller.
Was ihr nicht sehen könnt ist die Phase bei der er zuerst ein paar Fahrten macht und den Untergrund / das was vor ihm an Farbe ist abscannt. Während dieser Phase lasse ich die "Warnblinkleuchten" blinken
Macht schon Spass ein wenig mit Licht zu spielen, das weiß unser Fürst ja auch
Viel Spass beim Schauen. Code kommt demnächst nach Github, wer vorher was braucht einfach melden.
View attachment Greendetect.mp4
Was ihr nicht sehen könnt ist die Phase bei der er zuerst ein paar Fahrten macht und den Untergrund / das was vor ihm an Farbe ist abscannt. Während dieser Phase lasse ich die "Warnblinkleuchten" blinken
Macht schon Spass ein wenig mit Licht zu spielen, das weiß unser Fürst ja auch
Viel Spass beim Schauen. Code kommt demnächst nach Github, wer vorher was braucht einfach melden.
View attachment Greendetect.mp4
Fürst Ruprecht
Well-known member
Der Rasen wird über den Jahresverlauf seinen Grünton ändern. Das Tageslicht ändert wohl auch den Farbton, der bei der Kamera dann ankommt. Folglich muß wohl der Mäher dann kontinuierlich die Grün-Erkennung anpassen?
In meiner Umgebung geht „zum Glück“ 1/3 meines Grundstücks nahtlos in das Grundstück des Nachbarn über. Rein optisch ist das ein Gewinn für beide, da die Grundstücke damit größer wirken. Ein weiteres Drittel des Rasens hat eine Steinborde (bestens für Kamera geeignet) und das letzte Drittel ist begrenzt durch grüne Büsche.
Somit ist wohl die Anforderung an eine Kameraerkennung recht hoch.
Insofern bin ich gespannt, wie sich das Thema bei Dir weiterentwickelt.
Ich hatte überlegt, ob ich evtl. einen der Mäher in Zukunft mit einer etwas besseren Kamera ausstatte und die Daten dann auf einem potenten PC auswerte. Das sollte gut möglich sein, da der Mäher und das GPS ins wlan eingebunden sind.
Bis dahin versuche ich aber zuerst meine GPS-Ortung stabiler hin zu bekommen.
Gruß Fürst Ruprecht
In meiner Umgebung geht „zum Glück“ 1/3 meines Grundstücks nahtlos in das Grundstück des Nachbarn über. Rein optisch ist das ein Gewinn für beide, da die Grundstücke damit größer wirken. Ein weiteres Drittel des Rasens hat eine Steinborde (bestens für Kamera geeignet) und das letzte Drittel ist begrenzt durch grüne Büsche.
Somit ist wohl die Anforderung an eine Kameraerkennung recht hoch.
Insofern bin ich gespannt, wie sich das Thema bei Dir weiterentwickelt.
Ich hatte überlegt, ob ich evtl. einen der Mäher in Zukunft mit einer etwas besseren Kamera ausstatte und die Daten dann auf einem potenten PC auswerte. Das sollte gut möglich sein, da der Mäher und das GPS ins wlan eingebunden sind.
Bis dahin versuche ich aber zuerst meine GPS-Ortung stabiler hin zu bekommen.
Gruß Fürst Ruprecht
ullisun58
Well-known member
Hallo mein Fürst, schön dass Dich das Thema interessiert, dann habe ich es nicht vergebens gepostet. Ich will dazu demnächst noch ein paar Details zum Konzept publizeiren. Es ist nicht so, -auch wenn dass bei dem grünen Karton vielleicht ginge - dass er eine Farbe als Referenz nimmt. Bei openCV kann man mit Farbräumen arbeiten, also z.B. sehr dunkles grün bis zu ganz hellem grün. Solange sich das was ich vergleiche in diesem Farbraum bewegt wäre alles fein. Kommt er an graue Steine oder etwas anderes was nicht in dem Farbraum liegt, so wird er das merken. Auch dann kann man noch bestimmen, wie er damit umgehen soll, wenn etwas außerhalb des Farbraumes liegt. Da bin ich aber noch am Anfang meines Lernens. Man kann angeblich zusätzlich mit Farb differenzen arbeiten. Das soll dann Sinn machen wenn ein anlysiertes Bild / Frame vielleicht an der Grenze das definierten Farbraumes ist, z.B. braune Blätter im Herbst, oder Erde von Bumenbeeten. Ich habe in den letzten beiden Jahren ja schon sehr erfolgreich mit der Kameraanalyse gemäht, aber gerade im Herbst kam es öfters zu Fehlinterpretationen auf dem Rasen. Die Beete und die Ränder hat er schon sehr gut erkannt. Dennoch hatte ich als Fallschirm mir einen Perimeterdraht gelegt, aber nur einmal um den Rasen herum. Meine Rasenfläche ist aber auch viel kleiner, als in Deinem Fürstentum. Was aber sicher eine Herausforderung wäre, ist wenn die Rasenflächen der Eigentümer eineinander übergehen, und der Nachbar nicht möchte, dass der Mäher aus einem fremden Fürstentum auf seiner Wiese arbeitet.
Mein Ansinnen war eigentlich zu Anfang als ich den OneEye konzipierte die ganze Auswertung auf einem PC / Notebook zu machen und dann nur die Fahrbefehle zurück zu ihm via Socket zu senden. Leider gab es Farbverfälschungen beim streamen der Bildinformation und damit Fehlfunktionen. Wenn ich das ins richtige Leben übertrage, war ich da aber noch in der Grundschule mit der Farbanalyse. Mittlerweile stehe ich kurz vorm Abitur und wenn das alles perfekt auf dem PiZero 2W funktioniert, will ich das mit dem Streamen noch einmal verfolgen. Für die Parxis bei mir aber ungeeignet, da mein Garten nicht Wifi Abdeckung in Summe hat, und ich dazu auch keine SIM Karte verbauen möchte. Also eigentlich eher zum Studium gedacht. Dennoch bin ich zuversichtlich, dass ich auch auf dem PiZero oder bei meinen großen Mähern auf dem Pi4 / P4 sehr gute Ergebnisse erzielen kann.
Gruß
Ulli
ullisun58
Well-known member
Heute noch ein kurzes Update und ein erstes Video mit Hindernissen auf meinem grünem Foto-Karton.
Bei dieser Testfahrt finde ich hat die Bildanalyse schon ganz ordentlich funktioniert. Das braune Packpapier um die Lego Pflanzen soll die Blumenerde simulieren. Natürlich passt das Größenverhältnis nicht, so kommt es schon mal vor, dass er mit dem Heck durch die Pflanzen fährt, aber es soll ja auch nur zeigen, dass die Farberkennung im großen und ganzen schon gut funktioniert. In dem angehängten Bild ist das erste Ausweichmanöver festgehalten. Oben kann man erkennen welchen Farbraum ich zulasse, lower - upper und unten in den roten rectangles kann man sehen welche Farbe er dort erfassst hat. Darüber habe ich die Farbwerte als Farbe dargestellt, da ich mal wissen wollte wie die Farbe dann für das menschliche Auge aussieht.
View attachment OneEye-Camera.mp4
Für mich gibt es jetzt noch 2 wichtige Dinge zu tun:
a Man kann gut erkennen dass er wenn er sich selbst im Licht steht das grün zu sehr abdunkelt. Die Bildanalyse hat ergeben, dass er in Summe das Bild zu dunkel aufnimmt. Das trifft auch für die Stops an den dunkleren grünen Stellen zu. Hierzu muss ich noch die Belichtungszeit automatisch anpassen. Beste Ergebnisse habe ich mit einer Bildhelligkeit von 160 erzielt ( brightness Angabe oben rechts im jpg)
b Im Moment werte ich nur die unteren 3 rectangles vom Bild aus. Sind alle 3 zu wenig grün, muss er wenden ist nur das linke zu wenig grün, korrigiert er nach rechts usw. Das ganze Bild habe ich in 9 Rechtecke aufgeteilt die ich alle auswerten möchte. Damit kann man dann z.B. sinnvolle Manöver definieren. z.B. ist der Linke unten und der in der Mitte unten zu wenig grün, aber alle anderen darüber sind ausreichend grün, handelt es sich wohl eher um ein Blatt vom Baum, oder Moos im Rasen oder, oder. Wenn die ToF Sensoren kein Hindernis erkennen, könnte er so also weiter fahren und müsste nicht die Richtung welchseln.
So viel ersteinmal zu dem aktuellen Status der Bildanalyse basierend auf der PiCamera V1.3 . Ausgewertet wird das Bild mit openCV. Da ich nicht streame, sondern nur das Bild local speicher, es mir aber über einen Fask Webserver auf ein Device bereitstellen lassen kann, benötigt das Script bei einem "PiZero 2W"!! nicht einmal 5% CPU Last. Und ich finde dafür ist das Ergebnis also die Reaktionsgeschwindigkeit Top! Was meint ihr?
Gruß
Ulli
Bei dieser Testfahrt finde ich hat die Bildanalyse schon ganz ordentlich funktioniert. Das braune Packpapier um die Lego Pflanzen soll die Blumenerde simulieren. Natürlich passt das Größenverhältnis nicht, so kommt es schon mal vor, dass er mit dem Heck durch die Pflanzen fährt, aber es soll ja auch nur zeigen, dass die Farberkennung im großen und ganzen schon gut funktioniert. In dem angehängten Bild ist das erste Ausweichmanöver festgehalten. Oben kann man erkennen welchen Farbraum ich zulasse, lower - upper und unten in den roten rectangles kann man sehen welche Farbe er dort erfassst hat. Darüber habe ich die Farbwerte als Farbe dargestellt, da ich mal wissen wollte wie die Farbe dann für das menschliche Auge aussieht.
View attachment OneEye-Camera.mp4
Für mich gibt es jetzt noch 2 wichtige Dinge zu tun:
a
Man kann gut erkennen dass er wenn er sich selbst im Licht steht das grün zu sehr abdunkelt. Die Bildanalyse hat ergeben, dass er in Summe das Bild zu dunkel aufnimmt. Das trifft auch für die Stops an den dunkleren grünen Stellen zu. Hierzu muss ich noch die Belichtungszeit automatisch anpassen. Beste Ergebnisse habe ich mit einer Bildhelligkeit von 160 erzielt ( brightness Angabe oben rechts im jpg)b
Im Moment werte ich nur die unteren 3 rectangles vom Bild aus. Sind alle 3 zu wenig grün, muss er wenden ist nur das linke zu wenig grün, korrigiert er nach rechts usw. Das ganze Bild habe ich in 9 Rechtecke aufgeteilt die ich alle auswerten möchte. Damit kann man dann z.B. sinnvolle Manöver definieren. z.B. ist der Linke unten und der in der Mitte unten zu wenig grün, aber alle anderen darüber sind ausreichend grün, handelt es sich wohl eher um ein Blatt vom Baum, oder Moos im Rasen oder, oder. Wenn die ToF Sensoren kein Hindernis erkennen, könnte er so also weiter fahren und müsste nicht die Richtung welchseln.So viel ersteinmal zu dem aktuellen Status der Bildanalyse basierend auf der PiCamera V1.3 . Ausgewertet wird das Bild mit openCV. Da ich nicht streame, sondern nur das Bild local speicher, es mir aber über einen Fask Webserver auf ein Device bereitstellen lassen kann, benötigt das Script bei einem "PiZero 2W"!! nicht einmal 5% CPU Last. Und ich finde dafür ist das Ergebnis also die Reaktionsgeschwindigkeit Top! Was meint ihr?
Gruß
Ulli
Last edited:
ullisun58
Well-known member
Hallo Sascha. Auf meinem ungepflegten Rasen wollte der Osterhase keine Eier ablegen. Heute habe ich dann mal ein Teil meiner Erkenntnisse aus dem OneEye Projekt auf das Produktivsystem übertragen und getestet. Den Perimter Sender hatte ich nicht in Betrieb, In meiner .ini Datei kann ich dann die Sensorik dafür ausschalten. Daher sind in den Protokoll Bildern auch unten links und rechts die Kreise immer grün. So ist er hier nur nach ToF und Kamera gefahren. Hat seinen Job an den Rändern und an den Beeten ganz gut gemacht finde ich. Man kann in dem Video sehr schön sehen wie er auf hohes Gras vor dem ToF oder bei zu wenig grün vor der Kamera anhält und korrigiert. Es werden zwar 6 ROIs ausgewertet, aber im Moment ist die reaktion des Scriptes nur auf die 3 unteren Rechtecke eingestellt. Das will ich später noch ändern.
Bei jedem Event was ihn zum stoppen bringt macht er ein Schnappschuß und blendet die Farbwerte und die Werte von den ToFs sowie Kompass Wert ein. Bei dem einblenden der ToF Werte ist noch ein Fehler im Script. Das zeigt zu oft 200cm an, obwohl er was anderes gelesen hat. Da muss ich noch mal ran. Es liegt aber eindeutig an der logik wie ich die Werte ins Bild einblende und nicht an den ToFs.
Viel Spaß beim schauen.
View attachment 1st_Mow_2025.mp4
ullisun58
Well-known member
Hallo ich hoffe ihr habt schon gut eure Rasen gemäht.
Bei uns ist es in OWL schon fast zu trocken und er wächst nur noch sehr langsam. Das gab mir mal wieder Zeit noch an der Perimeter Erkennung zu arbeiten.
Ich hatte im Dezember den Perimeter Code von dem STM Board auf ein ESP-32 D1 Board portiert und es gab noch die Herausforderung die Werte auf dem Pi auf Plausibilität zu prüfen. Damit habe ich mich und die KI in den letzten Tagen beschäftig. Heute war dann die Probefahrt. Und es klappte sehr sehr gut. Nachdem es letzte Woche noch einge Fehlinterpretationen gab, hatte ich noch einige Veränderungen vorgenommen. Mit dem Ergebnis bin ich sehr zufrieden. Die KI hat mir z.B. gezeigt wie ich in Pyton farbige print ausgaben realisiseren kann. Das hat zur Optimierung enorm beigetragen. Was ich auch sehr gut finde, dass ich deutlich erkennen kann ob er nahe dem Perimeter Draht ist oder nicht. So habe ich auf meinen Zettel noch eine neue Aufgabe: Ihn in der Nähe des Perimeterdrahtes abzubremsen. Das Video zeigt einen Mitschnitt meines Terminal Fensters. Ist ein Spulen Wert kleiner als -8000 wird "NEAR" erkannt und eine SLOW_DOWN Datei wird erstellt. Der Motorsteuerung muss ich noch beibringen, dass sie dann beide Motore nur mit 80% der Geschwindigkeit bestromt. Sind beide Spulen ungleich NEAR dann wird die Datei gelöscht und die Motoren werden normal bestromt. Ich muss aber noch prüfen ob das funktioniert. Vielleicht muss ich die Logik noch mal ändern, ich muss schauen wie er sich dreht wenn nur mit einer Spule "OUTSIDE" ist, dann wäre auch der Motorstrom geringer.
View attachment Roi-2025-06-09_16.50.17.mp4
Was ich noch sehr charmant finde, dass ich bei den anderen Sensoren die "NEAR" Info noch verwerten kann. Sollte sich der Mäher rechts nah am Draht befinden und der Linke ToF hätte z.B. ausgelöst, so würde er nach jetziger Logik nach rechts ausweichen. Ist aber dumm, weil er dann gleich den Draht findet. So etwas kann dann in der Entscheidungslogik berücksichtigt werden. Also spannender Nachmittag war das heute, ich bin sehr zufrieden. Nochmals vielen Dank an @Bernard, der mich bei der Portierung des Perimeter Codes im letzten Jahr unterstützt hat.
Gruß Ulli
Bei uns ist es in OWL schon fast zu trocken und er wächst nur noch sehr langsam. Das gab mir mal wieder Zeit noch an der Perimeter Erkennung zu arbeiten.
Ich hatte im Dezember den Perimeter Code von dem STM Board auf ein ESP-32 D1 Board portiert und es gab noch die Herausforderung die Werte auf dem Pi auf Plausibilität zu prüfen. Damit habe ich mich und die KI in den letzten Tagen beschäftig. Heute war dann die Probefahrt. Und es klappte sehr sehr gut. Nachdem es letzte Woche noch einge Fehlinterpretationen gab, hatte ich noch einige Veränderungen vorgenommen. Mit dem Ergebnis bin ich sehr zufrieden. Die KI hat mir z.B. gezeigt wie ich in Pyton farbige print ausgaben realisiseren kann. Das hat zur Optimierung enorm beigetragen. Was ich auch sehr gut finde, dass ich deutlich erkennen kann ob er nahe dem Perimeter Draht ist oder nicht. So habe ich auf meinen Zettel noch eine neue Aufgabe: Ihn in der Nähe des Perimeterdrahtes abzubremsen. Das Video zeigt einen Mitschnitt meines Terminal Fensters. Ist ein Spulen Wert kleiner als -8000 wird "NEAR" erkannt und eine SLOW_DOWN Datei wird erstellt. Der Motorsteuerung muss ich noch beibringen, dass sie dann beide Motore nur mit 80% der Geschwindigkeit bestromt. Sind beide Spulen ungleich NEAR dann wird die Datei gelöscht und die Motoren werden normal bestromt. Ich muss aber noch prüfen ob das funktioniert. Vielleicht muss ich die Logik noch mal ändern, ich muss schauen wie er sich dreht wenn nur mit einer Spule "OUTSIDE" ist, dann wäre auch der Motorstrom geringer.
View attachment Roi-2025-06-09_16.50.17.mp4
Was ich noch sehr charmant finde, dass ich bei den anderen Sensoren die "NEAR" Info noch verwerten kann. Sollte sich der Mäher rechts nah am Draht befinden und der Linke ToF hätte z.B. ausgelöst, so würde er nach jetziger Logik nach rechts ausweichen. Ist aber dumm, weil er dann gleich den Draht findet. So etwas kann dann in der Entscheidungslogik berücksichtigt werden. Also spannender Nachmittag war das heute, ich bin sehr zufrieden. Nochmals vielen Dank an @Bernard, der mich bei der Portierung des Perimeter Codes im letzten Jahr unterstützt hat.
Gruß Ulli
ullisun58
Well-known member
Hallo, heute mal wieder was Neues von meinem RoπLawnMow
in der Zwischenzeit habe ich einiges an Greenkeeping in der SW vorgenommen und mein RoπLawnMow hat zwei Bumper für die Hinterräder bekommen, damit er sich nicht mehr an den Baumstämmen festfährt und dann schwindlig wird weil er immer im kreis fährt. Die habe ich mit Microschaltern versehen und so vor die Hinetrräder gebaut, dass der Mäher eigentlich am Baumstamm vorbei gedrückt wird, wenn das nicht klappt, löst dann der Schalter aus und eine Ausweichbewegung wird eingeleitet.
Dann war es heute beu uns stark sonnig und die Bäume haben schön kräftigen Schatten geworfen. Da habe ich dann mal eine Langzeit Sequenz aufgenommen Jedes Video ist 1 Minute lang und ich habe ihn einfach mähen lassen. Mit dem Ergebnis bin ich sehr zufrieden, ich kann ihn bald allein laufen lassen. Was jetzt noch aussteht ist das Spurhalten und ein Bahnen mähen. Dazu will ich mal den BNO085 ausprobieren, hat jemand damit schon Erfahrung gesammelt? Mit der YAW Berechnung von meinem MPU6050 bin ich nicht ganz zufrieden, das kann aber auch an dem von mir geschriebenen Python Code liegen. Mein Ziel ist den Kompass initial zu nutzen um den Wert an den MPU weiter zu geben, und dann nach einer gefahrenen Bahn zu prüfen, ob Kompass und die Werte vom MPU im Rahmen des driftes liegen, wenn die Toleranz es zu lässt, dann liegt keine Fehlablenkung des Kompasses vor und der MPU kann wieder synchronisiert werden. Somit könnte ich mittels ODOMetrie und den MPU/ Kompasswerten schon mal sehr gut die zurück gelegten Strecken ohne RTK aufzeichnen. Später könnte ich sogar noch über zusätzliche Bilderkennung / Vergleiche die Positionierung genauer vornhemen. Also um zu bestimmen wo er noch nicht gemäht hat und noch mähen sollte.
Ja das wäre so mein Plan.
View attachment 2025-07-03 15-15-17.mp4
Alle Videos von heute habe ich in mein onedrive geschoben Mower
manchmal ist er auch nicht zu sehen, dann einfach im Video vorspulen. Wenn das mit dem Link nicht geklappt hat bitte einfach melden
Viel Spaß beim schauen,
in der Zwischenzeit habe ich einiges an Greenkeeping in der SW vorgenommen und mein RoπLawnMow hat zwei Bumper für die Hinterräder bekommen, damit er sich nicht mehr an den Baumstämmen festfährt und dann schwindlig wird weil er immer im kreis fährt. Die habe ich mit Microschaltern versehen und so vor die Hinetrräder gebaut, dass der Mäher eigentlich am Baumstamm vorbei gedrückt wird, wenn das nicht klappt, löst dann der Schalter aus und eine Ausweichbewegung wird eingeleitet.
Dann war es heute beu uns stark sonnig und die Bäume haben schön kräftigen Schatten geworfen. Da habe ich dann mal eine Langzeit Sequenz aufgenommen Jedes Video ist 1 Minute lang und ich habe ihn einfach mähen lassen. Mit dem Ergebnis bin ich sehr zufrieden, ich kann ihn bald allein laufen lassen. Was jetzt noch aussteht ist das Spurhalten und ein Bahnen mähen. Dazu will ich mal den BNO085 ausprobieren, hat jemand damit schon Erfahrung gesammelt? Mit der YAW Berechnung von meinem MPU6050 bin ich nicht ganz zufrieden, das kann aber auch an dem von mir geschriebenen Python Code liegen. Mein Ziel ist den Kompass initial zu nutzen um den Wert an den MPU weiter zu geben, und dann nach einer gefahrenen Bahn zu prüfen, ob Kompass und die Werte vom MPU im Rahmen des driftes liegen, wenn die Toleranz es zu lässt, dann liegt keine Fehlablenkung des Kompasses vor und der MPU kann wieder synchronisiert werden. Somit könnte ich mittels ODOMetrie und den MPU/ Kompasswerten schon mal sehr gut die zurück gelegten Strecken ohne RTK aufzeichnen. Später könnte ich sogar noch über zusätzliche Bilderkennung / Vergleiche die Positionierung genauer vornhemen. Also um zu bestimmen wo er noch nicht gemäht hat und noch mähen sollte.
Ja das wäre so mein Plan.
View attachment 2025-07-03 15-15-17.mp4
Alle Videos von heute habe ich in mein onedrive geschoben Mower
manchmal ist er auch nicht zu sehen, dann einfach im Video vorspulen. Wenn das mit dem Link nicht geklappt hat bitte einfach melden
Viel Spaß beim schauen,
Fürst Ruprecht
Well-known member
sieht aus wie mein Sensor:
Adafruit LSM6DSOX + LIS3MDL 9 DOF IMU
Ich versuche seit Tagen den Sensor zum Laufen zu bekommen, ist bei mir ein echter Job-Stopper.
Von der Programmierung her funktioniert alles auf Anhieb. Aber im Betrieb kommt nur Sch.. raus.
In der Nähe der Ground-Plane vom GPS funktioniert kein Magnetsensor. In der Nähe von den Motoren und Treibern wohl auch nicht.
Vielleicht sollte ich einen Anhänger bauen, nur für den Sensor …
Zumindest habe ich Gestern von ChatGPT gelernt, wie man die Kalibrierungsdaten interpretiert.
Adafruit LSM6DSOX + LIS3MDL 9 DOF IMU
Ich versuche seit Tagen den Sensor zum Laufen zu bekommen, ist bei mir ein echter Job-Stopper.
Von der Programmierung her funktioniert alles auf Anhieb. Aber im Betrieb kommt nur Sch.. raus.
In der Nähe der Ground-Plane vom GPS funktioniert kein Magnetsensor. In der Nähe von den Motoren und Treibern wohl auch nicht.
Vielleicht sollte ich einen Anhänger bauen, nur für den Sensor …
Zumindest habe ich Gestern von ChatGPT gelernt, wie man die Kalibrierungsdaten interpretiert.
ullisun58
Well-known member
Hallo Mein Fürst, Danke für das Teilen Deiner Erfahrung.
hier ein Foto von meinem Sensor
Meine "Kumpels" von X schwören auf den BNO055 der BNO085 ist der Nachfolger ich bin gespannt. Ich habe ihn erst seit 3 Tagen ich wollte aber erst mit der Kombi aus MPU6050 und QMC5883l Erfahrung sammeln und mein Konzept validieren, Bevor ich auch noch die HW austausche, denn mit dem MPU und dem Kompass Modul habe ich bisher immer gearbeitet. Der Kompass ist bei mir einigermaßen stabil es gibt 3 - 5 Stellen im Garten da lenkt ihn was ab, Der Gyro ist sehr sehr stabil den kann ich sehr gut für die Geradeausfahrt verwenden, jedoch ist mein Script noch nicht perfekt für die Drehungen. Erst wenn das so läuft dass ich es nicht verbessern kann, werde ich wohl den BNO085 testen. Dann hätte ich einen validen Vergleich. Meine Erfahrung mit ChatGPT sind nicht schlecht, man sollte aber das eigenständige Denken nicht aufgeben, denn oft verrennt sich ChatGPT bei der Nachbesserung. Aber die Ansätze z.B. für eine Bilderkennung zur Positionsermittlung finde ich sehr gut. Ob es dann was taugt wenn die Kamera hautsächlich auf den Rasen schaut, oder im Frühjahr die Büsche anders aussehen als im Herbst - ich bin gespannt. @Bernard Tipp den Kompass von dem Gyro zu trennen, ist aus meiner Sicht gold richtig. Don't give up
ullisun58
Well-known member
merci!
Fürst Ruprecht
Well-known member
Ich habe gestern noch einen Fehler in meiner imu-Task gefunden. Meine Berechnung des Heading hatte einen Fehler in der Skalierung. Den code hatte ich zum Teil von meinem HMC5883MA übernommen. Dadurch wurden die Signale fälschlicher Weise um den Faktor 100 verkleinert. Den Fehler habe ich nun bereinigt. Im Büro schaffe ich es nicht, 360Grad abzubilden. Mal sehen, was heute im Garten geht.
Mein „Kombi-Sensor“ ist kein BNO085.
Mein „Kombi-Sensor“ ist kein BNO085.
ullisun58
Well-known member
Ein weiterer Unterschied ist denke ich, dass Du in C++ Dein Programm schreibst, ich hingegen in Python, was aber eigentlich keinen Unterschied machen sollte. Gestern Abend habe ich noch das Script von meinem MPU6050 angepasst. heute morgen beim Test draußen hat es schon sehr gut funktioniert. Vielleicht schaffe ich heute auch noch den Kurs vom QMC5883l initial zu übertragen (das geht schon) aber die Berechnung beim drehen passt noch nicht. +-180 das ist für mich immer ein Buchmit 7 Siegeln. Bin gespannt. Bericht mal von Deinen Ergebnissen dann
Gruß
Ulli
Fürst Ruprecht
Well-known member
.. nach weiteren Stunden im Garten: Ergebnis: Mein Kombi-Sensor ist nicht zu gebrauchen. Ab es am Sensor liegt oder meinem verstrahlten Rasen läßt sich nicht sagen. Ich werde mal die beiden anderen Typen ausprobieren.
ullisun58
Well-known member
Danke für den Status. Ich habe heute Abend folgendes heraus gefunden.
Mein Kompass QMC5883l ist ziemlich genau wenn er in Richtung Osten oder in Richtung Westen fährt. Mit meinem überarbeitetem MPU Script bekomme ich ziemlich gut die Drehung berechnet, also könnte ich nach Osten und Westen fahrend den Gyro auf den Kompass wert einstellen und somit den Drift in Schach zu halten. ChatGPT warf dann noch die Idee auf den Kompass während der Fahrt zu kalibrieren. Das würde ich in den nächsten Tagen mal testen.
Ich werde berichten
Mein Kompass QMC5883l ist ziemlich genau wenn er in Richtung Osten oder in Richtung Westen fährt. Mit meinem überarbeitetem MPU Script bekomme ich ziemlich gut die Drehung berechnet, also könnte ich nach Osten und Westen fahrend den Gyro auf den Kompass wert einstellen und somit den Drift in Schach zu halten. ChatGPT warf dann noch die Idee auf den Kompass während der Fahrt zu kalibrieren. Das würde ich in den nächsten Tagen mal testen.
Ich werde berichten
Fürst Ruprecht
Well-known member
Daran habe ich auch schon gedacht. Nur fehlt dann die z-Komponente. Wenn das Gelände eben ist, dann kann das funktionieren. Ist bei mir aber nicht so, daher habe ich das noch nicht probiert.