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

Hallo Lars,
ich würde erstmal ohne WLAN und ohne IMU Modul betreiben - den Mäher aufbocken wie in dem Video und dann per Bluetooth BLE für 5-10 Minuten "in der Luft" bedienen. Dabei die Entfernung zwischen Handy und Mäher immer weiter vergrößern und schauen wie weit alles stabil läuft.
Wenn das einwandfrei und für längere Zeit stabil läuft das ganze auf den Boden testen. Wenn das läuft nach und nach ein Modul einsetzen (nicht alle gleichzeitig). Evtl. sind es ja nur Kabel die nicht festsitzen. Oder die Bluetooth-Reichweite ist stark eingeschränkt... (dann Bluetooth-Modul weiter nach außen/oben verlagern)


Gruss,
Alexander
 
Hello, hmm genau das Video muss ich irgendwie verpasst haben... Ich habe vorhin auch tatsächlich eine Weile gebraucht bis ich eine Karte hatte... Jetzt habe ich leider noch ein anderes Problem dazubekommen welches mich vom testen abhält. Mir ist vorhin gleich zu Beginn ein Motortreiber abgebrannt. Und zwar richtig, mit Feuer und allem was dazugehört. Ich hatte keine Kühlkörper drauf und dachte das wäre mein Fehler gewesen... Dann habe ich den vom Mähmotor eingesetzt da ich den Mähmotor eh noch nicht angeschlossen hatte. Dort habe ich mit einer grossen Unterlegscheibe und einer grossen Mutter und viel Kleber eine meiner Ansicht nach gute Kühlung geschaffen... Jetzt ist mir nach einer Weile testerei aber auch der zweite Treiber abgebrannt. Da es jedesmal die gleiche Seite war und ich ja auch das Problem mit dem ruckigen Antrieb hatte wo ich zwischenzeitlich schon gemerkt habe dass dies eigentlich nur eine Seite betrifft wollte ich den Motor tauschen. Dabei habe ich festgestellt dass die Verbindungen zum Motor nur lose anlagen und es dort bereits ordentlich gespratzelt hatte... Ich gehe mal davon aus, dass das die Ursache für die gestorbenen Treiber war und evtl. auch noch für mehr... Ich habe das jetzt schön gemacht und warte auf neue Motortreiber...

MFG Lars
 
Wen es interessiert, so sieht das aus mit Wackelkontakten an den Motorkabeln... Ich ärgere mich gerade dass ich da nicht eher drauf gekommen bin... 😒

Edit: Jetzt etwas komprimierter...
 

Anhänge

  • IMG_4665.MP4
    12,7 MB
Zuletzt bearbeitet:
Hallo Alexander,
das ist mal eine tolle Weiterentwicklung des Projekts! Ich habe meinen Ardumower jetzt seit fast 5 Jahren am Laufen. Schon seit der Anfangsphase habe ich mit meinem Perimeter Probleme. Die Probleme haben aber eher mit der Verlegung und der Vegetation zu tun als mit der Technik. Die Technik arbeitet tadellos. Der Draht liegt teilweise zu dicht an Hindernissen oder die Winkel sind zu spitz sodass ich eigentlich noch das Perimetertracking verwendet habe um in die Garage zu kommen. Ich habe den Mower immer vor die Garage an den Perimeter gesetzt und nur die letzten Meter das Tracking verwendet. Klar hätte ich den Perimeter optimieren können. Ich hab aber irgendwie immer andere Prioritäten gehabt ;) .

Wenn bedarf besteht könnte ich bei der Entwicklung unterstützen. Bin schon länger nicht mehr im Forum aktiv gewesen aber habe mit den neuen Möglichkeiten wieder richtig Lust mit einzusteigen.

Ich habe gesehen dass die Software (https://evothings.com) mit der Du das App erstellt hast eingestellt wird? Hat das irgendwelche Auswirkungen wenn die ihren Server zum 1.Juli herunterfahren?

Ich werde wohl demnächst mal eine Bestellung an Markus auslösen wenn ich das geld zusammen haben. Mein Mower läuft bereits mit DUE auf Board 1.3 und ein IMU ist auch drin. Ich würde auch die Lösung mit nur einem Empfänger (NTRIP) vorziehen. Ist für mich als Niedersachse kostenlos und ich habe ohnehin schon flächendeckend WLAN im Garten da ich bereits seit einigen Jahren das Webinterface für den ESP welches ich entwickelt habe und einen Pi im Mower nutze
Bis ich den Empfänger habe bleibt mir wohl nichts anderes übrig als mir hier und bei Skype die Fortschritte anzusehen die die Software macht.

Viele Grüße und weiter so!
Kilian
 
Hallo Kilian,
noch ist alles sehr experimentell und für nur eine Entwickler-Person ist diese Entwicklungsaufgabe eine riesen Herausforderung.
Die Einstellung der Entwicklungs-Software "Evothings" hat keinen Einfluss auf unsere Entwicklung, wir nutzen einen eigenen Server und eigene Entwicklungstools.
Gruss,
Alexander
 
Hallo,
nachdem heute Mittag meine neuen Motortreiber kamen konnte ich heute eine ganze Menge testen. Ich habe mir nochmal die aktuelle Version aus dem Github gezogen und die Paar kleinen Anpassungen bzgl. meines Antriebes und der Odometrie gemacht. Letztesmal lag mein Problem definitiv an den lockeren
Kabelschuhen an den Motoren (Dadruch ist wohl auch damals die Originalplatine gestorben)

Die Odometrie läuft überigends aktuell mit dem CHANGE Interrupt mit 120 Imulsen pro Raddrehung, auf dem Oszilloskop siehts perfekt aus...
Bei geradeausfahrt eiert der Rover dabei etwas hin und her, aufgrund der wenigen Impulse werde ich das aber wohl auch nicht besser hinbekommen
ausser die Odometriesensoren umzubauen...

Ich habe dann mehrfach einfach Quadrate aufgezeichnet und abfahren lassen. Mein Rover ist im Vergleich zum Ardumower recht schwer und träge was
anscheinend dazu führt, dass er beim Rollen in eine neue Richtung erst garnicht will und dann überdreht was manchmal in einem hin und her endet.

Dann ist der RL1000 ja recht lang, also die Antenne muss ja mittig über der Radachse sitzen, von da habe ich dann noch locker 40cm nach vorne. Ich habe
mal einen Perimeter nach an einer Wand (und Tür) lang aufgezeichnet, der Rover hat dann später aus einem anderen Winkel eine Position nach an der
Wand anfahren wollen und ist voll dagegen gedonnert. Der Ardumower von dir Alexander hängt doch vorne auch recht weit über, hast du das Problem da auch
mit Perimetern nah an Hindernissen und steilen Anfahrwinkeln?

Was ich irgendwie nicht hinbekomme ist die Einstellung mit der Absoluten GPS Position über NTRIP. Nach jedem neustart musste ich zum testen einen neuen Bereich
aufzeichnen weil ich mit dem vorherigen daneben lag. Wenn ich von Relativ auf Absolut umgestellt habe im Menü war ich quasi ganz weit weg, also dann standen da 7-stellige Positionsdaten in der Oberfläche. Müsste es da nicht so etwas wie einen Nullpunkt-Schalter geben?

MFG Lars
 
Zuletzt bearbeitet:
Hallo Lars,
Wegpunkte werden aus steilen Anfahrweinkeln angefahren: das Problem habe ich auch und muss derzeit an Hindernissen mindestens Abstand zum Wenden einplanen. Das wird im Wegplaner noch verbessert, d.h. der Wegplaner verwendet dann z.B. immer 2 benachbarte Punkte (daraus ergibt sich ein Winkel) und verwendet dann nur diesen Anfahrwinkel um zu diesem Punkt zu gelangen.

Absolute Position: Du suchst Dir für Deine Adresse eine beliebige GPS-Position (Lat, Lon) heraus und gibst diese ein - die errechnete relative Position hierzu (also aktuelle GPS-Position abzüglich der eingestellten absoluten) wird dann für alle Koordinaten in den Karten verwendet.
z.B. hiermit: https://www.latlong.net/
Die ausgesuchte Ursprungs-Position (bzw. Nullposition) wird bei jedem Verbinden vom Handy in den Mäher übertragen.
Grus,
Alexander
 
Zuletzt bearbeitet:
Hi, funktioniert jetzt. Mein Fehler lag ganz einfach darin das ich immer lon und lat vertauscht hab... 😖

Die Anzeige für Fix und Float, wie hoch sollten die sekunden dort typischerweise
maximal laufen? Ich habe manchmal 0 und 0,1s, meistens aber eher 0,7-2s. Kann das mit der Internetverbindung des NTRIP Moduls zusammenhängen? Auf der Testfläche habe ich nur einen Access Point der per WLAN Brücke die Verbindung herstellt und der Ping ist etwas instabil...

MFG Lars
 
Hallo Lars,
maximale "Latenz" von 2 Sek. ist völlig normal in so einer Umgebung und habe ich hier auch- damit kann man gut Leben bei den Korrekturdaten.
Gruss,
Alexander
 
Ich habe mein Testquadrat mehrfach abgefahren gehabt, irgendwie war der Rover bei geradeausfahrt immer am hin und herschwanken und bei Drehungen hat er sich schwer getan. Manchmal hatte ich sogar das Gefühl, dass er sich erst in die falsche Richtung drehte... Ansonsten hat er oft übersteuert. Ich hatte das auf die Odometrie geschoben...

Jetzt habe ich mal das IMU Modul angezogen. Und auf einfach fährt er Spurtreu geradeaus und die Wendemanöver sind viel sauberer...

Einbaurichtung ist doch ok oder? Und nach dem was ich gelesen hab ist die Position egal... Oder muss der auch mittig auf die achse?

MFG Lars
 

Anhänge

  • 6D77CF20-43C9-44B7-A357-11BA0BC91732.jpeg
    6D77CF20-43C9-44B7-A357-11BA0BC91732.jpeg
    1,1 MB · Aufrufe: 40
Zuletzt bearbeitet:
Hallo nochmal,

ich habe jetzt diverse Sachen getestet, an sich ist das ganze schon recht vielversprechend. Um mich in die Materie einzuarbeiten habe ich versucht die Logik dahingehend zu Optimieren dass das ganze etwas dynamischer wird. Ich glaube der Original Ardumower ist gut darin auf der Stelle zu drehen und flott zu beschleunigen. Das ist bei meinem ja alles etwas träger. Der RL1000 fährt bis knapp 4kmh schnell, ich habe die Routinen für die Verlangsamung bei wegpunkt Anfahrt und Abfahrt verändert, das ging ganz gut. Dann habe ich oft wegpunkte mitten auf einer fast geraden Linie gehabt wo er dann auch immer stoppte, da gucke ich jetzt ob der Winkel zum übernächsten Wegpunkt <10 Grad ist und lasse ihn durchfahren ohne zu verzögern.
So richtig habe ich das Motormanagement noch nicht im Griff, manchmal macht er eine Vollbremsung mit blockierenden Rädern und manchmal auch einen Kavaliersstart...
Jetzt muss ich regenbedingt leider erstmal aufhören...

Was auf jeden Fall 1A Funktioniert ist die Positionsbestimmung, ich habe aktuell noch nichteinmal eine Platte unter der Antenne.

Für die Geschichte mit dem Randabstand, am Perimeterkabel mähende Mäher fahren ja zu Beginn einmal langsam den Perimeter ab und beim Chaosmähen überfahren sie diesen so gut wie garnicht... Evtl. wäre das auch hier die Lösung, aktuell und so wie ich es gesehen habe wird der Perimeter auch mal mitten in der Map angefahren was bei meinem Vorbau dann einen gewaltigen Sicherheitsabstand benötigt...

Dazu habe ich mit meinem Brummer das Problem, dass die Map, sowohl im Lines sowie im Rings Modus ziemlich viele kurzstrecken in engen Winkeln zeichnet und das beim mähen lange aufhält die anzufahren. Wenn ich manuell eine Karte zeichnen würde würde ich eine Art spirale zeichnen die immer enger wird, überschneidungen wären ja auch kein Problem.

Und wenn sich für den Algorythmus der Abstand der Linien einstellen liesse wär auch noch super, meiner hat ja 52cm Schnittbreite 😬

Auf jeden Fall bin ich Zuversichtlich dass das ne gute Lösung wird 👍

MFG Lars
 
Hallo Lars,

der Mähversatz lässt sich jetzt Einstellen (Menüpunkt ganz unten "mow offset", Ardumower verwendet 0.18m) - das mit der Spirale werde ich mal ausprobieren. Auch wären viel "weichere" Kurven möglich, dann allerdings würden deutlich mehr Wegpunkte produziert und die lassen sich nicht mehr in akzeptabler Zeit über Bluetooth übertragen (nur noch über WLAN). Aber das liesse sich ja optional gestalten...

Mit einem derzeitigen "Workaround" (bis der automatische Wegplaner das auch kann) lässt sich das Problem mit dem Randabstand evtl. lösen: man kann über eine neu angelegte, getrennte Karte (Switch map) manuelle "Waypoints" (Record mode: waypoints) dort entlang legen wo der Mäher zu viel Abstand lassen musste (nacheinander um Gegenstände usw.) und diese Waypoint-Karte dann getrennt regelmäßig abfahren lassen. Man hat dann also eine Flächen-Karte (links) und eine getrennte Karte mit manuellen Waypoints für Stellen welche bei der automatischen Wegplanung fehlen (rechts).
1589154307298.png 1589154266962.png
Hilfreich um den Abstand von Perimeter-Punkten im Nachhinein zu ändern: Bereits gesetzte Punkte kann man anwählen (rotes Kreuz) und nachträglich im Punkte-Verschiebemodus ("<.>") verschieben:
1589154996849.png
Achso: Könntest Du Deine Karten einmal "teilen" (Share map) und mir die ID mitteilen (die Karten enthalten übrings nur relative Koordinaten bezogen auf die Referenzstation, keine GPS-Koordinaten). Dann könnte ich die Karten zukünftig bei Verbesserungen der Wegplanung mit ausprobieren.
Gruss,
Alexander
 
Zuletzt bearbeitet:
Mit einem derzeitigen "Workaround" (bis der automatische Wegplaner das auch kann) lässt sich das Problem mit dem Randabstand evtl. lösen: man kann über eine neu angelegte, getrennte Karte (Switch map) manuelle "Waypoints" (Record mode: waypoints) dort entlang legen wo der Mäher zu viel Abstand lassen musste (nacheinander um Gegenstände usw.) und diese Waypoint-Karte dann getrennt regelmäßig abfahren lassen. Man hat dann also eine Flächen-Karte (links) und eine getrennte Karte mit manuellen Waypoints für Stellen welche bei der automatischen Wegplanung fehlen (rechts).

Hallo,
Wäre es nicht eine gute Idee, die Fläche und die Ränder zu trennen? Also das virtuelle Perimeterkabel und die Hindernisse umfahren (ähnlich wie dein manueller Ansatz, vielleicht auch mehrmals, um einen breiteren Abstand zu haben) und bei der restlichen Fläche genügend Abstand zu den Hindernissen zu halten?
Vorteil wäre, dass die Ränder immer im gleichen Winkel angefahren werden und man deshalb geringer Abstände nutzen kann.
Außerdem könnte der Mäher beim Bahnenmähen zum Wenden größere Radien fahren und muss nicht zwangsläufig auf der Stelle drehen (besser für den Rasen)

Gruß Etienne
 
Hallo Etienne, ist im Prinzip schon so umgesetzt worden- allerdings wurden die Anfahrwinkel zum Umfahren der Hindernisse (bisher) außer Acht gelassen und ggf. könnte man auch mehrmals umfahren wie Du schreibst. Das muss man also im Detail verbessern.
Gruss,
Alexander
 
Hallo,

aktuell existiert doch in der App ein Koordinatensatz für Parameter, exclusions und Map, also 3stk. in der App. Und auf den Mäher wird nur Map übertragen, also der Mäher fährt stumpf die Koordinaten der Map ab ohne zu wissen ob es der Perimeter oder so ist. Wäre da da nicht denkbar diese Daten tatsächlich auf den Mäher zu übertragen, sodass es ein Array Perimeter gibt welches er zuerst mit reduzierter Geschwindigkeit und so abfährt und danach erst zur Map übergeht. Das wäre dann eher so wie bei den aktuellen Mählösungen bzw. beschreibt auch das was du mit der zweiten Karte mit den wayponts rätst.

Oder halt wie ich schonmal gedacht hatte das eine Map Array auf dem Mäher lassen, dafür aber neben x/y koordinate einen zusätzlichen Wert, binär codiert oder so, worüber der mäher dann weis ob es der Perimeter, eine Exclusion oder halt auch eine Strecke ist der er mit ausgeschaltetem mähwerk befahren soll, dann noch zwei 3 bits für die geschwindigkeit oder so.

Ist auch nur so eine Idee, und es muss ja auch einfach zu Integrieren sein. Ich habe leider fast ausschliesslich Flächen mit "harten" Begrenzungen sprich Beton, Steine, Zäunen etc. dazu der "grosse" Mäher der bei einem Sicherheitsabstand den ich für den Perimeter einhalten muss dazu führt, dass aussen eine ganze menge stehenbleibt.

Gibt es eigendlich aktuell so etwas wie eine TODO Liste? Bzw. irgendetwas wobei man unterstützen könnte oder was getestet werden muss?

MFG Lars
 
Hallo,

jetzt am Wochenende komme ich mal wieder ans testen. Mein Rover verhält sich bei grösseren Strecken und Bögen gut, bei engeren Geschichten hat er probleme.
Wenn die Winkeldifferenz zum nächsten Ziel so gros ist, dass er sich erst drehen will, dann dreht er entweder zu weit oder zu wenig. Jetzt hatte ich gedacht, beim Drehen zum Ziel hin wäre es doch das Zuverlässigste dafür nur die Information der IMU zu verweden.
Ich dachte das bekomme ich schnell ausprobiert, aber irgendwie kappt das nicht.

In computeRobotState gibt es ja 3 Variablen:
stateDeltaGPS
stateDeltaIMU
deltaOdometry
Diese werden je nach bedingung zusammengerechnet und ergeben: stateDelta

In controlRobotVelocity wird dann nur noch stateDelta verwendet.
Ich hatte gedacht, ich kann einfach bei der drehung stateDeltaIMU verwenden, aber dann dreht er sich endlos im Kreis.

Jetzt habe ich mir die Variablen in eine Testausgabe eingebaut, während der Mower sich auf dem Boden im Kreis dreht sehen
die Inhalte der Variablen folgendermassen aus:
stateDeltaGPS = 0.00
stateDeltaIMU = 0.09 - 0.12
deltaOdometry = -0.00
stateDelta = 2.74 - 2.80

Im controlRobotVelocity Sub errechnet sich aus den geringen veränderungen an stateDelta ein Sinnvolles diffDelta -2.87 - 2.20

Jetzt versuche ich seit Stunden die zusammenhänge zu erkennen...
Ich bin ursprünglich davon ausgegangen, dass die 3 Einganswerte die gleiche Basis haben und einfach über sie gemittelt wird.
Scheint aber nicht so...

Wo ist mein Denkfehler?
 
Hallo Lars,

ich kann auch nur den Code lesen und versuchen, ihn zu verstehen. Alle Angaben also ohne Gewähr.
stateDeltaGPS = 0.00
stateDeltaIMU = 0.09 - 0.12
deltaOdometry = -0.00
Diese Werte werden unter verschiedenen Bedingungen berechnet.
Code:
if ((dist > 0.3) || (resetLastPos)){
      resetLastPos = false;
      lastPosN = posN;
      lastPosE = posE;
    } else if (dist > 0.1){     
      if (fabs(motor.linearSpeedSet) > 0){       
        stateDeltaGPS = scalePI(atan2(posN-lastPosN, posE-lastPosE));   
        //stateDeltaGPS = scalePI(2*PI-gps.heading+PI/2);
        float diffDelta = distancePI(stateDelta, stateDeltaGPS);                 
        if (fabs(diffDelta/PI*180) > 45){
          stateDelta = stateDeltaGPS;

stateDeltaGPS -> bei GPS Lösung (float oder fix) und dist zwischen 0.1 und 0.3. Dist ist der Durchschnitt der Distanz die die Räder zurückgelegt haben. Während der Mower sich im Kreis dreht sind die Rotationen entgegengesetzt, dist 0 und dementsprechend sollte stateDeltaGPS nicht berechnet werdet.
Code:
  if (imuFound){
    // IMU available
    stateDelta = scalePI(stateDelta + stateDeltaIMU );  
    stateDeltaIMU = 0;
  } else {
    // odometry
    stateDelta = scalePI(stateDelta + deltaOdometry);  
  }
Also in meinen Augen wird beim Drehen im Kreis ausschließlich stateDeltaIMU verwendet, sobald der Mower die IMU findet. Die Odometrie dürfte also in meinen Augen für den Winkel nicht verwendet werden.

@greymfm76
Kann es sein, dass unter bestimmten Voraussetzungen
erst
stateDelta = stateDeltaGPS;
und später
stateDelta = scalePI(stateDelta + stateDeltaIMU );
gesetzt werden. Also der Winkel, der vom GPS "genau" bestimmt wurde, durch das IMU wieder verfälscht wird?
Ich habe leider (noch) keinen Ardumower, kann es also nicht richtig nachvollziehen.

Gruß Etienne
 
Hi,
mit IMU: Winkeländerung (stateDeltaIMU) und Kurs (stateDelta) wird über IMU berechnet
ohne IMU: Winkeländerung (deltaOdometry) und Kurs (stateDelta) wird über Räder berechnet
mit GPS: allmähliche Korrektur des Kurses (stateDelta) über Komplementärfilter
ohne GPS: keine Korrektur des Kurses

Prinzip Komplementärfilter: über einen Tiefpass und einen Hochpass werden zwei Sensoren fusioniert:
1. Der etwas ungenaue GPS-Kurs (stateDeltaGPS), langfristig aber genau
2. Der sehr genaue Kurs ohne GPS (stateDelta), langfristig aber ungenau
So erhält man einen Kurs der kurzfristig und langfristig sehr genau ist. Das ist eigentlich alles, mehr steckt nicht dahinter ;-)
Gruss,
Alexander
 
Zuletzt bearbeitet:
Danke für die schnelle Antwort und die Kommentare im Code!

Okay, ich hatte auf jeden Fall einen Denkfehler
"dist" wird mehrmals definiert (Zeile 375 und 396), das hat mich auf jeden Fall verwirrt!
Außerdem wird die Zeile stateDelta = stateDeltaGPS; ja nur aufgerufen, wenn die absolute Winkeldifferenz > 45° ist, also der Mower mit seiner "Winkelschätzung" völlig vom GPS-Wert abweicht. Es wäre wahrscheinlich trotzdem sinnvoll hier stateDeltaIMU = 0; einzufügen, da in diesem Fall der GPS-Kurs das "richtigste" ist und nicht noch durch den Gierwinkel korrigiert werden muss. DIe Auswirkungen sollten aber minimal sein und im Fahrbetrieb keine Rolle spielen.

Gruß
 
Guten Morgen liebe Leut,
Ich hab gestern meine Maps geändert (Exclusions) und dann wollte die App keine Mähpunkte mehr berechnen. (CalcMap)
Leider kann ich keinen Grund dafür finden.
In der Console kommt:

calc map
map calc busy=>return

Könnt mir bitte wer weiterhelfen?
(ID 1208)

Ansonsten läuft der Mäher sehr gut.
Hab ihm zu ein wenig mehr Ausdauer verholfen und den Akku vom EBike 48V/10Ah mithilfe eines DC-DC-Wandlers angeknubbelt....;)
So hat er genug Reserven für meine 2x 500m².
Meine "ExtendedVersion" ist auch schon in Planung. Dann soll die ganze Fläche als Ganzes "bedient" werden.

Schönen Sonntag wünsch ich Allen:)
 
Oben