Path Planning und Mauern etc.

[greymfm]

Für die Planung von Verbindungslinien zu den Rändern hin etc. könnte man ggf. folgenden Ansatz wählen:

Immer wenn die Verbindung zum nächsten Verbindungspunkt eine zu große Winkeländerung erfährt (der Roboter zu stark drehen muss) wird ein Stück zurück vom Ende zu der Verbindung ein neues Zwischenziel eingefügt mit z.B. max. 30 Grad Winkeländerung usw. - D.h. starke Winkeländerungen werden durch mehrere kleinere ersetzt. So hätte der Roboter genügend Platz um am Zielpunkt die richtige Orientierung zu haben... Die Idee könnte natürlich auch direkt am Roboter (dynamisch) umgesetzt werden und wäre dann nicht statisch...

[disaster123]

Das ganze ist def. eine Sache für die Sunray FW - ich hatte damit bereits mal angefangen. Das Problem ist doch aber, das man manchmal ebend genau dieses Verhalten nicht habe will - weil es einfach länger dauert.

Ich habe im Video vom Luma (heisst der so) gesehen, dass der tatsächlich vor starken Drehungen immer zurück fährt... ich habe in meiner FW die Basis für solche Dinge bereits gelegt, in dem er generell immer mit WAY_FREE und nicht WAY_MOW fährt, weil ich bereits jetzt zum navigieren Punkte on the Fly statt feste Wegpunkte der Karte nutze.

Für mich ist die Hauptfrage eigentlich, wann erkenne ich diese Situation? Reicht es aus, wenn der Mäher > 60 Grad drehen muss? Kann der Mäher wirklich solch kleine Kurven dann auch sauber fahren? Nicht das man dann ungemähte Flächen hat. Der Luba / Luma oder wie er heißt fährt dann quasi mehrfach vor und zurück - hat aber einfach einen anderen und besseren Antrieb als z.B. Alfred.

[greymfm]

Ein wichtiger Punkt. Beim Mähen ist ja der Weg das Ziel und nicht das Ziel das Ziel :) - Wenn man weitere Sensorik hätte die einem sagen können "hier kommst du ohne weiteren Abstand nicht vorbei" o.ä. hätte man weitere Informationen über die Umgebung. Andernfalls ist ja gerade das starre Festhalten am Pfad gewollt um alles abzumähen...

Abgesehen davon ist obige Perimeter-Erstellung schon nicht optimal, der Benutzer sollte keine 90 Grad Winkel verlegen...

[disaster123]

Naja wäre aber schon cool wenn das alleine in der FW gehandelt wird und nicht der User runde Kanten bauen muss. Auch obstacles können Ecken erzeugen - kann der User gar nicht rund machen ;-)

[EinEinfach]

Ich denke an sowas, beim Aufzeichnen der Karte muss die echte Grenze aufgenommen werden bzw. halbe Mäherbreite von echten Grenze entfernt (in der Regel sitzt die GPS Antenne so auf dem Mäher, dass man den Roboter so an jedem Hindernis positionieren kann) Der Pathplanner erzeugt dann echte Grenze, die auf keinen Fall überschritten werden darf. Als nächstes läuft der coverage Pathplanner los und berechnet die Mähwege, wie das schon heute der Fall ist. Zum Schluss läuft der Optimierer los, dieser kennt den Richtungsvektor und die echten Abmessungen des Rovoters (von der GPS Antenne aus gesehen). Überschreitet der Rovermaaß an irgendeiner Stelle die echte Grenze, muss der Punkt gegen die Richtung des Vektors verschoben werden/zusätzlicher Punkt erzeugt werden/.... und und und, bin mir noch nicht sicher, was genau getan werden soll

[themanfrommoon]

Das die Lubas ein besseres Antriebskonzept haben als 97% aller anderen Mäher halte ich für ein Gerücht. In meinen Augen ist der Luba, insbesondere das Antriebskonzept mit der Panzersteuerung, ein Designfail. ...aber das wird die Zeit zeigen.

[disaster123]

Das die Lubas ein besseres Antriebskonzept haben als 97% aller anderen Mäher halte ich für ein Gerücht. In meinen Augen ist der Luba, insbesondere das Antriebskonzept mit der Panzersteuerung, ein Designfail. ...aber das wird die Zeit zeigen.

ich korrigiere mich - ich meinte nicht den Antrieb - ich meinte einfach nur Motoren. ALfred ist da schon recht schwachbrüstig - gerade was auch seichtere / langsamere Bewegungen angeht. Da fehlt dann komplett die Kraft.

[disaster123]

Ich denke an sowas, beim Aufzeichnen der Karte muss die echte Grenze aufgenommen werden bzw. halbe Mäherbreite von echten Grenze entfernt (in der Regel sitzt die GPS Antenne so auf dem Mäher, dass man den Roboter so an jedem Hindernis positionieren kann) Der Pathplanner erzeugt dann echte Grenze, die auf keinen Fall überschritten werden darf. Als nächstes läuft der coverage Pathplanner los und berechnet die Mähwege, wie das schon heute der Fall ist. Zum Schluss läuft der Optimierer los, dieser kennt den Richtungsvektor und die echten Abmessungen des Rovoters (von der GPS Antenne aus gesehen). Überschreitet der Rovermaaß an irgendeiner Stelle die echte Grenze, muss der Punkt gegen die Richtung des Vektors verschoben werden/zusätzlicher Punkt erzeugt werden/.... und und und, bin mir noch nicht sicher, was genau getan werden soll

Grundsätzlich ja aber - es muss halt zur Laufzeit optimiert werden. Was ist mit hindernissen - doch gegen die Mauer gefahren, weil GPS leicht versetzt usw. das muss der Mäher zur Laufzeit machen. Habe mir da schon einige male den Kopf zerbrochen aber noch keine gute Logik gehabt.

Das Problem fängt ja schon damit an, dass man bei der Berechnung aktuell kein Objekt sondern einen Punkt bewegt... dann wo ist die Drehachse - wo das GPS. Wie wurde aufgezeichnet? Gerade die ecken - wo war zu diesen Zeitpunkt der Empfänger auf dem Mäher....

[disaster123]

Letztendlich - ist es doch so, dass der Mäher aktuell eigentlich immer zu weit fährt. Man stelle sich eine 90° Ecke vor. Der Mäher dürfte ja nur mit der Spitze rein und bis an die "Kante". Der GPS Empfänger (bei Alfred hinten) fährt also gar nicht bis zum Zielpunkt. Dann muss der Mäher da eigentlich auf der Stelle drehen (kann mind. Alfred nicht).

Ich hatte mal angefangen mit einem moved_stateX, moved_stateY zu spielen, der soetwas in der virtuellen Position berücksichtigt. Auf Basis der Mähergröße.

Die Logik war ca. so:

Setze target_reached bereits, wenn der Mäher im Winkel von -5° - 5° zum Zielpunkt steht und die aktuelle Position als Vektor um die Mäherlänge geschoben wird. Der Mäher erreicht dann also in der FW das Ziel bereits mit der Schnauze und nicht mehr mit dem GPS hinterteil.

Die Probleme fangen dann aber an bei: wenn nun rechts eine Mauer ist oder links und der Mäher nun drehen soll - klappt das nicht, weil der hintern noch gar nicht vorbei ist... an der Mauer zum drehen.

Nächste Idee war dann, das ganze NUR anzuwenden, wenn die Schnautze bei dem Scenario den Mähbereich verlässt. Aktuell noch keine Ahnung, welche nächsten Fallstricke dann warten...

[themanfrommoon]

Siehe hier: https://forum.ardumower.de/threads/sunray-advanced-pathfinder.24963/ Im Prinzip ist die Regel so: Fahre soweit aussen wie möglich, aber verletze nie die Grenze.

[themanfrommoon]

Theoretisch muss man die Kontur des Mähers am Perimeter so entlangführen, das immer mindestens zwei Punkte sich berühren, aber gleichzeitig nichts die Grenze überschreitet. Das wäre dann quasi Null auf Null. Jetzt kann man zur Mäherkontur noch 2cm Offset hinzurechnen. Unter den Bedingungen kann man dann zu jeder Position die Antennenposition bestimmen. Man wird feststellen, dass es dadurch mehr Punkte braucht. Das sieht man hier gut:

[EinEinfach]

Grundsätzlich ja aber - es muss halt zur Laufzeit optimiert werden. Was ist mit hindernissen - doch gegen die Mauer gefahren, weil GPS leicht versetzt usw. das muss der Mäher zur Laufzeit machen. Habe mir da schon einige male den Kopf zerbrochen aber noch keine gute Logik gehabt.

Natürlich, es ist ein Zusammenspiel zwischen den Offline Funktionen (Pathplanner) und Online Funktionen (Firmware). Ich meine wenn die Vorarbeit vom Pathplanner gut ist, muss die Firmware umso weniger korrigieren.

[marvin78]

Und als Ergänzung: "Runde Ecken" mit mehreren Punkten sind, gerade bei Alfred mit seinem langen Vorbau, nicht optimal, wenn es um Mauern und Ecken geht. Tatsächlich ist die Wahrscheinlichkeit viel höher, dass er in die Mauer fährt, als wenn er 90 Grad dreht. Das habe ich durch unzählige Tests für mich nachgewiesen. Die Einzige Möglichkeit, dass er einige Stellen optimal mäht, sind 90 Grad Ecken. An den Stellen darf aber eben nicht redundant und dann noch Spitz in den Perimeter gefahren werden. Bei Alfreds Form ist es dann zu 100% klar, dass die Mauer angebumst oder die Blumen im Beet geküpft werden.

[themanfrommoon]

Es gibt ja einige unterschiedliche Konzepte bei den Mähern: Räder vorne, Räder hinten, symmetrisch sowie Mähscheibe links, rechts, mittig, vorne, hinten. Position der GPS Antenne. Auch die Mährichtung spielt eine Rolle. Der Mäher ist ja leider kein Punkt. Der Pfadplaner muss all das berücksichtigen.

[disaster123]

@themanfrommoon theoretisch korrekt aber das wird die aktuelle Sunray FW nicht leisten können und das statisch vorher zu berechnen ich weiß nicht. Das sind für mich eindeutig Entscheidungen zur Laufzeit. Dafür bräuchte es einen großen oder kompletten rework des Sunray FW Codes... und viel Zeit oder Geld...

[themanfrommoon]

Ich glaube, dass das statisch geht. Aber ich glaube, man muss über das Konzept nochmal nachdenken, denn das Thema fängt ja schon bei der Aufnahme des Perimeters an. Auch dort muss die Mähergeometrie bereits bekannt sein. Man muss also unterscheiden zwischen echter physischer Grenze bis zu der der Mäher fahren darf und der Position der Antenne. D.h. wenn man einen Punkt aufnimmt, dann muss man dazu noch die Mähergeometrie rechnen. Das ergibt die physische Begrenzung. Das nenne ich mal Perimeter. Der ist das wichtige bei der Aufnahme der Karte (nicht die Antennenposition!). Wenn man nun die Mähbahnen berechnen will, dann muss dieser Perimeter (die echte physische Grenze) sowie die Mähergeometrie berücksichtigt werden. Daraus kann dann die nötige Antennenposition berechnet werden. Das geht alles statisch. Nur wenn es ein unerwartetes Hindernis gibt muss das Problem zur Laufzeit gelöst werden. Die Größe des Hindernisses wird wohl weiterhin unbekannt bleiben. Da nimmt man irgendeine Annahme, z.B. einen 30cm großen Kreis. Den kann man dann auf der Karte anzeigen. Und nun hat man den Perimeter und den Kreis und kann wieder unter Berücksichtigung der Mähergeometrie da herum fahren.