RoπLawnMow

[Fürst Ruprecht]

Hallo Ulli,
der esp32-NTRIP-Caster/Client ist fertig und soweit ich bisher testen konnte, läuft er auch stabil. Allerdings ist aktuell nur der Client im Test. Um den Caster zu testen muß ich die Basisstation erst auseinander nehmen und das hat gerade keine Priorität. Den Code habe ich unter separatem Titel eingestellt.
Ich habe noch an der Auswertung meines Feldtests für die Zielsteuerung gearbeitet und noch einen vermutlich „Dicken Hund“ gefunden.
Der nächste Feldtest steht bevor.
Das von Dir angesprochene Bumper-Thema interessiert mich brennend, meine Bumper-Versuche sind bisher alle nicht zufriedenstellend.
Durch die lenkenden Räder vorn hat man größere mechanische Herausforderungen, Man könnte auch sagen es sollte nicht nur ein sehr einfacher und kostengünstiger Mechanismus sein, sondern er muß auch zuverlässig sein und mechanisch halten. Dem werde ich zur Zeit nicht gerecht.
Kannst Du etwas mehr vom Design zeigen? Welche Schalter nutzt Du?
Gruß Fürst Ruprecht

 

[ullisun58]

Hallo Ulli,
der esp32-NTRIP-Caster/Client ist fertig und soweit ich bisher testen konnte, läuft er auch stabil. Allerdings ist aktuell nur der Client im Test. Um den Caster zu testen muß ich die Basisstation erst auseinander nehmen und das hat gerade keine Priorität. Den Code habe ich unter separatem Titel eingestellt.
Ich habe noch an der Auswertung meines Feldtests für die Zielsteuerung gearbeitet und noch einen vermutlich „Dicken Hund“ gefunden.
Der nächste Feldtest steht bevor.
Das von Dir angesprochene Bumper-Thema interessiert mich brennend, meine Bumper-Versuche sind bisher alle nicht zufriedenstellend.
Durch die lenkenden Räder vorn hat man größere mechanische Herausforderungen, Man könnte auch sagen es sollte nicht nur ein sehr einfacher und kostengünstiger Mechanismus sein, sondern er muß auch zuverlässig sein und mechanisch halten. Dem werde ich zur Zeit nicht gerecht.
Kannst Du etwas mehr vom Design zeigen? Welche Schalter nutzt Du?
Gruß Fürst Ruprecht

Hallo mein Fürst,
Ich bereite am Wochenende ein paar Fotos vor und extrahiere aus Fusion 360 den Körper vom Bumpergehäuse und von der grauen flexiblen Stoßstange. Als Taster kamen solche zum einsatz
Was ich noch nicht verstehe: Du schreibst Du hast den Client im Einsatz. Woher beziehst Du denn Deine Korrekturdaten?
Die Definition Ntrip Caster / Client ist mir noch nicht ganz geläufig. RTK-Rover habe ich bei mir im Mäher verbaut und der bekommt die Korrekturdaten derzeit noch vom SAPOS NTRIP Service. Eine Basis Station habe ich auch, aber noch nicht im Einsatz, da ich den finalen Ort noch nicht definiert habe. Das ist bei mir aber alles auf ca 500m² überschaubar.
Gruß
Ulli

 

[ullisun58]

Hier schon mal ein erstes Video von dem montierten Bumper.
Die weiße Verriegelung muss natürlich noch durch einen Bolzen ersetzt werden. Ich denke das wird ein kleiner Stahlstift werden mit denen man Fußleisten befestigt. Dann hatte ich in meinem Fundus noch selbstklebende Kupferfolienstreifen gefunden, den habe ich zum Auflöten der Schalter benutzt. es geht da ganz normaler dünner schaltdraht aber auch. Die Schalter sitzen in einer kleinen Vertiefung, damit sie ein wenig Führung haben, ich habe sie mit einem Tropfen kleber auf dem PETG fixiert. Aber sie werden eigentlich vom Draht / von der Kupferbahn gehalten.Das flexible graue Teil, habe ich aus TPU mit 15% Infill gedruckt. mit 0.4mm Düse und ganz langsam 20mm/s Da habe ich mich an dieser Anleitung orientiert, aber Du hast sicher einen anderen Drucker.
Das andere bereite ich Dir am Wochenende vor.

 

[Silberstreifen]

Der SAPOS NTRIP Service ist dein öffentlicher Caster und dein Rover ist der Client. Mehr brauchst du eigentlich auch nicht. Der SAPOS-Dienst ist inzwischen sehr brauchbar geworden. Als ich damit mal angefangen habe, hat der Dienst noch böse Sprünge verursacht. Das kenne ich heute nicht mehr. Größtes Risiko ist eigentlich die WLAN-Verbindung. Wenn die für längere Zeit abreißt, dann hast du keine Korrektur mehr.
Grüße
Jürgen

 

[ullisun58]

Hallo Ulli,
Kannst Du etwas mehr vom Design zeigen? Welche Schalter nutzt Du?
Gruß Fürst Ruprecht

Hallo mein Fürst,
Hier die Konstruktions / Slicer Dateien
vielleicht dienen sie Dir ein wenig als Anregung. Im Moment wird gerade der 2. Bumper gedruckt. Den will ich dann noch heute montieren.
Gestern habe ich wieder ein paar Testfahrten durchgeführt. Ich verfolge mit meinem RoπLawnMow im Moment ja noch die Strategie die Bahnen vorher im Editor zu definieren, die er dann danach abarbeitet. Stößt er auf ein NoGo Area, berechnet er ein Ausweichzeil und navigiert dahin, hat er es erreicht, dann navigiert er zu dem ursprünglichen Ziel weiter. Das funktioniert soweit gut, ich will es aber noch ein wenig allgemeiner implementieren.
In meiner urspünglichen (onhe RTK) SW-Lösung habe ich mit einer - ich nenne sie - "Drivechain" gearbeitet. Das ist eine Datei da sind Fahrbefehle hinterlegt. Diese Fahrbefehle werden geladen und abgearbeitet. z.B. Für Hindernis vorm linken TOF weiche nach rechts aus.
Für ein Hindernis welches die Kamera in allen Frames erkennt setze zurück weiche dahin aus, wo am meisten grün im Bild ist und setze dann die Vorwärts fahrt fort. So habe ich Dateien wie z.B. ToF-avoid-left und ToF-void-right, Peri avoids Bumper avoids usw. Diese will ich zukünftig immer aus dem jewiligen Script aufrufen, die Motorsteuerung arbeitet das dann einfach ab. Bisher hatte ich dazu ein Zentrales Script welches die Sensoren ausgewertet hat und dann die Entscheidungen getroffen hat. Das war relativ komplex, sowohl die Motorsteuerung als auch das "Mower Script. Beim RTK-Modus habe ich das einfacher implementiert. Da steht einfach das Ziel im Vordergrund und das Erreichen des Ziels ist die Misson. So kann ich dann zukünftig einach Das Ziel annavigieren, erkennt ein ToF ein Hinderniss gibt er es gleich an die Motorsteuerung, die setzt es dann um bis das Ausweichen abgearbeitet ist und er nimmt das ursprüngliche Ziel wieder in Auge. Je nach Betriebsart bekommen die Sensoren eine unterschiedliche Priorität. Perimeter hat immer die höchste Priorität Ich habe nur eine Draht außen rum, da mein RTK nur sekündlich liefert, belasse ich das weiterhin in meinem Konzept. Wenn RTK-Fix vorhanden ist, hat die Camera eine geringe Priorität. Habe ich nur einen RTK-Float mit geringer Qualität bekommt die Kamera eine größere Prioritaät. Das werde ich in der nächsten Zeit mal austesten.
Mit meinem BNO läuft es soweit ganz ordentlich, Im Moment schaue ich immer noch mit dem Auge drauf ob er die Richtige Richtung hat. Wenn ich ihn calibriere bleibt mein RoπLawnMow stehen und setzt seine Fahrt dann fort. Das schöne ist, dass ich das alles beim Pi mit Dateien steuern kann. Was mir aufgefallen ist, dass der BNO aus dem Tritt kommt wenn die Antriebsmotore feststecken, da muss ich noch eine Strombegrenzung einbauen.
Soweit mein Status für heute.
Gruß
Ulli

 

[Fürst Ruprecht]

Hallo Ulli,
danke für Unterlagen, ich schau mir sie an.
Ich habe endlich einen Durchbruch erreicht. Der Mäher navigiert jetzt nachvollziehbar! Ich habe wieder etwas Ingenieurhaftes getan: „Hast du Probleme mit dem Magnet-Kompass -> dann laß ihn weg !!! Mir ist aufgefallen, daß der Stanley-Controller die Navigation aus x/y-Koordinaten berechnet. Also dachte ich mir, bei RTK-Fix oder Genauigkeit besser als 10cm navigiere ich eben nur mit den Positionsdaten. Und siehe da, funktioniert sehr gut.
Ich habe für die sichere Übertragung des NTRIP-Signals noch eine Monster-Wlan-Antenne angeschaft mit 30m Netzwerkkabel. Die habe ich aktuell an einem Fotostativ befestigt und kann sie so teilmobil einsetzen.
Einschränkend muß man allerdings dazusagen, daß für den Fall eines schlechten GPS-Signals und Rückgriff auf Sensorsignale zur Navigation ein Headingsignal erforderlich ist. Die beiden Magnetkompasse liefern aber nach optischer Kalibrierung jetzt recht vernünftige Werte.
Das was Du ansprichst bezüglich Wertigkeit von einzelnen Sensoren will ich über den Kalman-Filter regeln. Im Moment ist er aber deaktiviert, weil einfach im Programm zu viele Einflußgrößen das Gesamtergebnis beeinflußt haben und dadurch die Fehlersuche nicht möglich war.
Heute habe ich mich um das Thema Rangieren gekümmert. Mein Rover dreht nicht auf der Stelle, also muß er wie ein PKW rangieren, damit er nicht zu weit von der vorgegebenen Route abweicht. Feldtest folgt noch.
Gruß Fürst Ruprecht

 

[ullisun58]

Hallo Ulli,
danke für Unterlagen, ich schau mir sie an.
Ich habe endlich einen Durchbruch erreicht. Der Mäher navigiert jetzt nachvollziehbar! Ich habe wieder etwas Ingenieurhaftes getan: „Hast du Probleme mit dem Magnet-Kompass -> dann laß ihn weg !!! Mir ist aufgefallen, daß der Stanley-Controller die Navigation aus x/y-Koordinaten berechnet. Also dachte ich mir, bei RTK-Fix oder Genauigkeit besser als 10cm navigiere ich eben nur mit den Positionsdaten. Und siehe da, funktioniert sehr gut.
Gruß Fürst Ruprecht

Hallo Mein Fürst,
irgendwann musst Du mir mal dein Konzept erklären >>> daß der Stanley-Controller die Navigation aus x/y-Koordinaten berechnet <<<
Ist das was ich bisher noch nicht kenne? Bei mir geben die GeoDaten ein heading aus, und wenn der Mäher schneller als 0.18m/s fährt, dann ist das sehr zuverlässing auch bei RTK-Float, jedoch nicht wenn die Geo Daten "springen", aber das kann ich herausfiltern. Da ich nur jede Sekunde einen Refresh der Lat Lon bekomme, steckt da das heading zwar schon drin, aber ist zum Nachregeln der Richtung nicht brauchbar. Daher snchronisiere ich den Gyro vom BNO085 nach dem Start einmal mit dem Heading von Lat Lon und dann passt das. ich muss nur noch einen Algotytmus finden, wann ich dem Gyro besser nicht vertraue. Bin aber zuversichtlich.
Habe heute den 2. Bumper zusammen gebaut. Nachdem ich den dann angebaut habe kann ich den Bumper für Frontalkontakt aufzeichnen und entwerfen. Übrigens ich finde den fachlichen Austausch mit Dir sehr wertvoll.
Gruß
Ulli

View attachment RightBumper.mp4

 

[Fürst Ruprecht]

Hallo Ulli,
vielen lieben Dank für das „sehr wertvoll“. Ich habe gerade gestern gedacht, man könnte bei passenden Gelegenheiten noch etwas tiefer in die fachlichen Themen einsteigen wie beispielsweise bei der Berechnung der Navigation.
Zum Bumper. Wie bereits berichtet, tue ich mir mit dem Bumper schwer. An Deiner Lösung gefällt mir besonders gut, daß sie wenig Bauraum für den Schaltmechanismus benötigt, beim Einsatz von den Microschaltern wohl auch keine zusätzlichen Federn braucht und immer noch einfach und preisgünstig ist. Ich müsste mir nur noch überlegen, wie robust ich den Träger (bei Dir das schwarze Teil) auslegen muß, damit mein massiger und kräftiger Mäher ihn nicht im Anhalteweg zerstört.
Mein Roter Mäher hat Brushless-Motoren mit 45mm Durchmesser - das war im Nachhinein ein Fehler, weil sie zu viel Strom verbrauchen und die Untersetzung ist eigentlich auch zu hoch gewählt, er ist nämlich arsch-langsam. Die max-Geschwindigkeit liegt so ca. bei 0,3m/s bei Geradeausfahrt. In Kurven entsprechend langsamer. Das ardusimple-RTK liefert 5 Pakete/s. Das Odo-Signal schafft 50 Pakete/s - damit erhält man eine sehr flüssige Navigation. Der Teensy 4.1 ist da wirklich spitze. Durch die schnellen RTK-Signale ist das RTK-Heading vom ardusimple Board nur bei schneller Fahrt überhaupt zu gebrauchen. Das ergibt sich selbst bei RTK-Fix schon aus den Resttoleranzen der x/y-Auflösung. Bei langsamer Fahrt oder Stand also nutzlos. Da Du nur 1 Paket/s auflöst, sollte Dein Heading besser sein. Nur ist 1/s natürlich dann ein handicap weil mit nachgeschalteten Filtern die Trägheit des Systems zunimmt. Ich weiß im Moment noch nicht, ob meine Navigation bei voller Fahrt noch funktioniert. Der Stanley-Controller betrachtet die Ideallinie von Punkt[n-1] zu Punkt[n]. Dann bestimmt er den Abstand vom Rover zum Punkt[n] und den kürzesten Abstand (Lot-Linie) zur Ideallinie. Er steuert also nicht einfach nur zum Zielpunkt (Punkt[n]) sondern er steuert auch so gegen, daß die seitliche Abweichung von der eigentlich vorgegebenen Route, also der Ideallinie reduziert wird. Das hat Vor und Nachteile, deshalb nutze ich auch mehrere Navigationsregler (mindestens 2).
Für die Berechnung kann man ausschließlich auf x/y-Koordinaten zurückgreifen. Wie das genau geht, kannst Du direkt in meinem code nachlesen. Ich habe mir Mühe gegeben, das im code zu dokumentieren.
Die wirkliche Herausforderung beginnt dann mit „kein RTK-Fix“ oder Toleranz > 10cm. Da war/ist mein Ansatz der Kalman-Filter der die unterschiedlichen Signale gemäß ihrem Fehler dann kombiniert und -wenn er funktionier, was nur an einem selbst liegt- dann ein deutlich besseres und ruhigeres „End“-Signal liefert. In der Natur des Kalman-Filters liegt es, daß eigentlich keine weiteren Umschaltvorgänge erforderlich sein sollten. Wie gesagt, wenn es/wir/ich funktionieren. Bei mir funktioniert es noch nicht !
Ich stelle möglichst umgehen den code ein, dann kannst Du mal reinschauen.
Gruß Fürst Ruprecht

 

[Fürst Ruprecht]

Hier findet Ihr mein kleines Programm.

Post in thread '„Charger - my next Project“ inspired by Dodge Charger 1968 + https://designer.microsoft.com/ - by Fürst Ruprecht'

Wednesday at 11:00 AM

Hallo Forum,
da nach langer Zeit meine Software sich endlich wieder Richtung korrektem Verhalten entwickelt, stelle ich Euch hier mal den Arbeitstand ein. In erster Linie könnt Ihr mal sehen, wie das Ganze aussieht und zusammengestellt ist. Ich habe versucht, die Entwicklung etwas zu dokumentieren. Deshalb gibt es diverse .md Dateien die das Projekt erläutern sollen.
Viel Spaß beim Lesen.
Gruß Fürst Ruprecht

• Fürst Ruprecht

• 

 

[ullisun58]

Hallo mein Fürst, gestern habe ich noch einigehilfreiche Beobachtungen bei meinem RoπLawnMow gemacht.
a.) Er hat wieder nach Drehungen die Himmelsrichtung nicht richtig zugeordnet. Da muss ich mir jetzt ein kleines Debug Programm schreiben, welches nur bei den Drehungen Gyro und mag Kurs loggt. Da musste ich an Deine Bemerkung von vor 2 Tagen denken "Wenn der Magnetometer Probleme macht lass ihn weg" Wenn ich mir die GPS Punkte bei drehungen anschaue, dann sollte man eigentlich daraus erkennen können in welche Himmelsrichtung er gerade steht, denn meine Antenne sitzt ca 15cm vor der Hinterachse und eine Drehung beschreibt dann auch einen Kreis in meinem GPS Plott.
b.) Ich habe gestern meine ToFs wieder im Einsatz gehabt, Funktioniert richtig, aber wenn ich GPS Punkte definiert habe die dicht an unserer Garage oder an unseren Hochbeeten liegen, dann melden die ToFs "ausweichen!!" und er kommt schlecht an seinen Zielpunkt
c.) Das Ausweichen um die NoGoAreas mittels vordefiniertem Trip funktioniert besser, als das erstellen von temporären GPS Zwischenzielen.
Werde dann jetzt mal als nächstes wieder die Kamera zuschlaten und Schnappschüsse schießen zu den Zeitpunkten bei denen Ausweichmannöver eingeleitet werden.
Ahh und was ich noch sagen wollte.
Mein Entwicklungsweg beim RoπLawnMow war ja Orientierung haupsächlich durch die Kamera und durch die ToFs. Später kam dann der Kompass hinzu. Also letztendlich war das sehr zufallsgetrieben, wo er gemäht hat. Einfaches GPS war da auch nicht hilfreich. Durch das RTK hingegen ist mein Ziel nun nicht ein Zentimeter genaues abmähen des Grases Bahn für Bahn, sondern ich würde meine Fläche in Sektoren einteilen. Dann kann er die Sektoren Mähen, beurteilen, wo er bisher noch nicht gemäht hat und sich dann darauf focusieren. Hat er den Sektor abgearbeitet, dann nimmt er sich den nächsten vor. Das hat den Vorteil, dass er nicht randomized die gesamte Fläche mäht, sondern die Zonen. Da kann man ihm dann noch vorzugsrichtungen vorgeben. Aber im Moment bin ich mit diesem Ergebnis was ich jetzt habe schon sehr zufrieden.
Noch was zum Teensy. Ich habe den Teensy 4.0 bei mir eingeabut, der "schnüffelt" am Perimeter draht. Ist aber im Moment genau wie die Kamera abgeschaltet. Ist ein wenig kleiner als der 4.1, aber was die AD Wandler betrifft genauso stark. Die Magvalues vom Teensy übertrage ich per I2C an den Pi und werte dort dann nur noch In- oder Out Fence aus. Da ich letztens mal Probleme mit den ToFs hatte (war aber ein Bug im Programm) war meine Überlegung auf Ultrasonic Sensoren umzustellen. Mein Pi hat aber nicht mehr genügen freie GPIOs, daher hätte ich dann dem Teensy noch die Auswertung der Sensoren aufgebürdet. Das würde er sicherlich auch noch problemlos schaffen. Sicher eine Option wenn ich über meinen Allrad angetriebenes BobyCar im nächsten Projekt denke. Aber da kommt auch ein RTK Empfänger rein, und im Moment funktioniert Inboundary und Outboundary mit dem RTK sehr sehr zuverlässig. Ich kann durch den anstellwinkel auch sehen, in welche Richtung er an der Grenze entlangfährt und könnte dann auch passend ausweichen. ALso gibt noch ne Menge zu tun im Fürstentum
Bis dahin Erfolgreiche Zeit!
Gruß
Ulli

 

[Sascha]

Schöne Austausch
Ich habe seid ein paar Wochen den Ecovacs RTK800, der hat am Bahnende auch immer wieder Probleme sich in die richtige Richtung zu drehen.
Er dreht erst in die eine Richtung um dann festzustellen, das die Richtung falsch war und dreht dann in die andere Richtung.
Meinen Alfred habe ich aktuell eingemottet, da ich dort mit der Portierung auf Linux nicht weiter gekommen bin und keine Lust mehr hatte zu basteln, habe genug andere Projekte zu Zeit.

Aber schön, das es noch Leute wie euch gibt, die weiter basteln. Danke

 

[ullisun58]

Schöne Austausch
Ich habe seid ein paar Wochen den Ecovacs RTK800, der hat am Bahnende auch immer wieder Probleme sich in die richtige Richtung zu drehen.
Er dreht erst in die eine Richtung um dann festzustellen, das die Richtung falsch war und dreht dann in die andere Richtung.
Meinen Alfred habe ich aktuell eingemottet, da ich dort mit der Portierung auf Linux nicht weiter gekommen bin und keine Lust mehr hatte zu basteln, habe genug andere Projekte zu Zeit.

Aber schön, das es noch Leute wie euch gibt, die weiter basteln. Danke

Hallo Sascha,
danke für Dein Feedback, Ja Foren leben von dem Ausstasuch, das kann kein ChatGPT ersetzen. Was das drehen betrifft, so will ich bei meinem Nächsten Test mal protokolliere, ob der GPS-RTK Punkt beim drehen eine Auswerte Information sein könnte. Bei mir sitzt die GPS Antenne in höhe des Messermotors, Wenn sich der Mäher wendet, dann beschreiben die GPS Punkte einen Kreis. Man müsste dann eigentlich nur loggen ab wenn die Distanz zum Ziel wieder größer wird, dann wäre man mit dem Drehpunkt schon über der richtigen Stelle drüber weg, würde kurz in die entgegengesetzte Richtung zurück drehen und dann losfahren. Damit könnte man u.U. auf die Werte vom Gyroskop beim Drehen verzischten. Bin gespannt was bei dem Test herauskommt. Zur Portierung von Alfred nach Linux, da bin ich inzwischen überzegt, dass sich nicht alles portieren lässt. Die Perimeterdraht Erkennung funktioniert nur 100% mit einem Teensy. Meine ganzen alternativen sind mehr oder weniger gute Kompromisse, aber kein vergleichbarer ersatz. So habe ich mir jetzt dafür ein Teensy 3.0 PCB mit den Vorverstärkern fertigen lassen . Kommt aber wegen den RTK-Tests derzeit nicht zum Einsatz, also wird nicht ausgewertet. Und wenn man ein Teensy im Einsatz hat, könnten die Abstandssensoren auch noch einbezogen werden, dann idelt der Teensy nicht nur rum und spart dann beim Pi einiges an GPIOs.
Datenaustausch zwischen Pi und Teensy funktioniert über I2C zuverlässig.
Beste Grüße
Ulli