-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pathplanner: zu viele Irokesen #143
Comments
+1 |
Ja, muss ich mir genauer anschauen |
+1 Es stört ja nicht, wenn der Rover 2x über eine Stelle drüber fährt, aber keinmal ist einmal zu wenig. |
Das Thema ist echt knifflig, habe tatsächlich noch keine simple Lösung für das Problem. Als Übergangslösung schlage ich euch vor distance to border = border laps im Pathplanner auszuwählen |
Du meinst bei distance to border=2 auch border laps=2. So ist es hier eingestellt. Das klappt also nicht., Man könnte 3 border Laps nehmen aber bei unserem komplexen Garten dauert das Mähen einer Fläche gut doppelt so lange. Distance to border zu verringern ergibt bei Alfred keinen Sinn. Dann fährt er gegen alles und jeden. Es gibt ja auch solche Stellen. Da kann man schwierig mit Workarounds arbeiten. In Sunray habe ich mir das einfach zurechtgezogen: |
Den Rechteck links kriege ich denke ich weg, den rechten Rechteck bekommst du mit distance to border = border laps weg. Bei dem mittleren Rechteck bin ich mir nicht sicher was da passiert |
Ah sorry, |
Ja. Das ist ein Problem. Die Idee hatte ich auch. Unser Garten ist jedoch zu komplex dafür. Die Border-Laps sind das, was ohnehin schon prozentual (im Verhältnis zur Fahrdauer) am längsten dauert und die meiste Energie aus dem Akku zieht. Noch eine Runde mehr pro Task ist hier nicht sinnvoll. Ich habe keine Ahnung davon, wie komplex das ist, das im Pathplanner zu lösen. Ich würde mir bloß wünschen, dass es nicht aus dem Fokus verschwindet. :) Manchmal kann man es mit anderen Winkeln lösen. Aber auch das kommt nicht der Effizienzu zu Gute. |
Wie gesagt, erstmal als workaround gedacht. Ich habe das Problem identifiziert, aber habe noch keine 100%e Lösung, ein Teil der Löcher kann ich schon stopfen, aber bei weitem nicht alle. Es ist jetzt als issue dokumentiert, und geht nicht verloren |
Gut, Danke. Wir haben einen Garten mit vielen Ecken und Kanten und ich habe aktuell 20 Stellen, an denen große Irokesen stehen bleiben (und noch viele kleine Ecken). Wenn das Gras nicht so schnell wächst, wie aktuell, dann sieht man es nicht ganz so schlimm (und man kann es eben lösen, in dem man täglich den Winkel wechselt) aber aktuell sieht das echt besch*** aus, da das Gras hier mehrere cm am Tag wächst und es auch nicht überall sinnvoll ist, den Winkel zu wechseln. Allerdings muss ich auch sagen, dass Alfred aktuell mit leicht modifizierter 318 Firmware und vor allem danke Cassandra, einen echt guten Job macht. Von daher ist das alles jammern auf hohem Niveau. Das ist ggf. auch das Problem: Setzt man den Standard hoch, werden auch die Ansprüche immer höher ;) |
Ich kann schon mal das Update pushen, wo zumindest ein Teil der Irokesen verschwinden soll |
Kannst dir auch Zeit lassen. Ich kann das ggf. sowieso erst heute Abend testen. Alfred mäht gerade. |
Gleiche Einstellungen wie vorhin? |
Jap. Gleiche Einstellungen, wie vorhin. Interessant ist, dass es aber offenbar gar nicht an der neuen Version liegt. Ich hatte wieder zurück gerüstet auf den vorherigen Commit und er macht den gleichen Quatsch (auch mit derm ganzen Durcheinander hin und her). Nur der Original Task (jap, gleiche Einstellungen - der existiert schon lange). sieht ordentlich aus (eben mit den Haken an den ein oder anderen Stellen). |
Ich weiß, dass du nicht mehr gerne am Pathplanner fuckelst aber das hier stört mich und dürfte, aus meiner Sicht, auch so nicht sein:
Da fehlt zu viel und es bleibt hier immer eine ganze Menge stehen: So müsste das aussehen (lieber zu viel, als zu wenig):
Wenn du Zeit hast, kannst du dir das ja ggf. nochmal ansehen. Ich habe das auf meiner Map in vielen Bereichen. Du sagst immer, es interessiert nicht, wie die Mähbahnen innerhalb des Perimeters sind. Das stimmt in solchen Fällen eben nur dann, wenn man sicher sein kann, dass alles abgefahren wird und nichts stehen bleibt (und eben der Perimeter nicht ständig für Dinge misbraucht wird, für die er nicht da ist). Hier konnte man in der Sunray App immer schön nachkorrigieren. Da das in Cassandra nicht möglich ist, muss der Pathplanner besser werden (aus meiner Sicht).
The text was updated successfully, but these errors were encountered: