ullisun58
Well-known member
Dann viel Spaß beim Schauen, your fürstliches Feedback is welcome.
RoπLawnMow
- Thread starter ullisun58
- Start date
Fürst Ruprecht
Well-known member
Sieht gut aus !
Für die Ebene auf jeden Fall eine brauchbare Lösung. Ich vermute, die Zackenräder an der Hinterachse brauchst du für die nötige Traktion, damit der Rover vorn dreht. Hier würde das Mecanum Wheel wahrscheinlich mit zusätzlichem, seitlichen Moment noch etwas zum Wendemanöver beitragen. Das zusätzliche Gewicht von deinem Aufbau wird diesbezüglich auch noch einmal interessant. Das kann helfen durch mehr Andruck, aber auch schaden - das wird man sehen.
Bei mir ist leider der alte/leise 3D-Drucker ausgefallen, mit dem ich die TPU-Räder drucken wollte. Ich habe 3 Varianten bisher probiert, alle 3 sind leider nicht zielführend - ich werde berichten.
Die letzten Tage habe ich die Navigation von 5Hz auf 10Hz erhöht und noch versucht Quantifizierungs-„Fehler“ zu bereinigen - also Integer raus und durch Float ersetzen um möglichst geschmeidige Regelung zu bekommen - Feldtest steht aus.
Na dann bin ich mal gespannt auf dein Gesamtergebnis.
Vielleicht wird man dich ja zum Ritter des Allradmähens schlagen - warten wirs ab.
Gruß Fürst Ruprecht
Für die Ebene auf jeden Fall eine brauchbare Lösung. Ich vermute, die Zackenräder an der Hinterachse brauchst du für die nötige Traktion, damit der Rover vorn dreht. Hier würde das Mecanum Wheel wahrscheinlich mit zusätzlichem, seitlichen Moment noch etwas zum Wendemanöver beitragen. Das zusätzliche Gewicht von deinem Aufbau wird diesbezüglich auch noch einmal interessant. Das kann helfen durch mehr Andruck, aber auch schaden - das wird man sehen.
Bei mir ist leider der alte/leise 3D-Drucker ausgefallen, mit dem ich die TPU-Räder drucken wollte. Ich habe 3 Varianten bisher probiert, alle 3 sind leider nicht zielführend - ich werde berichten.
Die letzten Tage habe ich die Navigation von 5Hz auf 10Hz erhöht und noch versucht Quantifizierungs-„Fehler“ zu bereinigen - also Integer raus und durch Float ersetzen um möglichst geschmeidige Regelung zu bekommen - Feldtest steht aus.
Na dann bin ich mal gespannt auf dein Gesamtergebnis.
Vielleicht wird man dich ja zum Ritter des Allradmähens schlagen - warten wirs ab.
Gruß Fürst Ruprecht
ullisun58
Well-known member
Die Zackenräder an der Hinterachse sind noch aus der 2 Rad Antriebszeit. Ich werde die mal abbauen wenn das Gesamtgewicht auf die Räder drückt. Ich denke aber die Hinterräder müssen einen gewissen Grip haben. Ein normales BobyCar Rad muss ja nur rollen. Ein Ausfall meines 3D Druckers wäre für mich ein Albtraum. Auch wenn er nur klein ist. Für mich unverzichtbar.
Was ich bei Deiner Navigation noch nicht ganz verstehe. Dein "Arnold" fährt doch sehr langsam - jedenfalls auf den Videos die ich bisher gesehen habe - Du kämst doch locker mit 1Hz update Rate aus, oder? Wie viele cm legt Arnold in einer Sekunde zurück? 5 Hz wären da doch schon super genau, oder habe ich da einen Knoten im Kopf?
Gruß & schönen entspannten kühlen Sonntag.
Fürst Ruprecht
Well-known member
Der Rover fährt grundsätzlich sehr langsam, weil der Fürst eine zu hohe Übersetzung des Getriebes ausgewählt hat. Fährt der Rover von allein ist das nicht schlimm, fährt der Fürst von Hand, ist er dann meistens genervt.
Maximalgeschwindigkeit ist 0,3m/s. Bei 5Hz = 200ms fährt der Rover 6 cm weit. Allerdings kommt die Koordinaten-Differenz nur zu einem Teil in der Lenkung an - dazwischen liegen Lenksignalglättung, Regler-Eingriffsglättung, Antriebs-Glättung, Kalmanfilter. Selbst das GPS-Signal hat eine Schwankung. Das bedeutet, der Rover fährt also schon eine deutlich größere Strecke als es die Werte im ersten Moment Glauben machen. Bei langsamer Fahrt, wie auf dem Video mit ca 50%, sind das vielleicht 15cm Fahrstrecke in der Realität und bisher 20cm Toleranzvorgabe. Da sieht man, welche Reaktionsgeschwindigkeit dann erforderlich ist. Auf ebener Strecke funktioniert das gut. Ich habe versucht, die Mittelwertbilder und Filter auf möglichst kleine Werte (zB. =3) zu reduzieren und jetzt noch die verloren gegangene Genauigkeit bei Umrechnungen von Float zu Integer zu eliminieren, das hat auch deutlich die Genauigkeit beim Abfahren der Maurerschnur erhöht. Dennoch läßt sich das nicht beliebig steigern, weil sonst die Lenkung anfängt zu flattern und das mechanisch das Fahrwerk überlastet. Es geht schneller aber dann zu Lasten der Genauigkeit. Bei steigender Geschwindigkeit ist die Herausforderung die Parameter so zu wählen, daß man exakt zwischen Schwingen um und Abtriften von der Ideallinie liegt. Mit der bisherigen Geschwindigkeit kann man mähen, aber einen guten Eindruck macht das nicht. Im Moment sieht man ein Ruckeln des Antriebs, was auf die vielen Lenkbewegungen zurück zu führen ist. (Den Effekt von Integer zu Float habe ich noch nicht gesehen.) Ich denke, die Maurerschnur legt da schon die Schwächen offen. Normalerweise sieht man vielleicht, daß der Rover nicht so genau auf einer Linie fährt aber wie weit er abweicht läßt sich schwer einschätzen. Der große Unterschied bei diesem/n Konzept/en ist, daß der Rover gezielt von Punkt zu Punkt fährt. Bei den kommerziellen Mähern ist das (vermutlich) anders geregelt. Die fahren schöne gerade Bahnen und achten auf Grenzen. Ob die Bahn jetzt seitlich versetzt ist, spielt weniger eine Rolle.
Ich denke darüber nach, ob ich die Odometrie stärker berücksichtigen soll um gerade Linien zu fahren, aber das ist mit dem Lenkungsprinzip eine große Herausforderung. Hätte ich einen Servo an der Lenkung (so einen, der >100€ kostet und nur einen Tag hält) dann wäre die viel steifer und würde nicht durch kleine Steine, Mulden usw. seitlich verzogen/ausgelenkt, was dann sofort wieder korrigiert werden muß. Es ist aber auch zu überlegen, ob der Mäher nur gerade Linien fahren muß. Es wäre auch denkbar, die Fahrstrecke über mehrere Wegpunkte in Kurvenfahrt zu berechnen. Das wollte ich zum aktuellen Zeitpunkt nicht, weil ich dann nicht die wirkliche Genauigkeit abschätzen kann.
Die Azurite-Software vom Ardumower pendelt bei der Fahrt entlang des Perimeters permanent um den Draht. Für mich war/ist die Geschwindigkeit der Hinterachs-getriebenen Mäher beeindruckend. Das habe ich mit der lenkenden Vorderachse nur sehr kurze Zeit abbilden können. Mit Servoantrieb ist der Servo so im Dauerstreß, daß er innerhalb einer Stunde das zeitliche segnet, ohne Servo müssen die Räder so hart angesteuert werden (also bei der recht hohen Fahrgeschwindigkeit) daß das einen Eindruck eines Schlagschraubers vermittelt. Daran ist auch mein Antrieb mit Schrittmotoren gescheitert. Die Schrittmotoren haben manchmal bei hoher Last zB. am Hang Schritte verloren, trotzdem hat der Mäher gut funktioniert. Aber die Schrittimpluse haben sowohl die Kunststoffräder zerlegt, als auch alle Befestigungselement auf den Achsen. Dauerthema war Rad kaputt oder Rad verloren -> Projekt eingestellt, Mäher geschlachtet.
Mein blauer Mäher - ChargerFR oder Prototyp-5 ist jetzt auf dem neusten Stand. Er hat noch nie den Rasen gesehen. Er fährt deutlich schneller als der rote Mäher - Arnold (der Starke) oder Prototyp-4. Morgen werde ich den roten aktualisieren und dann mit beiden mal Testfahrten absolvieren. Ich werde berichten.
Es grüßt
Fürst Ruprecht
Maximalgeschwindigkeit ist 0,3m/s. Bei 5Hz = 200ms fährt der Rover 6 cm weit. Allerdings kommt die Koordinaten-Differenz nur zu einem Teil in der Lenkung an - dazwischen liegen Lenksignalglättung, Regler-Eingriffsglättung, Antriebs-Glättung, Kalmanfilter. Selbst das GPS-Signal hat eine Schwankung. Das bedeutet, der Rover fährt also schon eine deutlich größere Strecke als es die Werte im ersten Moment Glauben machen. Bei langsamer Fahrt, wie auf dem Video mit ca 50%, sind das vielleicht 15cm Fahrstrecke in der Realität und bisher 20cm Toleranzvorgabe. Da sieht man, welche Reaktionsgeschwindigkeit dann erforderlich ist. Auf ebener Strecke funktioniert das gut. Ich habe versucht, die Mittelwertbilder und Filter auf möglichst kleine Werte (zB. =3) zu reduzieren und jetzt noch die verloren gegangene Genauigkeit bei Umrechnungen von Float zu Integer zu eliminieren, das hat auch deutlich die Genauigkeit beim Abfahren der Maurerschnur erhöht. Dennoch läßt sich das nicht beliebig steigern, weil sonst die Lenkung anfängt zu flattern und das mechanisch das Fahrwerk überlastet. Es geht schneller aber dann zu Lasten der Genauigkeit. Bei steigender Geschwindigkeit ist die Herausforderung die Parameter so zu wählen, daß man exakt zwischen Schwingen um und Abtriften von der Ideallinie liegt. Mit der bisherigen Geschwindigkeit kann man mähen, aber einen guten Eindruck macht das nicht. Im Moment sieht man ein Ruckeln des Antriebs, was auf die vielen Lenkbewegungen zurück zu führen ist. (Den Effekt von Integer zu Float habe ich noch nicht gesehen.) Ich denke, die Maurerschnur legt da schon die Schwächen offen. Normalerweise sieht man vielleicht, daß der Rover nicht so genau auf einer Linie fährt aber wie weit er abweicht läßt sich schwer einschätzen. Der große Unterschied bei diesem/n Konzept/en ist, daß der Rover gezielt von Punkt zu Punkt fährt. Bei den kommerziellen Mähern ist das (vermutlich) anders geregelt. Die fahren schöne gerade Bahnen und achten auf Grenzen. Ob die Bahn jetzt seitlich versetzt ist, spielt weniger eine Rolle.
Ich denke darüber nach, ob ich die Odometrie stärker berücksichtigen soll um gerade Linien zu fahren, aber das ist mit dem Lenkungsprinzip eine große Herausforderung. Hätte ich einen Servo an der Lenkung (so einen, der >100€ kostet und nur einen Tag hält) dann wäre die viel steifer und würde nicht durch kleine Steine, Mulden usw. seitlich verzogen/ausgelenkt, was dann sofort wieder korrigiert werden muß. Es ist aber auch zu überlegen, ob der Mäher nur gerade Linien fahren muß. Es wäre auch denkbar, die Fahrstrecke über mehrere Wegpunkte in Kurvenfahrt zu berechnen. Das wollte ich zum aktuellen Zeitpunkt nicht, weil ich dann nicht die wirkliche Genauigkeit abschätzen kann.
Die Azurite-Software vom Ardumower pendelt bei der Fahrt entlang des Perimeters permanent um den Draht. Für mich war/ist die Geschwindigkeit der Hinterachs-getriebenen Mäher beeindruckend. Das habe ich mit der lenkenden Vorderachse nur sehr kurze Zeit abbilden können. Mit Servoantrieb ist der Servo so im Dauerstreß, daß er innerhalb einer Stunde das zeitliche segnet, ohne Servo müssen die Räder so hart angesteuert werden (also bei der recht hohen Fahrgeschwindigkeit) daß das einen Eindruck eines Schlagschraubers vermittelt. Daran ist auch mein Antrieb mit Schrittmotoren gescheitert. Die Schrittmotoren haben manchmal bei hoher Last zB. am Hang Schritte verloren, trotzdem hat der Mäher gut funktioniert. Aber die Schrittimpluse haben sowohl die Kunststoffräder zerlegt, als auch alle Befestigungselement auf den Achsen. Dauerthema war Rad kaputt oder Rad verloren -> Projekt eingestellt, Mäher geschlachtet.
Mein blauer Mäher - ChargerFR oder Prototyp-5 ist jetzt auf dem neusten Stand. Er hat noch nie den Rasen gesehen. Er fährt deutlich schneller als der rote Mäher - Arnold (der Starke) oder Prototyp-4. Morgen werde ich den roten aktualisieren und dann mit beiden mal Testfahrten absolvieren. Ich werde berichten.
Es grüßt
Fürst Ruprecht
Last edited:
Fürst Ruprecht
Well-known member
Ulli,
ich hätte da mal eine Frage zu Deinem Heading. Wie berechnest Du das Heading? Nimmst Du es aus dem Sensor ohne nachgelagerte Verarbeitung oder durchläuft es eine Tilt- oder Mahony-Filterung? Wenn ja, wie hoch ist deine Abtastfrequenz und wie sind deine Verarbeitungsparameter?
Gruß Fürst Ruprecht
ich hätte da mal eine Frage zu Deinem Heading. Wie berechnest Du das Heading? Nimmst Du es aus dem Sensor ohne nachgelagerte Verarbeitung oder durchläuft es eine Tilt- oder Mahony-Filterung? Wenn ja, wie hoch ist deine Abtastfrequenz und wie sind deine Verarbeitungsparameter?
Gruß Fürst Ruprecht
ullisun58
Well-known member
Beim Heading (meine Definition: Das ist die Ausrichtung des Mähers gemäß Kompass / Himmelsrichtung) da mache ich folgendes.
Beim Einschalten wrd der BNO085 kurz kalibiriert. i.d.R klappt das schon ohne Bewegung, der BNO ist da sehr gut. Ist er kalibriert, dann wird der Wert vom Kompass als GyroKurs festgesetzt (Zeile 251 in der BNO085.py). Ab diesem Zeitpunkt arbeite ich nur noch mit dem Gyro weiter.
Danach wird alle 200ms dieser Wert in die /dev/shm/bno_heading Datei geschrieben. Mit diesem Wert arbeitet meine Navigation rtk_navi.py als Heading Wert wenn der Mäher sich nicht bewegen würde.
Nun stellt aber das RTK Modul fest, dass sich der Mäher bewegt wenn er los fährt und schneller als 15cm/s aber das Delta aus den letzten Positionen kleiner als 0.8m ist (das kann passieren wenn er zwischen RTK-Fixed und RTK-Float hin und her springen würde dann kann das delta schon mal größer sein und würde einen flaschen heading wert liefern.) dann passiert folgendes: In die Datei /dev/shm/gyro.kurs wird der rtk-heading wert geschrieben.
Und damit arbeitet nun der Gyro weiter und stellt ja alle 200ms fest ob sich die Ausrichtung ändert, und schreibt dann seinen aktuellen Wert wieder in die bno_heading Datei. Das ist stabiler, als wenn ich mit dem rtk-heading wert arbeiten würde, der wird ja bei mir im Moment durch mein RTK-Modul nur jede Sekunde aktualisiert. Die rtk_navi.py schaut dann wieder in der bno_heading nach welchen Wert dort steht. Sie hat aus der /dev/shm/rtk_point.json die aktuelle Lat/Lon herausgeholt und weiß aus der waypoint Liste wo sie hin muss. Daraus kann sie dann für die Motorsteuerung die erforderlichen Werte berechnen, und schreibt diese dann jede sekunde cmd= f"20, 20, {int(distance*100)},s,{int(target_bearing)}" in die /dev/shm/drive_cmd. Die Motorsteuerung liest die dann auch wieder aus und aktualisiert damit dann in diesem Beispiel 20 20 mit den erforderliche rpm Werten die sich aus dem target_bearing und dem aktuellen heading (welches auch die Motorsteuerung aus der bno_headimg Datei ausliest) ergibt. In den Dateien im zip File ist noch sehr viel logging information enthalten, was ich zur Analyse gebraucht habe. Das müsste ich dann mal bereinigen.Hoffe ich konnte Dir helfen.