Lawn Mower AWD Mähroboter Allrad Automower All wheel drive 4WD von Fürst Ruprecht

Ist das nicht die Aufgabe vom Regler, bei mehr Steigung mehr Gas zu geben, damit die Geschwindigkeit konstant bleibt?
Ja, wenn die Geschwindigkeit gleich bleiben soll.
Die Genauigkeit bei RTK-Fahrt hängt auch von der Geschwindigkeit ab. Wenn man genug Leidenschaft ( oder Leidensfähigkeit ) hat, kann man die Geschwindigkeitsvorgabe in kritischen Bereichen für mehr Genauigkeit oder vielleicht für schonende Wendemanöver reduzieren.
 
Hallo Frank,
ich habe aktuell zwei Allradmäher laufen.
1. PCB 1.3 + Arduino Due + 4x brushed Motor
2. Selbst gelötetes PCB mit Teensy 4.1 + 4x brushless Motor
Kernfragen:
A: Welche Software soll auf deinem Mäher laufen ?
B: RTK Ja/Nein ?
C: Software/ Lizenzkosten Ja/Nein
Ich denke an PCB 1.4 + arduino Due + 4x brushed Motoren
Leider RTK wegen einiger Bäume nicht möglich.
Als Software ist dann wohl nur Azurit möglich/sinnvoll ?

Eine andere Frage. Nach meinen Entwürfen benötige ich einen zuverlässigen Kompass.
Funktioniert Dein Kompass ? Reichen die Abstände zu den 5 Motoren bzw. anderen Störquellen aus ?
Gruß Frank
 
Ich denke an PCB 1.4 + arduino Due + 4x brushed Motoren
Leider RTK wegen einiger Bäume nicht möglich.
Als Software ist dann wohl nur Azurit möglich/sinnvoll ?

Eine andere Frage. Nach meinen Entwürfen benötige ich einen zuverlässigen Kompass.
Funktioniert Dein Kompass ? Reichen die Abstände zu den 5 Motoren bzw. anderen Störquellen aus ?
Gruß Frank
You can take a look here :
 
You can take a look here :
Das ist ein sehr gutes Thema zu 4WD und Perimeterproblemen. Leider konnte ich zum Thema Kompass nichts finden.
Ich habe gelesen, dass man vom Kompass zu DC-Motoren einen Abstand von 20 cm einhalten sollte. Könnt Ihr das bestätigen ? Ich dachte es gibt beim 4WD keine Stelle die 20 cm von den Motoren weg ist, oder doch ? Gibt es da Unterschiede zwischen brushless und brushd Motoren ?
 
Hallo, hallo,
Abstand zum Kompass: an jeder Ecke ein Radmotor, im Zentrum 1 oder 2 Mähmotoren - da wird der Abstand schnell recht gering.
Bei meinem blauen Mäher (PCB1.3+Due) hat der Kompass gut funktioniert (außer beim Lenkantrieb mit Steppermotor). Bei meinem Grundstück hilft mir der Kompass aber wenig. Nach jedem Umbau (und das waren bei mir sehr viele) mußte ich ihn neu kalibrieren und da der Mäher recht schwer ist, habe ich irgendwann darauf verzichtet.
In meinem Mäher Eve sitzt der pixhawk (da ist ein Kompass drin) direkt über einem Antriebsrad (BLDC) und funktioniert überraschend gut.
Im gleichen Mäher habe ich am Teensy einen anderen Kompasstyp, der wiederum nicht überzeugt. Da gibt es aber auch Probleme mit der Software, die zumindest bei mir tricky ist.
Ich würde den Kompass evtl. Richtung Gehäusedeckel bringen, bei RTK neben die Antenne, über dem Metallfuß.
Bäume habe ich keine, aber Sträucher. Selbst wenn der Mäher tief unterm Strauch steht, hat es bei mir bis jetzt noch keine Probleme mit RTK gegeben. Die Frage ist aus meiner Sicht auch, wo brauche ich die hohe Positionsgenauigkeit? Wenn der Mäher nicht ins Beet fahren soll (und man auch nicht von Hand nach mähen möchte), dann muß die Position schon exakt sein, ansonsten eher nicht.
Meine Frau bemängelt die exakten Bahnen vom RTK-Mäher und will lieber den anderen, bei dem kein Bahnenbild entsteht!! So also jedem das seine.
Bei der Lösung PCB1.3 + Due ist zu beachten: Der Due kommt an seine Leistungsgrenze. Das PCB kann nativ nur 4 Motortreiber (2xRad, 2xMäh) bedienen. Die 2 weiteren müssen per Kabel ergänzt werden. Das geht, das sieht man ja an meinem Mäher. Ich habe allerdings keine Drehzahlerfassung an den Vorderrädern umgesetzt.
Meine Motoren stammen aus dem Shop und machen eine sehr gute Arbeit. Der Mähmotor ist recht groß und schwer, hat aber den Vorteil, daß er in Kombination mit dem Treiber bei Überlast sicher abschaltet. Bei Eve nutze ich zwei preiswerte Brushed China Motoren. Blockiert das Messer, dann brennt jedes Mal meine Transistoransteuerung durch - zu hoher Kurzschlußstrom - echt Schei…
Der Perimeter macht eigentlich keine Probleme (es sei denn, der Draht ist kaputt).

Frank, Deine angedachte Hardware ist eine gute Wahl, wenn Du nach Möglichkeit auf die vorhanden Lösungen zurückgreifen und nicht beliebig viele Baustellen aufmachen willst.
Alternativ zu Azurit gibt es noch AzuritBer (von Bernard). Eine gute Alternative mit mehr Feinschliff für den „Standardmäher“. Ich würde Dir an dieser Stelle aber eher zu Azurit raten, ist einfacher, transparenter und für 4WD leichter anzupassen.

Gruß Fürst Ruprecht
 
In réalité
Das ist ein sehr gutes Thema zu 4WD und Perimeterproblemen. Leider konnte ich zum Thema Kompass nichts finden.
Ich habe gelesen, dass man vom Kompass zu DC-Motoren einen Abstand von 20 cm einhalten sollte. Könnt Ihr das bestätigen ? Ich dachte es gibt beim 4WD keine Stelle die 20 cm von den Motoren weg ist, oder doch ? Gibt es da Unterschiede zwischen brushless und brushd Motoren ?
Compass (using magnetic earth ) can't work inside a mower (simply test with your smartphone and a Compass APP and you are going to see the stupid result when moving the phone around the mower).
I use into all my code only GYRO and ACCEL based on gravity and they work everywhere inside the mower. (Only avoid big vibration and use good wire to connect IMU to PCB ) Velcro Tape is perfect to fix the IMU
 
Kurzer Statusbericht bezüglich meiner 4WD-Träume:

Aktuell habe ich einen Ardumower RTK aufgebaut, den ich als Entwicklungsplatform sehe. Mein Plan ist, statt des simplen Hinterrades eine Achse mit 2 aktiv getriebenen Rädern anzubauen, also vom Prinzip ähnlich wie der Husqvarna 435x . Leider bietet sind bei PCB V1.4 nur 3 Motorantriebe möglich. Evtl. kann ich ungenutzte Pins verwenden, um 2 weitere Treiber zu steuern (notfalls Sonar rauswerfen). Zusätztlich ist noch ein RPI mit an Bord und per UART mit dem M4 verbunden.

Ich will zwingend eine RTK Lösung bauen. Leider habe aber auch ich viele Bäume im Garten. Erster Schritt, ist nun mit dem Ardumower eine bessere Positionsbestimmung zu erreichen. Hier werde ich versuchen, mit
  • GPS
  • Odometrie
  • IMU (derzeit wird der IMU nur zur TILT-Detektion verwendet, da sollte doch mehr gehen)
  • (später: Kamera)
die Position möglichst genau zu bestimmen, um die benötigten GPS-Locks zu minimieren. Warum sollte z.B. der Mäher in "unkritischer Umgebung" unter einem Baum auf einen Lock warten, wenn der Stamm das einzige Hindernis ist?

Als SW habe ich Sunray als Startpunkt genommen, es werden aber sehr viele Teile herausfallen. Der M4 soll sich nur noch um die low-level Funktionen (Motoren, ...) kümmern.
Der RPI soll dann die Kartensteuerung, Netzwerk-Kommunikation, Video usw. übernehmen, dafür halte ich die Arduino-Platform für nicht geeignet. Auf ihm läuft Ubuntu mit ROS2, damit kann er bei WLAN-Verbindung elegant auch mit nodes auf meinem Entwicklungsrechner zusammenarbeiten (ein echt geiles Feature... :)).

Ist aber noch ein langer Weg...

Hier mein aktueller Versuchsaufbau:

20240101_235543.jpg
 
Take a look here for 5 motor management and raspberry pi connections.It s sunray version
The vision part Was ok on olber version (raspbian) but need Some change on ai picamera part for bulleyes
You can see it into azuritber wiki.
 
Thanks bernard for your remarks.
I was choosing for sunray as this is the only firmware officially supporting the M4. But it seems Azuritber may also be a solution. But this is not pushed back to the master branch - right?

About the 5 motor management I need individual control of each single motor. Running in parallel mode will not work as I have to steer 4 wheels differently.
 
Azuritber is not RTK (Only odometry and IMU) and run on DUE.
Azuritber wiki is only to see the vision part working on a connected raspberry pi:
take a look at Expérimental AI Vision with Tensorflow part.

For 4 wheel drive, you can use PCB1.4 free output or take a look at teensy PCB and use free output to manage the PWM and dir of the 2 front wheel.
 
Kurzer Statusbericht bezüglich meiner 4WD-Träume:
Aktuell habe ich einen Ardumower RTK aufgebaut, den ich als Entwicklungsplatform sehe. Mein Plan ist, statt des simplen Hinterrades eine Achse mit 2 aktiv getriebenen Rädern anzubauen, also vom Prinzip ähnlich wie der Husqvarna 435x . Leider bietet sind bei PCB V1.4 nur 3 Motorantriebe möglich.
Für meinen 4WD-Traum versuche ich eine anderen Ansatz - Knicklenkung.
Ich bin soweit, dass ein ESP32 die komplette Steuerung der 4 Motore einschließlich PID übernimmt. Also ich sage ihm nur Vor/Zurück, Knickwinkel, Geschwindigkeit. und Entfernung.
Auf dem Teppich läuft er, ob unter Praxisbedingungen ?

Gern würde ich ein GPS-RTK System mit azurit anwenden. So wie ich das gesehen habe, sind bei Sunrise einige Stellen leider für mich nicht anpassbar.
Geht GPS-RTK auch mit azurit zu machen.
PCB V1.4
Ich hab zwar einen M4 bereits hier liegen aber als Haupt-MC reicht mir wahrscheinlich der Due.
 
Für meinen 4WD-Traum versuche ich eine anderen Ansatz - Knicklenkung.
Ich denke, wir reden vom gleichen Verfahren. Auch bei mir wären das 4 aktiv angetriebene Räder und ein Gelenk zwischen beiden Achsen zum Steuern. Wenn man nun das Gelenk etwas nach hinten versetzt, kann man die kleinere hintere Hälfte bis zu 180° "knicken". Damit verbessert sich aus meiner Sicht die Wendigkeit. Aber das Grundprinzip ist das gleiche. Evtl. können wir hier ja zusammenarbeiten.

Wie kontrollierts Du den Knickwinkel? Mit einem Drehwinkelgeber?

Wie steuerst Du mit dem PCB V1.4 eigentlich 4 Motoren? Es hat zwar 4 Treiber, aber 2 davon laufen ja für den Mower im Parallel-Modus, wie ich aus dem Schaltplan sehen konnte. Eine Möglichkeit zur Auftrennung wäre eine sinnvolle Erweiterung für eine V1.5 ;).
Welche Motoren und Treiber verwendest Du - ich brauch ja noch zwei weitere und weiß noch nicht, welche hier am Besten funktionieren.

Was ist beim RTK eigentlich nicht an den DUE anpassbar? Letztendlich braucht es ja nur eine serielle Schnittstelle. Das Problem ist aus meiner Sicht dann eher, was ich mit den Daten mache. Und da finde ich ein Arduino-System zu schwach bzw. wird die SW zu komplex (kooperatives Multitasking, keine Synchronisationsmechanismen). Der Arduino soll zuverlässig und wartbar bleiben - nur statisches Speichermanagement. Die "Middleware" (Karte, Navigation, Umgebungserkennung, ...) soll dann in den RPI.

Die Steuerung der Motoren finde ich nicht optimal für meinen Einsatz. Statt eine Sekunde draufloszufahren möchte ich, dass der Ardumower eine definierte Wegstrecke zurücklegen soll. Ich möchte also auch die Odometrie schon dazu verwenden, die theoretische Position des Ardumowers zu ermitteln (wenn mal gerade wieder kein GPS Fix zustandekommen will). Hier muss ich also vermutlich die Treiber überarbeiten. Oder gibt es da schon andere Lösungen?
 
Ich nutze für die Überwachung des Drehwinkels:
Reichelt:

MUR SV01A103AEA0 Rotationssensor, 333,3°, SMD​

Ansteuerung der Motoren: die beiden zusätzlichen Motortreiber (ich nutze den gleichen Typ wie die bereits vorhanden) lassen sich über die vorhandenen / restlichen Ports per Kabelverbindung anschließen. Bei den Treibern habe ich aufgrund der „hohen“ Betriebsspannung (7s-Akku) keine Alternative gefunden.

Wenn der Mäher nicht auf der Stelle wenden kann (Gestaltung der Achse), dann muß das Programm aus meiner Sicht erweitert werden um die Möglichkeit „zurück zu stoßen“. Das kompliziert die ganze Fahrstrategie. Von Vorteil ist es auch, wenn die Lenkachse es ermöglicht, möglichst schnell die Wegstrecke in y zu verändern - also eine Lenkung wie beim Mähdrescher ist sehr ungünstig.
Von Vorteil ist es, wenn mann bei der Berechnung der Radgeschwindigkeit auf Winkelfunktionen verzichten kann, weil sonst die microcontroller zu schnell einbrechen.
Die 4 Räder müssen immer belastet auf dem Boden aufstehen !! -> Achskonstruktion !

Was kann der Due bei RTK nicht? Wahrscheinlich kann er alles - die Frage ist, was er können soll. Wenn die Fahrstrecke von außen vorgegeben wird, dann ist aus meiner Erfahrung die Berechnung der 4 Raddrehzahlen eine deutliche Erhöhung der Last. Den Ansatz, die Motorsteuerung auszulagern, finde ich gut, das schafft Freiraum -> dann ist das PCB 1.4 aber der falsche Weg, dann wäre der Wechsel auf das Teensy-PCB angesagt.
Odometrie: Meine Erfahrung: Umsetzung für die gelenkten Räder zu aufwendig/kompliziert. Fordert das Gelände einen 4-Rad-Antrieb, dann wird auch das ein oder andere Rad im Betrieb durchdrehen, wodurch das Odometrie-Signal verfälscht wird. Beim Due könnten zwei weitere Interrupts auch kritisch werden.

Die Wegsteuerung anstelle der Zeitsteuerung hat den großen Vorteil, daß bei Veränderung der Geschwindigkeiten nicht alle Parameter erneut angepaßt werden müssen. Leider hat Bernard‘s azuritber bei mir keinen Vorteil gebraucht (aufgrund Radschlupf). Für den „Einstieg“ würde ich daher azurit empfehlen, weil es leichter zu verstehen ist und nicht die Komplexität und Funktionsvielfalt von azuritber hat.


Wie siehts bei mir aus:
Ich werde Mission Planner nutzen, um den Mäher zu parametrieren, zu “beobachten“ und die Fahrstrecke vorab zu generieren. Dazu habe ich die letzten Tage das Interface Teensy - PC (via 900Mhz-Radio / wlan-bridge) auf Basis des mavlink-Protokolls aufgebaut. Stand heute kann der teensy die Streckenplanung, die Parameter und die Betriebsdaten zwischen Mission Planner hin und her schicken. Fernsteuerung über joystick funktioniert, RC-Steuerung (10Kanal S-Bus Anbindung) ebenso.
Als nächstes kümmere ich mich um die Motoransteuerung. Den esp32 als Controller habe ich im Moment verworfen, weil die Ports nicht ausreichen. Stattdessen werde ich wohl zwei 16Kanal PWM Platinen und einen 16Kanal Portexpander einsetzen. Ein Vorteil ist dabei die Trennung zwischen 3,3V Teensy-Umfeld und 5V Anforderung für die BLDC-Controller.
Hier haben die Getriebemotoren mit integriertem BLDC-Controller einen großen Vorteil, weil deren Ansteuerung lediglich einen Levelshifter benötigen.
 
Ich nutze für die Überwachung des Drehwinkels:
Reichelt:

MUR SV01A103AEA0 Rotationssensor, 333,3°, SMD​

Danke für die Info. Also im Prinzip eine spezielle Ausführung eines Potentiometers.

An ein Poti hatte ich auch schon gedacht, sehe hier aber 2 Nachteile:
  • Ich kann den 0° Winkel mit AD-Wandler nicht zuverlässig erfassen für eine exakte Geradeausfahrt (und die wird es ja sicherlich geben). Wäre mit einem zusätzlichen Kontakt aber lösbar.
  • Die Montage ist schwieriger, weil die Gelenkwelle deutlich größer ist.

Am liebsten wäre mir ein digitaler Impulsgeber. Vielleicht kann man ja mit 2 Lichschranken und 3D-Drucker was hinkriegen...
 
Zuletzt bearbeitet:
Von Vorteil ist es, wenn mann bei der Berechnung der Radgeschwindigkeit auf Winkelfunktionen verzichten kann, weil sonst die microcontroller zu schnell einbrechen.

Die Wegsteuerung anstelle der Zeitsteuerung hat den großen Vorteil, daß bei Veränderung der Geschwindigkeiten nicht alle Parameter erneut angepaßt werden müssen. Leider hat Bernard‘s azuritber bei mir keinen Vorteil gebraucht (aufgrund Radschlupf). Für den „Einstieg“ würde ich daher azurit empfehlen, weil es leichter zu verstehen ist und nicht die Komplexität und Funktionsvielfalt von azuritber hat.

Ich hatte gestern Abend etwas Zeit und mal testweise eine Positionsberechnung implementiert (Xpos, Ypos, Drrehwinkel). Dann bin ich in meinem Zimmer etwas umhergefahren und wieder zum Ursprungspunkt zurück. Das Ergebnis war vielversprechend.
Ich habe einen relativ glatten Boden und die Ardumower Räder rutschen da sehr leicht durch. Trotzdem war die Abweichung nur wenige Zentimeter. Zumindest werde ich den Weg noch weiter verfolgen.
Zumindest der GCM4 hat floating point support, die Rechenleistung sehe ich nicht als Problem.

Natürlich wird die Positionsbestimmung nur durch die Odometrie nicht genügen, aber mich stört, dass der Alfred unter Bäumen immer wieder stehen bleibt und auf einen Fix wartet. Mein Ansatz ist, diese Funkschatten mit anderen Sensoren (Odometrie, IMU) überbrücken zu können.

Azurit und Azuritber scheinen ja nicht den GCM4 zu unterstützen, deshalb bin ich von Sunray aus gestartet.
 
Zuletzt bearbeitet:
Die 4 Räder müssen immer belastet auf dem Boden aufstehen !! -> Achskonstruktion !

Gute Bemerkung! Auf ebener Fläche wird das vielleicht noch nicht so wichtig, aber im Gelände wird das sicherlich wichtig.
Derzeit schwebt mir vor, der hinteren Achse noch ein Gelenk auf der X-Achse zu spendieren, so wie Du das bei Deinem 4WD bei der Vorderachse gemacht hast.
 
Wie siehts bei mir aus:
Ich werde Mission Planner nutzen, um den Mäher zu parametrieren, zu “beobachten“ und die Fahrstrecke vorab zu generieren. Dazu habe ich die letzten Tage das Interface Teensy - PC (via 900Mhz-Radio / wlan-bridge) auf Basis des mavlink-Protokolls aufgebaut. Stand heute kann der teensy die Streckenplanung, die Parameter und die Betriebsdaten zwischen Mission Planner hin und her schicken. Fernsteuerung über joystick funktioniert, RC-Steuerung (10Kanal S-Bus Anbindung) ebenso.
Als nächstes kümmere ich mich um die Motoransteuerung. Den esp32 als Controller habe ich im Moment verworfen, weil die Ports nicht ausreichen. Stattdessen werde ich wohl zwei 16Kanal PWM Platinen und einen 16Kanal Portexpander einsetzen. Ein Vorteil ist dabei die Trennung zwischen 3,3V Teensy-Umfeld und 5V Anforderung für die BLDC-Controller.
Hier haben die Getriebemotoren mit integriertem BLDC-Controller einen großen Vorteil, weil deren Ansteuerung lediglich einen Levelshifter benötigen.
Diese Themen stehen bei mir noch hinten an. Zunächst werde ich wohl neue Räder konstruieren, die "Ardumower-Kreissägeblätter" (ist jetzt nicht abwertend gemeint :)) sind vor allem bei meinen Indoor-Tests auf glattem Boden nicht sehr hilfreich.

Ich lasse jetzt bei meinem Ardumower RPI4 und GCM4 über UART (BLE) kommunizieren. Wie verbindest Du die Controller miteinander?
 
Ich nutze für die Überwachung des Drehwinkels:
Reichelt:

MUR SV01A103AEA0 Rotationssensor, 333,3°, SMD​

Ich hab mir das fertige Modul bei amazon besorgt. SV01A103AEA01R00-40. Ist nicht viel teurer aber einbaufreundlicher.

Was sagt Eure Erfahrung, wäre es möglich den 4WD nur mit den 4 Antriebsmotoren ohne aktive Lenkung zu steuern ? Also laufend das Ziel überprüfen und mit Hilfe der 4 Radencoder und des Drehwinkelsensors am Knick die Radgeschwindigkeiten anpassen(PID). Wenn man das Ziel laufend kontrolliert, wäre theoretisch der Drehwinkelsensor auch nicht notwendig ?
In meinen Versuchen ist das auch gelungen. Sobald aber ein größeres Hindernis auftritt, hilft die Drehzahl zum steuern nicht mehr aus, sondern die Achse muß aktiv in die richtige Stellung gebracht werden.
Bisher brauchte ich nur überschaubare Winkelberechnungen. Das 3D-Knickgelenk liegt bei mir genau in der Mitte. Ich gehe immer davon aus, dass die beiden Räder einer Seite die gleiche Zieldrehzahl haben.
 
Was sagt Eure Erfahrung, wäre es möglich den 4WD nur mit den 4 Antriebsmotoren ohne aktive Lenkung zu steuern ? Also laufend das Ziel überprüfen und mit Hilfe der 4 Radencoder und des Drehwinkelsensors am Knick die Radgeschwindigkeiten anpassen(PID). Wenn man das Ziel laufend kontrolliert, wäre theoretisch der Drehwinkelsensor auch nicht notwendig ?
In meinen Versuchen ist das auch gelungen. Sobald aber ein größeres Hindernis auftritt, hilft die Drehzahl zum steuern nicht mehr aus, sondern die Achse muß aktiv in die richtige Stellung gebracht werden.
Bisher brauchte ich nur überschaubare Winkelberechnungen. Das 3D-Knickgelenk liegt bei mir genau in der Mitte. Ich gehe immer davon aus, dass die beiden Räder einer Seite die gleiche Zieldrehzahl haben.

Meine Erfahrung sagt: Keine Ahnung! ;)

Fürst Rupprecht hat hier mehr Erfahrung, und meines Wissens rät er auch ab davon (steht hier irgendwo im Forum). Wegen des benötigten Drehmoments bräuchte man einen sehr kräftigen Motor, oder einen mit Getriebe, der dann wiederum langsam wäre. Er hat seinen 4WD auch erfolgreich nur mit 4 aktiv gesteuerten Motoren realisiert.

Ich möchte die Achse nicht aktiv steuern, sondern nur mit den 4 Rädern. Ich hoffe, dass das gelingt. Evtl. muss man hier der Vorderachse etwas mehr Antrieb geben, solange man nicht alle 4 Räder braucht.
Wenn das Knickgelenk genau in der Mitte steht, ist die Algorithmik sicher einfacher. Man ist dafür aber beim Knickwinkel eingeschränkt, irgendwann kippt der Mower dann ja um. Ich möchte hintere Achse näher Richtung +/-90° drehen, ähnlich wie ein Vorderlenker im Rückwärtsgang (oder Mähdrescher). Dann ist die Vorderachse immer dominant.
 
Oben