Ardumower cm-genau und experimentell ohne Schleife betreiben (Sunray Firmware goes RTK)
- Ersteller AlexanderG
- Erstellt am
Hallo Alexander,
hier die versprochene Rückmeldung: Das IMU Modul wird jetzt beim Start initialisiert. Die 8 Piepstöne + Bootpiepser sind jetzt zu hören.
Der Geradeauslauf ist auch besser geworden. Es gibt deutlich weniger Ausreißer und wenn... dann findet er schnell wieder zur richtigen Linie. Ich muss mal noch mit Grundplatten experimentieren.
Handy-App: v1.0.22
Ardumower-Sunray: v1.0.25
Beste Grüße
Martin
hier die versprochene Rückmeldung: Das IMU Modul wird jetzt beim Start initialisiert. Die 8 Piepstöne + Bootpiepser sind jetzt zu hören.
Der Geradeauslauf ist auch besser geworden. Es gibt deutlich weniger Ausreißer und wenn... dann findet er schnell wieder zur richtigen Linie. Ich muss mal noch mit Grundplatten experimentieren.
Handy-App: v1.0.22
Ardumower-Sunray: v1.0.25
Beste Grüße
Martin
Wow, great evolution!
(hope you don't mind I write in English, I can read a bit of German but I probably should not try to type...)
just wanted to say that I'm trying to achieve the same goal but with small scale agriculture in mind. (see video). I have bought roughly the same components (due, SimpleRTK, ...). I choose to put the motor feedback on separate wheels, to avoid measuring slip errors. I didn't think sensor fusion with IMU was feasible but you did it ?! The feedback wheel have issues when making short turns so I'm looking to dump that idea.
Currently I hit some obstacles on the control logic, but it will probably be easier to learn ardumower than to solve them...
Any one else working towards agriculture? I think the only difference is that there's a different path to plan but that should be feasible to learn I think?
(hope you don't mind I write in English, I can read a bit of German but I probably should not try to type...)
just wanted to say that I'm trying to achieve the same goal but with small scale agriculture in mind. (see video). I have bought roughly the same components (due, SimpleRTK, ...). I choose to put the motor feedback on separate wheels, to avoid measuring slip errors. I didn't think sensor fusion with IMU was feasible but you did it ?! The feedback wheel have issues when making short turns so I'm looking to dump that idea.
Currently I hit some obstacles on the control logic, but it will probably be easier to learn ardumower than to solve them...
Any one else working towards agriculture? I think the only difference is that there's a different path to plan but that should be feasible to learn I think?
Einen Guten Morgen in die Runde,
ich bin gerade dabei zu erforschen warum auf der GPS->XBEE LED so viel los ist und ob es deswegen evtl. an anderer Stelle zu Beeinträchtigungen kommt.
Dabei ist mir aufgefallen, dass der skipped Zähler scheinbar zu hoch ist (wie es auch im Wiki zu sehen ist).
Nun bin ich die beschriebenen Punkte soweit durch gegangen konnte aber nichts finden. Ich hatte seiner Zeit die Config von Alex in das Roverboard eingespielt. Einziger unterschied:
Im Wiki sind 200ms beschrieben und in der Config-Datei 1000ms eingetragen. Aber ich glaube nicht, dass es etwas damit zu tun hat.
In welche Richtung kann ich noch suchen?
Beste Grüße
Martin
ich bin gerade dabei zu erforschen warum auf der GPS->XBEE LED so viel los ist und ob es deswegen evtl. an anderer Stelle zu Beeinträchtigungen kommt.
Dabei ist mir aufgefallen, dass der skipped Zähler scheinbar zu hoch ist (wie es auch im Wiki zu sehen ist).
Nun bin ich die beschriebenen Punkte soweit durch gegangen konnte aber nichts finden. Ich hatte seiner Zeit die Config von Alex in das Roverboard eingespielt. Einziger unterschied:
Im Wiki sind 200ms beschrieben und in der Config-Datei 1000ms eingetragen. Aber ich glaube nicht, dass es etwas damit zu tun hat.
In welche Richtung kann ich noch suchen?
Beste Grüße
Martin
Anhänge
Hallo Martin,
ich gehe davon aus dass Du vom Rover-ublox-Empfänger sprichst (und nicht von einem Base-ublox-Empfänger bei einer eigenen Referenzstation).
Nur so eine Idee (hab ich bisher nicht überprüft) : falls im NTRIP-Modul die Log-Nachrichten ("Log forward") aktiviert sind könnte es sein dass dies zusätzliche Nachrichten verursacht (von XBee zu GPS) mit denen der ublox-Empfänger logischerweise nichts anfangen kann (und wodurch der "Skip-Wert" ansteigen könnte). Diese Log-Ausgaben kann man sich übrings per seriellem Monitor in der Arduino IDE anschauen - man muss dazu die USB-Buchse neben der XBee am ublox-Empfänger verwenden.
wiki.ardumower.de
Wäre so eine Idee...
Gruss,
Alexander
Nachtrag: ich muss mich korrigieren, du meinst ja anscheinend Kommunikation in die andere Richtung (von GPS zu XBee). Dann wären am ublox-Empfänger zusätzliche Nachrichten aktiviert (z.B. weitere NMEA-Nachrichten) welche die XBee gar nicht benötigt. Ein stark ansteigender "Skip-Wert" bezieht sich übrings nur auf Nachrichten welche der ublox-Empfänger empfängt (also "XBee zu GPS").
ich gehe davon aus dass Du vom Rover-ublox-Empfänger sprichst (und nicht von einem Base-ublox-Empfänger bei einer eigenen Referenzstation).
Nur so eine Idee (hab ich bisher nicht überprüft) : falls im NTRIP-Modul die Log-Nachrichten ("Log forward") aktiviert sind könnte es sein dass dies zusätzliche Nachrichten verursacht (von XBee zu GPS) mit denen der ublox-Empfänger logischerweise nichts anfangen kann (und wodurch der "Skip-Wert" ansteigen könnte). Diese Log-Ausgaben kann man sich übrings per seriellem Monitor in der Arduino IDE anschauen - man muss dazu die USB-Buchse neben der XBee am ublox-Empfänger verwenden.
Ardumower Sunray – www.wiki.ardumower.de
Gruss,
Alexander
Nachtrag: ich muss mich korrigieren, du meinst ja anscheinend Kommunikation in die andere Richtung (von GPS zu XBee). Dann wären am ublox-Empfänger zusätzliche Nachrichten aktiviert (z.B. weitere NMEA-Nachrichten) welche die XBee gar nicht benötigt. Ein stark ansteigender "Skip-Wert" bezieht sich übrings nur auf Nachrichten welche der ublox-Empfänger empfängt (also "XBee zu GPS").
Zuletzt bearbeitet:
Hallo Alexander,
ich hab gerade nochmal nach dem "Log forward" gesehen aber daran lag es nicht. Hab auch gerade erst Deinen Nachtrag gelese.
Da grundsätzlich soweit alles funktioniert... las ich erstmal die Finger davon und schau mal was ich so als alternative Grundplatten finde.
Beste Grüße
Martin
ich hab gerade nochmal nach dem "Log forward" gesehen aber daran lag es nicht. Hab auch gerade erst Deinen Nachtrag gelese.
Da grundsätzlich soweit alles funktioniert... las ich erstmal die Finger davon und schau mal was ich so als alternative Grundplatten finde.
Beste Grüße
Martin
larsberghahn
Member
Hallo,
ich habe erst letzte Woche angefangen meinen ersten Ardumower aufzubauen, da ich gut in elektronik und programmierung bin aber schlecht in mechanik und leider auch nicht die Zeit habe ein chassis zu bauen musste ich etwas nehmen was schon da war. Ein defekter Robomow RL 1000. Ein funktionierender RL 1000 läuft auf der Fläche... Ich habe alles soweit zusammengebaut und es scheint zumindest auf dem Tisch zu laufen. Jetzt sollte es daran gehen den perimeter umzurüsten aber wenn ich die Fortschritte hier sehe ist das ja totaler blödsinn das zu tun.
Ich würde lieber direkt auf RTK gehen, da ich zwei weitere Flächen mit je 400qm habe die ich aktuell manuell mähe weil kein strom, perimter, etc. Also das Gelände ist gross, insg. 18tqm wovon ca. 3tqm gemäht werden in 4 grösseren Flächen und ein Paar Streifen...
Jetzt hätte ich ein paar fragen bevor ich ein teures RTK set bestelle... Ich möchte ungern Wlan nutzen da die entfernungen und Flächen doch recht gros sind... Das bedeutet am besten wohl eigene Basis und zur Sicherheit LR Funk... Kein WLAN bedeutet aber auch garkein Wlan zum Mäher... Dort wo die Basis stehen soll hätte ich aber Netzwerk bzw. Wlan... Ist es möglich den Mäher dann von der Basis aus zu überwachen und zu starten/stoppen?
Wenn ich das ans laufen bekäme und ich den bestehenden RL 1000 auch noch umbauen wollte... Könnte ich mit einer Basis zwei Mäher befeuern?
Anbei ein Bild vom aktuellen Prototypen...
ich habe erst letzte Woche angefangen meinen ersten Ardumower aufzubauen, da ich gut in elektronik und programmierung bin aber schlecht in mechanik und leider auch nicht die Zeit habe ein chassis zu bauen musste ich etwas nehmen was schon da war. Ein defekter Robomow RL 1000. Ein funktionierender RL 1000 läuft auf der Fläche... Ich habe alles soweit zusammengebaut und es scheint zumindest auf dem Tisch zu laufen. Jetzt sollte es daran gehen den perimeter umzurüsten aber wenn ich die Fortschritte hier sehe ist das ja totaler blödsinn das zu tun.
Ich würde lieber direkt auf RTK gehen, da ich zwei weitere Flächen mit je 400qm habe die ich aktuell manuell mähe weil kein strom, perimter, etc. Also das Gelände ist gross, insg. 18tqm wovon ca. 3tqm gemäht werden in 4 grösseren Flächen und ein Paar Streifen...
Jetzt hätte ich ein paar fragen bevor ich ein teures RTK set bestelle... Ich möchte ungern Wlan nutzen da die entfernungen und Flächen doch recht gros sind... Das bedeutet am besten wohl eigene Basis und zur Sicherheit LR Funk... Kein WLAN bedeutet aber auch garkein Wlan zum Mäher... Dort wo die Basis stehen soll hätte ich aber Netzwerk bzw. Wlan... Ist es möglich den Mäher dann von der Basis aus zu überwachen und zu starten/stoppen?
Wenn ich das ans laufen bekäme und ich den bestehenden RL 1000 auch noch umbauen wollte... Könnte ich mit einer Basis zwei Mäher befeuern?
Anbei ein Bild vom aktuellen Prototypen...
Anhänge
Hallo Lars, deine Ausführungen machen Sinn, eigene Basis klint sinnvoll. Und ja, man kann für das Monitoring auch ohne WLAN auskommen, denn man kann über die Rover-XBee auch Daten vom GPS-Modul (und evtl. auch vom Ardumower) zur Basis-XBee schicken.
Dies wird bereits für NTRIP (also ohne Basis) gebraucht (dort allerdings zum NTRIP-Provider geschickt), konkret wird die Nachricht "NMEA GGA" dabei aktiviert:
wiki.ardumower.de
Das bedeutet die eigene Basis empfängt die aktuelle Rover-GPS-Position bereits (kann dort über den zweiten USB-Anschluss neben der XBee in Form von NMEA-Daten abgefragt werden).
Für einen zweiten Mäher kann man eine einzige Basis benutzen, da müsste ich mich aber schlau machen ob sich beide Mäher den "Rückkanal" für das Monitoring teilen können, vermutl. sollte das aber gehen.
Folgender Abschnitt ist für Software-Entwickler interessant (und könnte Nachbauer verwirren ;-) ):
Komplizierter wird's wenn einer oder beide Ardumower auch noch darüber kommunzieren sollen (also nebem dem GPS-Modul, dann müsste man erstmal eine Datenpaket-Weiche umsetzen so dass von der Rover-XBee empfangene Pakete zwischen Ardumower und GPS-Modul umgeleitet werden und das auch noch für zwei Mäher... die Ardumower Sunray-Datenpakete sind übrings nur wenige Bytes lang, würden also die RTCM3/NMEA Kommunikation der LR-Module nicht ausbremsen) - desweiteren kann die Sunray App Web Oberfläche nicht auf serielle oder USB-Geräte zugreifen, nur auf Netzwerkgeräte.
Ein Monitoring ohne WLAN kannst Du jedoch bereits jetzt schon wie eingangs beschrieben über die LongRange-XBee durchführen (z.B. über die ublox u-Center Software) .
Last but not least : Die Sunray-Software ist im Experimentierstadium (für Experimentierfreudige) und wird primär für die Ardumower-Plattform aus dem Shop entwickelt - mit gleicher Hardware, gleichen Motoren und gleichem Chassis haben auch weniger Versierte eine Chance das Projekt exakt so nachzubauen und nur so kann man sinnvoll auf Dauer Support leisten. Einige wenige passen Ardumower-Software selber für Ihr eigene Hardware an, die meisten werden sie jedoch benutzen so wie sie ist. Bevor Du Dich für eine Software entscheidest oder großartige Pläne schmiedest (;-)) empfehle ich sie erst einmal auszuprobieren um zu schauen ob sie für Deine Umgebung und Ansprüche einsetzbar ist.
Gruss,
Alexander
Dies wird bereits für NTRIP (also ohne Basis) gebraucht (dort allerdings zum NTRIP-Provider geschickt), konkret wird die Nachricht "NMEA GGA" dabei aktiviert:
Ardumower Sunray – www.wiki.ardumower.de
Für einen zweiten Mäher kann man eine einzige Basis benutzen, da müsste ich mich aber schlau machen ob sich beide Mäher den "Rückkanal" für das Monitoring teilen können, vermutl. sollte das aber gehen.
Folgender Abschnitt ist für Software-Entwickler interessant (und könnte Nachbauer verwirren ;-) ):
Komplizierter wird's wenn einer oder beide Ardumower auch noch darüber kommunzieren sollen (also nebem dem GPS-Modul, dann müsste man erstmal eine Datenpaket-Weiche umsetzen so dass von der Rover-XBee empfangene Pakete zwischen Ardumower und GPS-Modul umgeleitet werden und das auch noch für zwei Mäher... die Ardumower Sunray-Datenpakete sind übrings nur wenige Bytes lang, würden also die RTCM3/NMEA Kommunikation der LR-Module nicht ausbremsen) - desweiteren kann die Sunray App Web Oberfläche nicht auf serielle oder USB-Geräte zugreifen, nur auf Netzwerkgeräte.
Ein Monitoring ohne WLAN kannst Du jedoch bereits jetzt schon wie eingangs beschrieben über die LongRange-XBee durchführen (z.B. über die ublox u-Center Software) .
Last but not least : Die Sunray-Software ist im Experimentierstadium (für Experimentierfreudige) und wird primär für die Ardumower-Plattform aus dem Shop entwickelt - mit gleicher Hardware, gleichen Motoren und gleichem Chassis haben auch weniger Versierte eine Chance das Projekt exakt so nachzubauen und nur so kann man sinnvoll auf Dauer Support leisten. Einige wenige passen Ardumower-Software selber für Ihr eigene Hardware an, die meisten werden sie jedoch benutzen so wie sie ist. Bevor Du Dich für eine Software entscheidest oder großartige Pläne schmiedest (;-)) empfehle ich sie erst einmal auszuprobieren um zu schauen ob sie für Deine Umgebung und Ansprüche einsetzbar ist.
Gruss,
Alexander
Zuletzt bearbeitet:
larsberghahn
Member
Hallo,
vielen Dank erstmal für deine Ausführungen.
Ein zweiter Mäher an einer Basis ist ja erstmal noch ganz weit hinten angestellt, über die Basis an Statusinformationen des Mowers zu kommen und ihm Kommandos schicken zu können, das wäre mir schon sehr wichtig. Positionsdaten wären da die eine Sache, mir ginge es aber tatsächlich eher um die Steuerung des Rovers. Ich habe da jetzt eine Weile drüber nachgedach und evtl. wäre es einfacher bzw. mehr im Standart und damit Zukunftsorientierter wenn ich doch anstelle der Basislösung die Bereiche mit WLAN versorge... Die Möglichkeit dazu hätte ich, da ich eh ein weit Verzweigtes LAN-Netzwerk habe. WLAN ist allerdings aktuell noch nicht viel, ich stehe eigentlich auf Kabel. Um den Rover an jeder ecke versorgen zu können würde ich ein MESH WLAN benötigen damit der Rover quasi nur einen Access Point sieht da er wohl nicht so gerne zwischendurch ständig das WLAN wechseln will oder? Im ganzen wäre das wahrscheinlich die kostenneutralere Lösung.
Software ausprobieren ist das was ich mit dem Tischaufbau machen wollte. Nur jetzt bin ich eigentlich so weit, dass ich ihn gerne mal fahren lassen würde nur ohne Perimeter und ohne GPS wird das wohl nichts. Ob meine Hardware überhaupt fahrtüchtig ist mit der Software die ich teste sehe ich auf dem Tisch ja nicht. Ich habe mir den Quellcode von Azurit und Sunray grob angeguckt, ich kann schlecht einschätzen was für herausforderungen bei der Anpassung auf meine Hardware auf mich zukommen. Aber ein bisschen balsteln will ich natürlich auch noch.
Als ich schon mitten im Aufbau war habe ich durch Zufall dieses sehr Interessante Projekt von bernard gefunden: https://forum.ardumower.de/threads/robomow-rl1000-rebuild.23679/ Das ist schon sehr Professionell aus meiner Sicht, aber ich habe keinen 3D Drucker und möchte das ganze auch möglichst einfach halten. Achja, und ich möchte keine Schleifen verbuddeln, weil es teilweise gar nicht geht, da überall Beton und Steine verbuddelt sind und weil ich sonst riesen Aufwände hätte überall noch Stromkabel für die Perimetersender hinzubuddeln...
Wenn ich jetzt 3-4 WLAN Router positioniere (Habe wahrscheinlich noch genügend rumliegen) und damit die bereiche Versorge und dann das "GPS/RTK WiFi NTRIP ArduMower spezial Kit" aus dem Shop bestelle, dann hätte ich doch eine schönere günstigere Lösung und wäre dabei ganz nah am Standart oder? Würde sogar das Problem mit dem zweiten Mäher lösen
MFG Lars
vielen Dank erstmal für deine Ausführungen.
Ein zweiter Mäher an einer Basis ist ja erstmal noch ganz weit hinten angestellt, über die Basis an Statusinformationen des Mowers zu kommen und ihm Kommandos schicken zu können, das wäre mir schon sehr wichtig. Positionsdaten wären da die eine Sache, mir ginge es aber tatsächlich eher um die Steuerung des Rovers. Ich habe da jetzt eine Weile drüber nachgedach und evtl. wäre es einfacher bzw. mehr im Standart und damit Zukunftsorientierter wenn ich doch anstelle der Basislösung die Bereiche mit WLAN versorge... Die Möglichkeit dazu hätte ich, da ich eh ein weit Verzweigtes LAN-Netzwerk habe. WLAN ist allerdings aktuell noch nicht viel, ich stehe eigentlich auf Kabel. Um den Rover an jeder ecke versorgen zu können würde ich ein MESH WLAN benötigen damit der Rover quasi nur einen Access Point sieht da er wohl nicht so gerne zwischendurch ständig das WLAN wechseln will oder? Im ganzen wäre das wahrscheinlich die kostenneutralere Lösung.
Software ausprobieren ist das was ich mit dem Tischaufbau machen wollte. Nur jetzt bin ich eigentlich so weit, dass ich ihn gerne mal fahren lassen würde nur ohne Perimeter und ohne GPS wird das wohl nichts. Ob meine Hardware überhaupt fahrtüchtig ist mit der Software die ich teste sehe ich auf dem Tisch ja nicht. Ich habe mir den Quellcode von Azurit und Sunray grob angeguckt, ich kann schlecht einschätzen was für herausforderungen bei der Anpassung auf meine Hardware auf mich zukommen. Aber ein bisschen balsteln will ich natürlich auch noch.
Als ich schon mitten im Aufbau war habe ich durch Zufall dieses sehr Interessante Projekt von bernard gefunden: https://forum.ardumower.de/threads/robomow-rl1000-rebuild.23679/ Das ist schon sehr Professionell aus meiner Sicht, aber ich habe keinen 3D Drucker und möchte das ganze auch möglichst einfach halten. Achja, und ich möchte keine Schleifen verbuddeln, weil es teilweise gar nicht geht, da überall Beton und Steine verbuddelt sind und weil ich sonst riesen Aufwände hätte überall noch Stromkabel für die Perimetersender hinzubuddeln...
Wenn ich jetzt 3-4 WLAN Router positioniere (Habe wahrscheinlich noch genügend rumliegen) und damit die bereiche Versorge und dann das "GPS/RTK WiFi NTRIP ArduMower spezial Kit" aus dem Shop bestelle, dann hätte ich doch eine schönere günstigere Lösung und wäre dabei ganz nah am Standart oder? Würde sogar das Problem mit dem zweiten Mäher lösen
MFG Lars
Hallo Lars,
bevor ich mir große Gedanken über die Abdeckung mit WLAN mache, würde ich einfach ein altes Smartphone mit ein paar MB Datenvolumen (Netzclub o.ä.) an den Mower hängen und das Ganze testen.
Ich würde an deiner Stelle das WiFi NTRIP Kit kaufen.
Gruß Etienne
bevor ich mir große Gedanken über die Abdeckung mit WLAN mache, würde ich einfach ein altes Smartphone mit ein paar MB Datenvolumen (Netzclub o.ä.) an den Mower hängen und das Ganze testen.
Und ich denke bei großen Flächen, die keinen Stromanschluss haben. wird eine Versorgung über das Mobilfunknetz wahrscheinlich auch dauerhaft einfacher sein, als WLAN-Mesh (mit Stromversorgung der Router über Akku, Solar, ...). Einfach einen mobilen Router (oder Smartphone) auf dem Ardumower mitfahren lassen und über den Akku versorgen.
Ich würde an deiner Stelle das WiFi NTRIP Kit kaufen.
Gruß Etienne
Die Idee von Etienne hört sich gut an - einfach das WLAN auf dem Mäher aufbauen (über Mobilfunknetz) und dann darüber alles (NTRIP, Ardumower WIFI) laufen lassen. Und falls es nicht nach Deinem Geschmack ist, kannst Du später ja immer noch eine eigene LongRange-Basis dazukaufen oder WLAN-Netze an jeder Ecke überall aufbauen ;-). Ich denke wir sollten die Umsetzung über Mobilfunknetz (Router oder Smartphone) und auch noch ins Wiki aufnehmen (Prinzipskizze, Prinzipbeschreibung, Beispielhardware zeigen, ...).
Zuletzt bearbeitet:
larsberghahn
Member
Hallo, zusammen mit einem Kumpel der auch Interesse an der Thematik hat habe ich mich jetzt den Nachmittag damit beschäftigt ein Fritzbox WLAN Mesh aufzubauen... Zusätzlich zur bestehenden 7530 sind zwei 7490 per Kabel und eine 7362sl dazugekommen. Noch eben 100m Netzwerkkabel verlegt und jetzt ist so wie es aussieht alles wichtige erstmal abgedeckt. Die Testfläche wo aktuell der RL 1000 seinen Dienst tut zwar am schwächsten aber dann ist das schonmal der Worst case....
Nicht nur zum Rasenmähen, auch sonst hat es ja durchaus seinen Reiz überall wlan zu haben...
Jetzt gucke ich gleich erstmal ob mir noch irgendwas fehlt und dann bestelle ich das wifi RTK Set...
An meinem Mower verwende ich aktuell die Original Odometriesensoren, das sind Hall Sensoren und auf der Motorwelle sitzt ein magnet. Habe die einfach angeschlossen und die impulse kamen... Leider sind es nur so 66 incremente pro Radumdrehung... Meint ihr ich habe eine chance dass das was wird?
MFG Lars
Nicht nur zum Rasenmähen, auch sonst hat es ja durchaus seinen Reiz überall wlan zu haben...
Jetzt gucke ich gleich erstmal ob mir noch irgendwas fehlt und dann bestelle ich das wifi RTK Set...
An meinem Mower verwende ich aktuell die Original Odometriesensoren, das sind Hall Sensoren und auf der Motorwelle sitzt ein magnet. Habe die einfach angeschlossen und die impulse kamen... Leider sind es nur so 66 incremente pro Radumdrehung... Meint ihr ich habe eine chance dass das was wird?
MFG Lars
Also die Anzahl der Impulse pro Umdrehung, den Raddurchmesser und den Radstand kannst du in der config.h einstellen.
66 Impulse bedeutet bei 20cm Raddurchmesser immerhin eine Auflösung von 1 cm, also schon eine gewisse Genauigkeit.
Notfalls musst du Encoder nachrüsten, oder die Motoren umbauen.
Ich würde es einfach probieren
66 Impulse bedeutet bei 20cm Raddurchmesser immerhin eine Auflösung von 1 cm, also schon eine gewisse Genauigkeit.
Notfalls musst du Encoder nachrüsten, oder die Motoren umbauen.
Ich würde es einfach probieren
larsberghahn
Member
Hallo, leider kommt mein RTK Set zusammen mit dem neuen Bluetooth Modul und dem neuen Gyro wohl nicht mehr vorm Wochenende an...
Zumindest konnte ich den Mäher aber mit Wlan und Laptop die Tage schon fernsteuern. Bluetooth hab ich dafür testweise auskommentiert.
Zur Odometrie, ich kann doch einfach den Interrupt von RISING auf CHANGE umstellen und habe die doppelte Anzahl an Impulsen oder? Ein/Aus Verhältnis scheint nach Messung mit Multimeter zu passen...
Ich kann zum testen nicht einfach das normale GPS Modul verwenden oder? Also versucht habe ich es, aber entweder hatte ich keinen Empfang oder die Daten sind anders...
MFG Lars
Zumindest konnte ich den Mäher aber mit Wlan und Laptop die Tage schon fernsteuern. Bluetooth hab ich dafür testweise auskommentiert.
Zur Odometrie, ich kann doch einfach den Interrupt von RISING auf CHANGE umstellen und habe die doppelte Anzahl an Impulsen oder? Ein/Aus Verhältnis scheint nach Messung mit Multimeter zu passen...
Ich kann zum testen nicht einfach das normale GPS Modul verwenden oder? Also versucht habe ich es, aber entweder hatte ich keinen Empfang oder die Daten sind anders...
MFG Lars
Hallo Lars,
Wenn das Ein-/Aus-Verhältnis passt, könnte das funktionieren. Mir ist nur nicht ganz klar, wie das setDebounce funktioniert, und ob das auch bei beiden Flanken funktioniert. Dafür musst du wohl in den Registern des Mikrocontrollers stöbern, oder auf Alexanders Antwort warten.
Ohne RTK kannst du vergessen. Die GPS-Koordinaten werden ja nicht nur für die absolute Position verwendet, sondern auch zur Bestimmung der Richtung, in der sich der Mower bewegt. Und die Sprünge zwischen zwei Messwerten sind bei herkömmlichem GPS so groß, dass damit keine sinnvolle Berechnung möglich ist, selbst wenn du alle Abfragen im Code nach "GPS-Float" und "GPS-FIx" raus wirfst.
Gruß Etienne
Wenn das Ein-/Aus-Verhältnis passt, könnte das funktionieren. Mir ist nur nicht ganz klar, wie das setDebounce funktioniert, und ob das auch bei beiden Flanken funktioniert. Dafür musst du wohl in den Registern des Mikrocontrollers stöbern, oder auf Alexanders Antwort warten.
void PinManager::setDebounce(int pin, int usecs){ // reject spikes shorter than usecs on pin
if(usecs){
g_APinDescription[pin].pPort -> PIO_IFER = g_APinDescription[pin].ulPin;
g_APinDescription[pin].pPort -> PIO_DIFSR |= g_APinDescription[pin].ulPin;
}
else {
g_APinDescription[pin].pPort -> PIO_IFDR = g_APinDescription[pin].ulPin;
g_APinDescription[pin].pPort -> PIO_DIFSR &=~ g_APinDescription[pin].ulPin;
return;
}
int div=(usecs/31)-1; if(div<0)div=0; if(div > 16383) div=16383;
g_APinDescription[pin].pPort -> PIO_SCDR = div;
}
if(usecs){
g_APinDescription[pin].pPort -> PIO_IFER = g_APinDescription[pin].ulPin;
g_APinDescription[pin].pPort -> PIO_DIFSR |= g_APinDescription[pin].ulPin;
}
else {
g_APinDescription[pin].pPort -> PIO_IFDR = g_APinDescription[pin].ulPin;
g_APinDescription[pin].pPort -> PIO_DIFSR &=~ g_APinDescription[pin].ulPin;
return;
}
int div=(usecs/31)-1; if(div<0)div=0; if(div > 16383) div=16383;
g_APinDescription[pin].pPort -> PIO_SCDR = div;
}
Ohne RTK kannst du vergessen. Die GPS-Koordinaten werden ja nicht nur für die absolute Position verwendet, sondern auch zur Bestimmung der Richtung, in der sich der Mower bewegt. Und die Sprünge zwischen zwei Messwerten sind bei herkömmlichem GPS so groß, dass damit keine sinnvolle Berechnung möglich ist, selbst wenn du alle Abfragen im Code nach "GPS-Float" und "GPS-FIx" raus wirfst.
Gruß Etienne
larsberghahn
Member
Hallo, ja ich werde es wohl abwarten müssen. Dann werde ich übers WE noch ein bisschen mit der Odometrie rumspielen und die WLAN Verbindung über den ESP-01 ist auch noch nicht so recht stabil, da hoffe ich dass ein Paar Kondensatoren mehr das Problem lösen.
Ich habe inzwischen den Code etwas studiert, die Rohdaten der Karte sind ja simpel, das finde ich schonmal sehr gut. Ich bin mir nur noch nicht sicher wie ich am Sinnvollsten mehrere Flächen darin abbilden kann... Ich könnte z.b. das ganze Grundstück als Perimeter abfahren und dann ein kleine Tool schreiben um die Flächen die gemäht werden sollen manuell auszuschraffieren. Dann würde ich mir wünschen wenn ich für jeden Wegpunkt noch zusätzliche Parameter zu der X und Y Coordinate angeben könnte wie Messer Aus oder die Fahrgeschwindigkeit in %... Und ggf. ein Warnton solange ich auf Wegen ausserhalb des Rasens die Fläche wechsele... Wäre so etwas auch für andere Interessant?
MFG Lars
Ich habe inzwischen den Code etwas studiert, die Rohdaten der Karte sind ja simpel, das finde ich schonmal sehr gut. Ich bin mir nur noch nicht sicher wie ich am Sinnvollsten mehrere Flächen darin abbilden kann... Ich könnte z.b. das ganze Grundstück als Perimeter abfahren und dann ein kleine Tool schreiben um die Flächen die gemäht werden sollen manuell auszuschraffieren. Dann würde ich mir wünschen wenn ich für jeden Wegpunkt noch zusätzliche Parameter zu der X und Y Coordinate angeben könnte wie Messer Aus oder die Fahrgeschwindigkeit in %... Und ggf. ein Warnton solange ich auf Wegen ausserhalb des Rasens die Fläche wechsele... Wäre so etwas auch für andere Interessant?
MFG Lars
Hallo,
also beim aktuellen Stand kannst du zumindest mehrere Maps auswählen, also für jede deiner Flächen und diese separat mähen.
Da aktuell das Zurückkehren zur Ladestation noch nicht implementiert ist, macht es wahrscheinlich noch keinen Sinn, mehrere Flächen automatisch anzufahren, da vorher der Akku leer sein wird.
Aber den Ansatz finde ich sehr interessant. Eine einfache Implementierung wäre einfach die Exclusions mit zusätzlichen Eigenschaften zu versehen.
Dann könnte man zwischen Flächen unterschieden, die nicht durchfahren werden dürfen (Baum, Pool, etc.) und solchen, die z.B. ohne Messer überfahren werden sollen (Wege, Terrassen) oder besonders langsam befahren werden (zu steil).
Gruß Etienne
also beim aktuellen Stand kannst du zumindest mehrere Maps auswählen, also für jede deiner Flächen und diese separat mähen.
Da aktuell das Zurückkehren zur Ladestation noch nicht implementiert ist, macht es wahrscheinlich noch keinen Sinn, mehrere Flächen automatisch anzufahren, da vorher der Akku leer sein wird.
Aber den Ansatz finde ich sehr interessant. Eine einfache Implementierung wäre einfach die Exclusions mit zusätzlichen Eigenschaften zu versehen.
Dann könnte man zwischen Flächen unterschieden, die nicht durchfahren werden dürfen (Baum, Pool, etc.) und solchen, die z.B. ohne Messer überfahren werden sollen (Wege, Terrassen) oder besonders langsam befahren werden (zu steil).
Gruß Etienne
larsberghahn
Member
Hallo,
jetzt ist tatsächlich heute doch schon das RTL-WLAN Set, der Gyro und das neue Bluetooth Modul angekommen. Ich habe gleich alles eingebaut, nochmal die aktuellste Version aus dem GitHub gezogen, meine Anpassungen gemacht und dann... Ich hatte gar nicht auf dem Schirm, dass ich bei SAPOS NRW erst einen Antrag auf nutzung stellen muss um dann ggf. Logindaten zu bekommen... Das ist jetzt natürlich ärgerlich, dass ich da dann doch erstmal noch nicht zu testen komme... Gibt es da evtl irgendeine Übergangslösung? Von irgendeinem Dienst wenn es dann auch nicht so ganz genau wird?
Noch einmal zur Odometrie, das umstellen von Interrupt RISING auf CHANGE hat einfach so funktioniert, jetzt habe ich 132 Impulse pro Meter, habe es auch wie in der Anleitung ausgemessen und es sieht gut aus. Ich habe in der motor.cpp für die Odometrie anstatt 50ms 200ms als Verarbeitungszyklus eingestellt und die PID-Werte noch etwas angepasst, also den P-Anteil runter auf 1.1 und den I-Anteil hoch auf 0.5... dadurch ist das vorher manchmal etwas ruppige verhalten besser geworden, bin mal gespannt...
MFG Lars
jetzt ist tatsächlich heute doch schon das RTL-WLAN Set, der Gyro und das neue Bluetooth Modul angekommen. Ich habe gleich alles eingebaut, nochmal die aktuellste Version aus dem GitHub gezogen, meine Anpassungen gemacht und dann... Ich hatte gar nicht auf dem Schirm, dass ich bei SAPOS NRW erst einen Antrag auf nutzung stellen muss um dann ggf. Logindaten zu bekommen... Das ist jetzt natürlich ärgerlich, dass ich da dann doch erstmal noch nicht zu testen komme... Gibt es da evtl irgendeine Übergangslösung? Von irgendeinem Dienst wenn es dann auch nicht so ganz genau wird?
Noch einmal zur Odometrie, das umstellen von Interrupt RISING auf CHANGE hat einfach so funktioniert, jetzt habe ich 132 Impulse pro Meter, habe es auch wie in der Anleitung ausgemessen und es sieht gut aus. Ich habe in der motor.cpp für die Odometrie anstatt 50ms 200ms als Verarbeitungszyklus eingestellt und die PID-Werte noch etwas angepasst, also den P-Anteil runter auf 1.1 und den I-Anteil hoch auf 0.5... dadurch ist das vorher manchmal etwas ruppige verhalten besser geworden, bin mal gespannt...
MFG Lars
larsberghahn
Member
Hier noch ein Foto vom aktuellen Testaufbau, das Chassis des RL1000 bietet zum Glück jede Menge platz... Ich habe das ESP01 per zusammengelöteter Stiftleisten höher gesetzt um den Empfang zu verbessern. Das RTK habe ich extra ganz vorne weit weg von allem positioniert in der Hoffnung dass es dort auch guten WLAN Empfang hat...
Anhänge
larsberghahn
Member
Hallo, nachdem ich heute meine Zugangsdaten für den SAPOS Dienst bekommen habe bin ich seit 2 Stunden am testen. Ich bekomme mit meinem Prototypen ein fix Signal und habe auch schonmal testweise ein 4-eck abgefahren, ausschraffiert und ihn losgeschickt um dieses abzufahren. Also das ganze mit der App funktioniert
ja 1A, ich bin echt mal gespannt was das noch gibt. Erstmal grosses Lob für die geleistete Arbeit...
Jetzt leider zu den 2 Problemen die ich habe...
Eines ist Hausgemacht, da ich ja nicht den Ardumower verwende und eine Odometrie mit zu wenig impulsen läuft der Antrieb nicht sauber.
Die Antriebe ziettern regelrecht vor sich hin, als wenn der PWM immer wieder über 0 geht. Dabei ist es egal, ob ich die Standarteinstellungen der
Firmware verwende oder dran rumspiele, ich bekomme es nicht beruhigt.
Ein anderes Problem welches mich viel mehr beschäftigt ist, dass irgendetwas zu haken scheint bzw. sich der Arduino mit irgendetwas beschäftigt was dazu
führt, dass alles total hakelig wird. Ich habe auch die Odometrie Interrupts mal deaktiviert, ich habe eine recht instabile Verbindung über Bluetooth sowohl als
auch über WLAN. Wenn ich den Mäher manuell vorwärts fahren lasse bleibt er irgendwann einfach stehen um dann irgendwann wieder weiterzufahren.
Genauso kommt es auch vor, dass er einfach immer weiterfährt obwohl ich längst losgelassen habe und sich dann vor einem Hindernis eingräbt.
Nach einer weile kommt auch immer die Meldung IMU Timeout. Ich habe die IMU mal abgesteckt und den Pullup Jumper auch, dann kommen beim start
auch nicht wie gewohnt die 8 Pieptöne aber danach sieht alles aus wie mit IMU Modul. Nur das haken und die Verbindungsabbrüche habe ich weiterhin.
Welche Möglichkeiten habe ich der Sache auf den Grund zu gehen?
MFG Lars
ja 1A, ich bin echt mal gespannt was das noch gibt. Erstmal grosses Lob für die geleistete Arbeit...
Jetzt leider zu den 2 Problemen die ich habe...
Eines ist Hausgemacht, da ich ja nicht den Ardumower verwende und eine Odometrie mit zu wenig impulsen läuft der Antrieb nicht sauber.
Die Antriebe ziettern regelrecht vor sich hin, als wenn der PWM immer wieder über 0 geht. Dabei ist es egal, ob ich die Standarteinstellungen der
Firmware verwende oder dran rumspiele, ich bekomme es nicht beruhigt.
Ein anderes Problem welches mich viel mehr beschäftigt ist, dass irgendetwas zu haken scheint bzw. sich der Arduino mit irgendetwas beschäftigt was dazu
führt, dass alles total hakelig wird. Ich habe auch die Odometrie Interrupts mal deaktiviert, ich habe eine recht instabile Verbindung über Bluetooth sowohl als
auch über WLAN. Wenn ich den Mäher manuell vorwärts fahren lasse bleibt er irgendwann einfach stehen um dann irgendwann wieder weiterzufahren.
Genauso kommt es auch vor, dass er einfach immer weiterfährt obwohl ich längst losgelassen habe und sich dann vor einem Hindernis eingräbt.
Nach einer weile kommt auch immer die Meldung IMU Timeout. Ich habe die IMU mal abgesteckt und den Pullup Jumper auch, dann kommen beim start
auch nicht wie gewohnt die 8 Pieptöne aber danach sieht alles aus wie mit IMU Modul. Nur das haken und die Verbindungsabbrüche habe ich weiterhin.
Welche Möglichkeiten habe ich der Sache auf den Grund zu gehen?
MFG Lars