Silberstreifen
Active member
try and error war erfolgreich. Habe den neuen Code heute Morgen aufgespielt und ausprobiert. Jetzt macht er, was er soll.
Vielen Dank dafür.
Jürgen
Merkwürdiges Wendeverhalten am Bahnende
- Ersteller Silberstreifen
- Erstellt am
Vielen Dank dafür.
Jürgen
disaster123
Active member
MEGA ;-) Sehr cool. Dann würde ich noch ein wenig das ganze aufräumen und dann einen pull request für den offiziellen Code stellen.
FYI: @AlexanderG
FYI: @AlexanderG
disaster123
Active member
@Silberstreifen noch eine Frage - wie "lang" ist so ein Ardumower im standard?
Chassis: 60x36x25cm
Also 60cm lang ist der Deckel, Bumper müsste vorne genauso weit überstehen wie oben der Deckel. Kann aber auch ein wenig Differenz haben.
Danke dir disaster für die Code Anpassung. Hätte es fast gestern auch schon getestet, werde ich diese Woche aber noch machen.
Mir ist gestern aufgefallen, das der Alfred bei der Heimfahrt nicht auf den STOP Button reagiert hat. Ob das beim Ardumower auch ist, muss ich ausprobieren. Sollte aber eigentlich bei beiden Mähern möglich sein das der STOP Button den Mäher auch auf dem Weg zur Dockingstation stoppt. Nur die Liftsensoren beim hochnehmen haben den Alfred angehalten. Vielleicht haben wir da noch eine Sicherheitslücke. Anderseits ist der Mähmotor aus, viel passieren dürfte deshalb nicht.
Also 60cm lang ist der Deckel, Bumper müsste vorne genauso weit überstehen wie oben der Deckel. Kann aber auch ein wenig Differenz haben.
Danke dir disaster für die Code Anpassung. Hätte es fast gestern auch schon getestet, werde ich diese Woche aber noch machen.
Mir ist gestern aufgefallen, das der Alfred bei der Heimfahrt nicht auf den STOP Button reagiert hat. Ob das beim Ardumower auch ist, muss ich ausprobieren. Sollte aber eigentlich bei beiden Mähern möglich sein das der STOP Button den Mäher auch auf dem Weg zur Dockingstation stoppt. Nur die Liftsensoren beim hochnehmen haben den Alfred angehalten. Vielleicht haben wir da noch eine Sicherheitslücke. Anderseits ist der Mähmotor aus, viel passieren dürfte deshalb nicht.
Zuletzt bearbeitet:
Silberstreifen
Active member
noch als Ergänzung:
- Mitte Vorderachse bis Ende Deckel sind 42cm.
- Der Bumper steht ca. 1cm nach vorne raus.
- Dementsprechend Mitte Vorderachse bis Vorderkante Bumper sind 19cm.
Danke, funktioniert bei mir auch.Ist leider echt blödes try and error. Wer mag kann bitte den hier nochmal testen (achtung force push - ein pull reicht nicht aus):
GitHub - disaster123/Sunray at sunray_turn_pref_fixes
Ardumower Sunray. Contribute to disaster123/Sunray development by creating an account on GitHub.github.com
Nur ist der Default 60cm eigentlich zu groß, oder?
Ich habe 36cm eingestellt.
Wenn ich es richtig verstehe, wird MOWER_SIZE 1:1 als zu prüfender Radius eingesetzt und gegen die Perimeter-/Exclusionposition geprüft.
Das hintere Rad dreht beim ArduMower StandardChassis beim Wenden seitlich weg. Von Mitte GPS Receiver bis Ende des seitlich eingeschlagenen Rades sind es ca. 36cm. Das sollte dann als Radius auch locker ausreichen.
Es sind zwar noch ein paar Zentimeter bis zum hinteren Ende der Deckelplatte. Das sollte man aber ignorieren können. Die Perimeterpositionen sind ja auch immer die Positionen des GPS-Empfängers. Man hat also von der Perimeterposition bis zum Ende des fahrbaren Bereiches eh noch die halbe Mehrerbreite Puffer.
Um genau zu arbeiten könnte man also sogar mit MOWER_SIZE auf den Abstand GPS-Empfängermitte <-> Mäherende minus 1/2 * Mäherbreite runtergehen.
Das wäre beim ArduMower dann 43cm - 18cm = 25cm.
Oder habe ich da irgendwo einen Denkfehler?
Silberstreifen
Active member
Das sehe ich genauso. Ich hatte 42cm von der Vorderachse bis Ende des Deckels gemessen. Das ist aber Geschmacksache, ob man das quer stehende Rad nimmt, oder den Deckel. 60cm ist definitiv zu viel.
EDIT: Habe gerade nochmal geguckt. Aktuell habe ich 30cm eingestellt. Damit läuft es bei mir eigentlich ganz zufriedenstellend.
Mr. Tree
Active member
Damit läuft es wahrscheinlich wie zuvor?!
Kann es daran liegen, dass der Mittelpunkt der Drehachse dem Mittelpunkt des GPS Sensors entspricht? Vielleicht wurde das eingebaut bzw. berücksichtigt. Aber das Heck oder die Front (je nachdem wo der Antrieb sitzt) sollte einen eigenen Kreis zum offset der Drehachse haben.. Oder den Mower gleich als Rechteck, und nicht als Kreis behandeln, mit Drehpunkt nicht in der Mitte sondern um die Achse des Antriebs. Wahrscheinlich hat @disaster123 das auch so ersonnen, aber es funktioniert noch nicht so wie gewollt. Es gibt jedenfalls kein #define wo man den Offset des GPS Empfängers zur Drehachse einstellen könnte. Und die GPS Koordinaten des Empfängers ist soweit ich verstehe immer das NonPlusUltra für Drehungen oder allgemein Positionen.
Kurzum, der Gedanke ist super. Aber die Umsetzung ist noch nicht wie erhofft.
Kann es daran liegen, dass der Mittelpunkt der Drehachse dem Mittelpunkt des GPS Sensors entspricht? Vielleicht wurde das eingebaut bzw. berücksichtigt. Aber das Heck oder die Front (je nachdem wo der Antrieb sitzt) sollte einen eigenen Kreis zum offset der Drehachse haben.. Oder den Mower gleich als Rechteck, und nicht als Kreis behandeln, mit Drehpunkt nicht in der Mitte sondern um die Achse des Antriebs. Wahrscheinlich hat @disaster123 das auch so ersonnen, aber es funktioniert noch nicht so wie gewollt. Es gibt jedenfalls kein #define wo man den Offset des GPS Empfängers zur Drehachse einstellen könnte. Und die GPS Koordinaten des Empfängers ist soweit ich verstehe immer das NonPlusUltra für Drehungen oder allgemein Positionen.
Kurzum, der Gedanke ist super. Aber die Umsetzung ist noch nicht wie erhofft.
Zuletzt bearbeitet:
Silberstreifen
Active member
Hm, so ganz kann ich deine Ausführungen und Zusammenfassung nicht nachvollziehen.
Bei mir funktioniert die Funktion von @disaster123 perfekt.
Das GPS sollte unabhängig von der Funktion von @disaster123 immer auf der Drehachse liegen. Ansonsten wird es mit der präzisen Navigation schwierig, da sich bei jeder Drehung auch eine Verschiebung des GPS-Punktes ergibt. Man müsste dann vom tatsächlichen GPS-Punkt auf einen virtuellen Punkt auf der Drehachse rückrechnen, damit die Navigation befriedigend funktioniert.
Bei mir funktioniert die Funktion von @disaster123 perfekt.
Das GPS sollte unabhängig von der Funktion von @disaster123 immer auf der Drehachse liegen. Ansonsten wird es mit der präzisen Navigation schwierig, da sich bei jeder Drehung auch eine Verschiebung des GPS-Punktes ergibt. Man müsste dann vom tatsächlichen GPS-Punkt auf einen virtuellen Punkt auf der Drehachse rückrechnen, damit die Navigation befriedigend funktioniert.
Der GPS Empfänger sollte mittig auf der Antriebsachse verbaut sein. Somit stellt sich diese Position auch als Drehpunkt bei einer Drehung auf der Stelle dar. Von daher passt es in meinen Augen, hierum einen Radius zu legen.
Vielleicht ist MOWER_SIZE hierfür nicht ganz so günstig als Begriff gewählt worden. Man definiert hiermit ja eher den Betrachtungsradius, der möglichst nicht den Perimeter verlassen soll.
Ansonsten sieht es für mich plausibel aus, dass die Funktion tut, was sie tun soll, wenn sie korrekt parametriert wird.
Aber ja: Bei mir verhält sie sich wie vorher in 1.0.230. Ich habe aber auch dort keine Gartendurchquerungen gehabt, weil ich meine Parimetrpunkte und Waypoints bereits da so gelegt hatte, dass seine bevorzugte Richtung zum Ausweichen in die Fläche lief. Und dass er bei einer 90° Ecke am Perimeter diesen mit dem Heck verlassen muss, ist ja auch klar. Das muss ja eingeplant werden. Die Funktion sucht ja nur die Richtung mit der geringsten Überquerung.
Ansonsten müsste man eine komplett anders aufgesetzte Ecke-ausmäh-Funktion aufsetzen, bei der er erst mal in die Ecke mäht, dann dem Perimeter entlang zurücksetzt, geschmeidig in die Kurve fährt und dann noch mal vom 2. Schenkel in die Ecke geht.
Hier soll aber ja nur vermieden werden, dass er sich durch den Perimeter oder eine Exclusion dreht, wenn er es vermeiden könnte.
Vielleicht ist MOWER_SIZE hierfür nicht ganz so günstig als Begriff gewählt worden. Man definiert hiermit ja eher den Betrachtungsradius, der möglichst nicht den Perimeter verlassen soll.
Ansonsten sieht es für mich plausibel aus, dass die Funktion tut, was sie tun soll, wenn sie korrekt parametriert wird.
Aber ja: Bei mir verhält sie sich wie vorher in 1.0.230. Ich habe aber auch dort keine Gartendurchquerungen gehabt, weil ich meine Parimetrpunkte und Waypoints bereits da so gelegt hatte, dass seine bevorzugte Richtung zum Ausweichen in die Fläche lief. Und dass er bei einer 90° Ecke am Perimeter diesen mit dem Heck verlassen muss, ist ja auch klar. Das muss ja eingeplant werden. Die Funktion sucht ja nur die Richtung mit der geringsten Überquerung.
Ansonsten müsste man eine komplett anders aufgesetzte Ecke-ausmäh-Funktion aufsetzen, bei der er erst mal in die Ecke mäht, dann dem Perimeter entlang zurücksetzt, geschmeidig in die Kurve fährt und dann noch mal vom 2. Schenkel in die Ecke geht.
Hier soll aber ja nur vermieden werden, dass er sich durch den Perimeter oder eine Exclusion dreht, wenn er es vermeiden könnte.
Mr. Tree
Active member
Aber wenn der Kreis um die Drehachse ist, dann wird doch völlig ignoriert das der ardumower "vorne" mehr Platz als hinten hat? Wenn die "kollisionsfläche" ein Kreis ist, um den gedreht wird, gibt es immer die gleichen Schnittpunkte mit Punkten, weil der Kollisionskreis keinen Offset zur Drehachse hat?!
Wenn ich den Code richtig interpretiere, wird beim Frontantrieb nur überprüft, wo das Heck entlang läuft. Also wieviele verbotene Punkte es bei einer Linksdrehung überschreitet und wieviele bei einer Rechtsdrehung. Auf die Front wird nicht geschaut. Aber die Sollfunktion kann Disaster garantiert besser erklären.
hab jetzt hier mal den Code der im Masterzweig von Github ist ausprobiert, die Mowersize
habe ich auf 50cm gesetzt (Mittelpunkt GPS bis Heckende sind bei mir 45cm).
Am Bahnende dreht er jetzt gefühlt immer in die richtige Richtung, sehr schön danke!!!
Aber das löst nicht das Problem, dass er mit seinem Heck z.B. mal den Baum streift beim Umfahren von Exclusionen oder sich mit dem Heck an der Mauer verheddert.
Liegt das dann an eher zu spitzen Winkeln der Bahnen die die Sunray-App berechnet oder? Hatte gehoftt, dass sich hier dadurch evlt. auch das Problem behebt.
habe ich auf 50cm gesetzt (Mittelpunkt GPS bis Heckende sind bei mir 45cm).
Am Bahnende dreht er jetzt gefühlt immer in die richtige Richtung, sehr schön danke!!!
Aber das löst nicht das Problem, dass er mit seinem Heck z.B. mal den Baum streift beim Umfahren von Exclusionen oder sich mit dem Heck an der Mauer verheddert.
Liegt das dann an eher zu spitzen Winkeln der Bahnen die die Sunray-App berechnet oder? Hatte gehoftt, dass sich hier dadurch evlt. auch das Problem behebt.
Bei einer Exklusion bin ich mir gerade nicht sicher, weshalb er einen Baum streift. Wenn Du nur einen Kreis um einen Baum hast, sollte er ja in einem Außenkreis darum fahren. Dann dürfte es nicht zum Problem werden. Aber vielleicht trifft in Deiner Exklusionsführung auch der zu spitze Winkel zu.
Grundsätzlich hast Du in Ecken das Problem, dass er genug Platz benötigt, sich auf die neue Richtung zu drehen. Dabei wird er ausschwenken. Unabhängig davon in welche Richtung man dreht, er wird immer aus dem Bereich laufen. Hierfür kannst Du nur durch setzen mehrerer Punkte die Kurve etwas geschmeidiger auslegen oder den Eckpunkt mit ausreichend Abstand legen.
Zusätzlich solltest Du einplanen, dass die Positionsgenauigkeit beim Setzen der Punkte wenige cm zu weit links sein könnte, beim Abfahren dann die Toleranz zu weit rechts. Schon hast Du die doppelte Ungenauigkeit. Ist es Dir wichtig, dass er an einer Stelle nie etwas berührt, musst Du ein paar cm zusätzlichen Puffer einplanen.
Ich habe es auch schon kurz nach dem Einschalten gehabt, dass er zwar mit Fix 2cm Genauigkeit angezeigt hat, aber 10cm versetzt gefahren ist. Das pendelt sich bei mir eigentlich immer ganz gut ein, wenn ich nach dem Einschalten etwas länger warte. Vielleicht hast Du gelegentlich auch solche etwas größeren Ungenauigkeiten?
Das mit dem Eck ausmähen ohne beim Drehen überzuschwenken, könnte man nur sehr aufwändig lösen: Dann müsste man von einer Seite bis ins 90°-Eck mähen, rückwärts fahren, mit geschmeidiger Kurve in die Mähfläche fahren, von der anderen Seite verkehrt herum auf den Perimeter fahren, dann noch einmal von dort vorwärts ins Eck fahren, wieder rückwärts fahren, geschmeidig in die Mähfläche, dort 360° wenden, zurück auf den Perimeter und dann wieder in richtige Richtung weitermähen.
Grundsätzlich hast Du in Ecken das Problem, dass er genug Platz benötigt, sich auf die neue Richtung zu drehen. Dabei wird er ausschwenken. Unabhängig davon in welche Richtung man dreht, er wird immer aus dem Bereich laufen. Hierfür kannst Du nur durch setzen mehrerer Punkte die Kurve etwas geschmeidiger auslegen oder den Eckpunkt mit ausreichend Abstand legen.
Zusätzlich solltest Du einplanen, dass die Positionsgenauigkeit beim Setzen der Punkte wenige cm zu weit links sein könnte, beim Abfahren dann die Toleranz zu weit rechts. Schon hast Du die doppelte Ungenauigkeit. Ist es Dir wichtig, dass er an einer Stelle nie etwas berührt, musst Du ein paar cm zusätzlichen Puffer einplanen.
Ich habe es auch schon kurz nach dem Einschalten gehabt, dass er zwar mit Fix 2cm Genauigkeit angezeigt hat, aber 10cm versetzt gefahren ist. Das pendelt sich bei mir eigentlich immer ganz gut ein, wenn ich nach dem Einschalten etwas länger warte. Vielleicht hast Du gelegentlich auch solche etwas größeren Ungenauigkeiten?
Das mit dem Eck ausmähen ohne beim Drehen überzuschwenken, könnte man nur sehr aufwändig lösen: Dann müsste man von einer Seite bis ins 90°-Eck mähen, rückwärts fahren, mit geschmeidiger Kurve in die Mähfläche fahren, von der anderen Seite verkehrt herum auf den Perimeter fahren, dann noch einmal von dort vorwärts ins Eck fahren, wieder rückwärts fahren, geschmeidig in die Mähfläche, dort 360° wenden, zurück auf den Perimeter und dann wieder in richtige Richtung weitermähen.
hier mal ein Beispiel, ja ich weiß Abstand soll man lassen, habe ich auch realisiert, hatte halt gehofft, dass sich diese Änderung hier vom Code auch auf das Verhalten auswirkt, weil ja hier auch die Länge des Ardumowers berücksichtigt wird und nicht nur wie bisher die Breite.
Man stelle sich die Exlusion hier als fetten Blumentopf Hochbeet oder was auch immer vor, wenn also der Mäher nach links abbiegt, bleibt er halt immer mit dem Heck hängen. Beim Hinfahren löst er durch den spitzen Winkel schon hin und wieder den Bumper aus.
Wenn es ein Kiesbett wäre, hängt er drin ;-)
Naja dann male ich mir die Wege halt wieder selber bzw. nehme die spitzen Winkel raus.
Wie jemand anderes hier schon geschrieben hat, würde ich den Mäher auch noch lange nicht alleine mähen lassen wenn ich nicht zu Hause wäre. Die Hindernisumfahrung gehört hier auch dazu.
Ist halt schade, dass sich am Code wenig ändert, hatte sehr gehofft, dass das Versprechen wenn der Alfred im Verkauf ist es Fortschritte gibt, sich auch die Software und die App verbessert. Aber leider ist im letzten Jahr in meinen Augen wenig passiert.
Finde es ja interessant wenn Alexander hier mal was postet was es für Möglichkeiten mit Bilderkennung und ähnliches gibt, aber mir persönlich wäre wichtiger wenn die jetzige Software ausgereifter werden würde und z.B. die Timersteuerung hinzukäme.
Ich bin auf alle Fälle sehr dankbar, wenn sich hier andere im Code einbringen und ihr wissen teilen, damit die Software weiter kommt!
Man stelle sich die Exlusion hier als fetten Blumentopf Hochbeet oder was auch immer vor, wenn also der Mäher nach links abbiegt, bleibt er halt immer mit dem Heck hängen. Beim Hinfahren löst er durch den spitzen Winkel schon hin und wieder den Bumper aus.
Wenn es ein Kiesbett wäre, hängt er drin ;-)
Naja dann male ich mir die Wege halt wieder selber bzw. nehme die spitzen Winkel raus.
Wie jemand anderes hier schon geschrieben hat, würde ich den Mäher auch noch lange nicht alleine mähen lassen wenn ich nicht zu Hause wäre. Die Hindernisumfahrung gehört hier auch dazu.
Ist halt schade, dass sich am Code wenig ändert, hatte sehr gehofft, dass das Versprechen wenn der Alfred im Verkauf ist es Fortschritte gibt, sich auch die Software und die App verbessert. Aber leider ist im letzten Jahr in meinen Augen wenig passiert.
Finde es ja interessant wenn Alexander hier mal was postet was es für Möglichkeiten mit Bilderkennung und ähnliches gibt, aber mir persönlich wäre wichtiger wenn die jetzige Software ausgereifter werden würde und z.B. die Timersteuerung hinzukäme.
Ich bin auf alle Fälle sehr dankbar, wenn sich hier andere im Code einbringen und ihr wissen teilen, damit die Software weiter kommt!