Ardumower cm-genau und experimentell ohne Schleife betreiben (Sunray Firmware goes RTK)

Hallo,
ein paar Dinge müssten m.E. geändert werden, dann sollte die Berechnung funktionieren:
a) Hier haben sich zwei Exclusions zusammengemogelt (8 und 9):
1590314197139.png
die letzte (9) entfernen: "Record mode: Exclusions" einstellen, dann mit roten Button "-" die letzten beiden Punkte entfernen. Noch ein Hinweis: Exclusions nie zu dicht beieinander legen.
b) Hier schneidet der Perimeter mit sich selbst:
1590314318079.png
diese Überkreuzung entfernen: Das Symbol "[]" auf der Karte anwählen, es ändert sich in "[.]" - In diesem Modus kann man einzelne Punkte anwählen (an der Stelle wiederholt tippen bis rotes Kreuz für Perimeter-Punkt erscheint) und verschieben. Modus wieder verlassen mit erneuter Auswahl des Symbols.
Gruss,
Alexander
 
Zuletzt bearbeitet:
Hallo Alexander,
ich hab die Fehler soweit beseitigt, aber der Calc bei Karte 3 funktioniert noch immer nicht.
(Karte 2 ist derzeit nicht von belang)
Ich glaube beim Aufzeichnen kam mal ein IMU-Fehler; kann das damit zusammenhängen?

Sonst muss ich mir die Arbeit nochmal antun und die Karte neu aufzeichnen.

Vielen dank für deine unermüdliche Arbeit !!!
 
Hallo, geh bitte nochmal auf "Record mode: Exclusion", dann nochmal den roten Minus-Button drücken. Dann sollte "Calc" wieder möglich sein. Es war noch ein Rest einer unvollständigen "Exclusion" vorhanden. Gruss, Alexander
1590336911716.png
 
Supi.... 👍 :)
jetz hats geklappt.

Vielen Dank !!!:D

Hab gesehen, du bist schon eifrig an der Docking-Lösung.
Jetz wird´s perfekt.
 
Hallo,
ich habe heute erfolgreich zwei Flächen mit der aktuellen FW gemäht.
Allerdings kriege ich die IMU nicht ans laufen
Das sieht so aus
 

Anhänge

  • IMG_4806.MOV
    17,1 MB
Es ist auf jeden Fall erstaunlich wie gut sich das GPS Signal hält, selbst unter grossen Bäumen hatte ich nur vereinzelt mal Float.
Evtl. wäre es noch eine Sinnvolle erweiterung dass wenn der Perimeter oder Exclusions nicht gerade nahbei sind, dass dann auch die Geschwindigkeit nicht reduziert wird...

Leider habe ich auch noch verbindungsprobleme über Wlan und Bluetooth. Manchmal funktioniert es einwandfrei und auf einmal bekomme ich keine Verbindung mehr bzw. eine bestehende friert ein. Ich habe als es auftrat mal schnell die Console verbunden und da steht dann immer CRC Error....

MFG Lars
 
Hallo, ich bin neu bei Ardumower und habe gerade PCB 1.3 zusammengebaut.

Ich möchte wissen, wie ich den Sabertooth 2x60A Motorantrieb verwende ?

Vielen Dank
 
Nachdem ich alle HW Probleme gelöst hatte (es ist die Sunray Firmware Stand heute), habe ich heute den ersten Perimeter abgefahren, einige Bäume ausgeschlossen und los sollte es gehen.

Es gibt aber ein paar Probleme, ggf hängt es damit zusammen, wie meine Karte aussieht. Beim Fahren des Perimeters habe ich ca. beim lila Kreuz begonnen. Ich habe sie per ID 9703 geteilt.

Der eine Weg zwischen zwei Wegpunkten geht durch einen Bereich außerhalb der Karte, siehe hier schwarzer Pfeil. Auch scheinen mir diverse Wege in Nord-Sud Richtung nicht optimal zu sein. (Bitte nicht als Vorwurf verstanden sehen!!! Ich bin selbst SW Entwickler und weiß, wie schwierig das Problem zu lösen ist.)

WegPunktProblem.png

Ich habe ihn trotzdem einmal unter Aufsicht starten lassen und er wollte folgendes abfahren. Ich hatte ihn ungefähr beim blauen Pfeil gestartet. Dann ist er losgefahren und wollte zum Wegpunkt (oranges Kreuz beim grünen Pfeil). Anstatt den Perimeter zu umfahren, ist er den schwarzen Weg gefahren und wollte durch unser Gartenhaus (es steht an der schwarz gestrichelte Linie.)

StartProblem.png

Dann habe ich ihn um die Ecke getragen und ihn auf die Wiese in unmittelbarer Nähe dieses Wegpunkts gesetzt. Aber anstatt in Richtung Wegpunkt zu fahren wollte er wieder ins Gartenhaus, siehe Position beim roten Pfeil.

Irgendwann war er dann am besagten Wegpunkt und ist weitergefahren zum nächsten Punkt, schwarzer Pfeil im nächsten Bild. Auf dem Weg zum dritten Punkt (oranges Kreuz beim grünen Pfeil) habe ich ihn dann am Punkt mit dem roten Pfeil aufgehalten.

FahrFehler.png

Desweiteren ist mir aufgefallen, wenn er vor ein Hindernis fährt und die Räder sich nicht mehr drehen, versucht er nicht, sich wieder freizufahren. Kann das die Software noch nicht, oder muß ich noch was tun, damit es funktioniert? (Meine Ultraschall Sensoren habe ich noch nicht montiert.)
 
Idee/Anregung fuer Return to dock:
warum nicht vom User ein virtuelles Suchkabel-Linie festlegen lassen um die Wegfindung ggf effektiver zu gestalten? Dann muesste man lediglich einen Pfad zu dieser Linie suchen ohne Hindernis und dann entlang dieses Pfades zum Dock fahren... ggf als optionales Feature falls automatische Wegfindung situativ bedingt doof faehrt?
P.S Hab nen Sileno Gardena der macht das so, und variiert jedesmal den Abstand um Spurenbildung zu vermeiden...

gruesse
bigcheese
 
@felix: Exklusionen dürfen sich nicht überlappen und der Perimeter darf sich selber auch nicht kreuzen:
Die Firmware und auch die App haben sehr viele Fehler bzw. viele Dinge (noch) nicht umgesetzt: z.B. Hindernisumfahrung (obstacle avoidance) ist noch nicht implementiert:
Das ganze ist ein Prototyp um zu sehen ob RTK eine Lösung für einige (oder sogar viele) wäre, um Erfahrungen zu sammeln und dann nach und nach eine vollständige Software dafür zu bauen... :)
 
Zuletzt bearbeitet:
@bigcheese: So ist es auch angedacht - ein virtuelles Suchkabel (blaue Waypoints) welche im Docking-Punkt (blauer Punkt) enden. Dies ist in Erprobung, muss noch viel getestet und der Programmcode dabei verbessert werden (Stichwort "Robustheit" ....) - letzteres gilt nicht nur für den Docking-Vorgang sondern für das Abfahren der Wegpunkte generell (es fehlt dem Programmcode an Robustheit/Dynamik/Kreativität bei Hindernissen usw.).
 
Hallo,

Ich habe euer Projekt gestern entdeckt und bin begeistert. Mein Viking (Stihl) iMow 632PC läuft zwar ganz gut aber ich habe immer Probleme mit dem GPS Modul und mich ärgerts wenn 95% des Rasens gemäht sind und für die restlichen 5% braucht der Roboter nochmal gleich viel Zeit. Ich bin selbstständiger Soft- und Hardwareentwickler und mich würde es wirklich reizen euch zu helfen, leider lässt das meine derzeitige Auftragslage nicht zu. Ich werde mich jedoch bemühen das Geschehen im Forum zu verfolgen und vielleicht die ein oder andere Idee, wenn es von euch gewünscht wird, beizusteuern.

Die erste Idee hätte ich auch schon:
Das Berechnen des Mähplans hat mich an ein Projekt auf der UNI erinnert. Ihr verwendet ja das kantenparallele Fahren, das und auch das achsenparallele war dort der üblich Ansatz, der aber eine Mänge an Sonderregelungen (Obstacle-Umfahrung, Wegoptimierung, ...) brauchte um gut zu funktionieren. Soweit ich mich erinnern kann wurde das auf folgenden Ansatz umgebaut.

Man nimmt die zu mähende Fläche und legt einen Pixelraster darüber. Jedes pixel hat den gleichen Radius wie das Mähmesser. Die Pixel sich nicht wie bei einem Bild regulär angeordnet, sondern jede zweite Reihe ist um ein halbes Pixel verschoben. Damit kann man die Fläche mit diesen kreisförmigen Pixel so abdecken, dass möglichst wenig Überlappungen entstehen. Dann kommt der Clou der Sache, jedes Pixel das sich in der Mähfläche befindet wird als "zu mähen" markiert und muss somit vom Mäher angefahren werden. Damit ergibt sich ein "traveling salesman problem" für das es ja reichlich fertige Lösungen gibt.
Jedesmal wenn ein Pixel überfahren wird, wird es als "nicht mehr zu mähen" markiert. Werden Obstacles entdeckt so werden die Pixel als "nicht befahrbar" markiert und das "traveling salesman problem" wird erneut berechnet. Somit ergibt sich eine neue Route die nur noch die nicht erreichten Pixel enthält.

Ein großer Vorteil des traveling salesman Algos ist, das der Mäher bei der Station startet und dort auch wieder endet. Nur wenn das mähen unterbrochen wird (Obstacles, Akku laden, ...) dann würde der Mäher dort enden wo er das letzte mal unterbrochen wurde. Darum hatten die auf der UNI eine abgewandelte Form, bei der man das Ziel angeben konnte.

Der Nachteil den ich sehe, ist die benötigte Rechenpower und der Speicher, denn die Berechnung muss am Mäher geschehen und möglichst schnell ablaufen. Immerhin ist das Problem NP schwer.
Ich weiß leider auch nicht wie Sie damals das Problem gelöst haben, dass gewisse Fahrwege nicht erlaubt sind (z.B. Abkürzungen bei konkaven Flächen, überfahren von Obstacles, ...). Aber das sollte zu lösen sein.

Ich hoffe meine Beschreibung war nicht zu wirr und ihr könnt etwas damit anfangen.
 
Hi, was Du meinst ist sowas wie ein Grid-basierter Planner
1593027923117.png

Das ist bisher nicht angedacht weil man dann nicht mehr so schön Patterns und Winkel und Offsets einstellen kann :)

Wir behalten die Idee im Hinderkopf würde ich vorschlagen! ;-)

Gruss,
Alexander
 
Hi,

Wie ich sehe funktioniert euer Algo schon super also gibt es sicher wichtigere Baustellen.

Vielleicht nur zum Hintergrund des UNI-Projektes. Es ging darum für den 3D Druck:
1.) Jede Ebene in einem Zug (ohne abzusetzen) abzufahren und dabei drei Kriterien einzuhalten
* Der Weg sollte möglichst kurz sein
* So wenig wie möglich Richtungsänderungen
* Und vorallem möglichst geringe überlagerungen der Spuren (um nicht zuviel Matereal aufzutragen)
2.) Jede Ebene soll anders abgefahren werden um zu vermeiden das sich Überlagerungen der Spuren summieren und aus Stabilitätsgründen.

Mein Roboter mäht einmal die Woche den Rand und hinterläst mittlerweile deutliche fahrspuhren. Ich denke das wird bei einem Fixen Mähplan auch passieren, darum ist mir auch gleich das UNI-Projekt wieder eingefallen.

Ich hoffe ich finde ein wenig Zeit, dann probiere ich mal einem Prototypen zu bauen, einfach nur um zu schauen ob es funktionieren könnte :)

Grüße
Stefan
 

Anhänge

  • 1593068034287.png
    1593068034287.png
    140,7 KB · Aufrufe: 17
Hallo,

es soll sogar Menschen geben, die viel Wert auf Spuren/Streifen im Rasen legen. Nennt sich dann "Lawn-Striping" :D
Ich sehe das auch nicht als die wichtigste Baustelle an. Das Mähen ist ja zeitlich eher unkritisch, ein paar Minuten längere Laufzeit spielen in den wenigsten Fällen eine Rolle, im Gegensatz zum (gewerblichen) 3D-Druck. Wichtiger ist, dass das System verlässlich funktioniert, keine Treppen abstürzt und am besten noch sinnvoll auf Hindernisse reagiert.
Das Problem mit den Spuren kann man ja auch mit der aktuellen Entwicklung recht einfach verhindern: Durch Winkeländerung der Bahnen, Änderung der Mähbreite oder einem Versatz der Begrenzung (das müsste implementiert werden). Ich denke eine Funktion mit "Variiere den Winkel bei jeder Berechnung um +- xx°" ist sehr einfach zu implementieren und erfüllt den gleichen Zweck.

Gruß Etiene
 
@stefan: klingt alles einleuchtend - eins muss man auch noch berücksichtigen: es gibt ja globale und lokale Planung
Global: wo muss der Roboter überall hin und wie kommt er dort hin
Lokal: wie kommt der Roboter zum nächsten Zielort unter Berücksichtigung von Einschränkungen (Dimension des Mähers, Bewegungsmodell des Mähers, dynamische Hindernisse, GPS-Messfehler usw.)
(Hier mal in Bildern zusammengefasst: https://forum.ardumower.de/threads/...-exploring-brainstorming-loud-thinking.23815/ )
Beispiel für lokale Planung: ein Roboter (mit "rechteckiger Dimension/Größe") steuert auf eine Hauswand zu und soll diese parallel entlang fahren - berücksichtigt er nicht seine Größe bei der Planung (oder z.B. den aktuellen GPS-Messfehler) wird er die Drehung ggf. ständig an der Hauswand versuchen und überall an der Hauswand scheitern (aufgrund seiner Abmaße).
Bei einem 3D-Drucker kann man allein mit globaler Planung auskommen denke ich...
Die globale Planung würde ich ersmal als "gelöst" betrachten - was jetzt noch kommen muss ist lokale Planung um die letzten cm präzise zu meistern (und auch für dynamische Hindernisse).
Gruss,
Alexander
 
Zuletzt bearbeitet:
Hallo Ich habe eine Frage zur Sunray-Firmware. Können wir Sunray ohne odometry (ohne Kodierung) verwenden? Danke schon
 
Oben