Menü
Aktuelles
Von:
Filter

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

Lemming schrieb:
@FelixP: Du solltest unbedingt, wie im Sunray Wiki beschrieben, die GPS Reflexionen filtern/dämpfen. Ich hatte diese Probleme anfangs ohne Filter auch.

Ardumower Sunray – www.wiki.ardumower.de

wiki.ardumower.de wiki.ardumower.de
Zum Vergrößern anklicken....
Vielen Dank für den Hinweis. Habe gerade mein Modul ausgebaut und an das u-Center angeschlossen. Die Werte waren leider schon so eingestellt.
Min SV Elevation: 10 [deg]
C/N0 Threshold : 10 [#SVs]
30 [dbHz]
Was kann ich sonst noch verbessern? Oder ergäbe es Sinn, mit den Werten zu experimentieren?
 
Alexander könnte dir wahrscheinlich bessere Tipps geben wie Du es zur Laufzeit debuggen kannst. Bei mir fehlt einfach oft die WLAN Verbindung zum Korrekturdatensender und dann bleibt der Mäher stehen. (#define REQUIRE_VALID_GPS true)
Ich hab noch nicht so im Detail in die Debugausgabe der App gesehen, möglicherweise findest Du da schon einen Anhaltspunkt.
 
Ist dies der beste Thread, um die neueste Sunray-Firmware zu diskutieren?

Ich habe die neueste Version mit den Motorüberlastungsänderungen "more low-pass filtering for gear motors current " installiert. Ich finde, dass der Mäher viel empfindlicher gegen Überlastung ist und ziemlich leicht anhält. Sind die Werte in motor.cpp konservativ und können sie möglicherweise als konfigurierbarer Wert erhöht werden?

motorLeftOverload = (motorLeftSenseLP> 0.8);
motorRightOverload = (motorRightSenseLP> 0.8);
motorMowOverload = (motorMowSenseLP> 1.5);

Aus einigen begrenzten Beobachtungen geht hervor, dass der Überlastungsfehler auftritt, nachdem der Mäher längeres Gras durchlaufen hat, nicht während der Zeit der zusätzlichen Belastung.

Ich habe ein großes Gebiet mit etwas abfallendem Boden, so dass ich Tests unter verschiedenen Bedingungen durchführen kann, wenn es hilfreich ist.

Al
 
Hallo h-parva,
ich habe die Werte konservativer eingestellt (Firmware 1.0.71) - vielleicht kannst Du nochmal testen und Feedback geben - Danke :)
Gruss,
Alexander
 
Interessant wäre ja auch (für die Zukunft) eine lastabhängige Geschwindigkeitsregelung, so dass abhängig vom motorMowSenseLP bei langem Gras die Fahrgeschwindigkeit automatisch reduziert wird. Vielleicht reicht dafür schon eine einfache Zweipunktregelung anstatt PID Regler. Das würde zusätzlich dafür sorgen, dass er nicht so oft wegen Overload stehenbleibt.
 
Hi Alexander große Klasse was du da machst, ich habe schon 2x den Mower fähren und Mähen lassen. Am Wochende mach ich mal ein Video wie er bei mir Bahnen abfährt. Werde ich in Youtube hochladen. Kann man den Akku Justieren? Er zeigt genau 1 Volt weniger an als was der Akku hat ist ein 2x 7S Akku mit 18650 Samsung Zellen 3500mha.
Wenn ich diese Zeile in der Batterie.cpp so ändere Zeigt er in der App die richtige Akku Voltzahl an.
batteryFactor = (100+10) / 9.62; // (10 vorher) ADC voltage to battery voltage
Allerdings zeigt er dann beim Laden 1 Volt zuviel an und macht bei knapp 28,5V schluss.
In der app steht dann 30V ,das Ladegerät macht genau 29,4v ist nachgemessen ,alles aus dem Shop wie alles andere auch z.b RTK Spezial Kit .
Da ich schon viel Rasen habe schafft er das nicht mit einer Ladung und es fehlt gar nicht viel.
LG Michael
 
@greymfm76: Das Docking klappt soweit wunderbar, aber beim Ausdocken müsste er doch eigentlich rückwärts rausfahren, um aus seiner Hütte zu kommen. Wenigstens bis zum ersten Wegpunkt außerhalb des Docks. Ansonsten reißt er beim Wenden im Dock die Ladekontakte ab? Oder liegt das an meiner IMU ohne Kompass, dass er seine Position im Dock nicht richtig einschätzt?

Außerdem müssten die angelernten Docking-Wegpunkte doch in umgekehrter Reihenfolge abgefahren werden, oder? Im Augenblick fährt er scheinrbar Querbeet in Richtung Perimeter wenn er im Dock steht und ich auf "Start" drücke. Oder muss ich dann erst die Karte nochmal neu berechnen und übertragen? Irgendwas mache ich scheinbar falsch....
 
@greymfm76: Danke, jetzt verstehe ich es. Da unser Mower noch keine Hundehütte mit Ladekontakten hat, hatte ich das Abdocken nur "trocken" ausprobiert. Also fährt er nur rückwärts aus dem Dock wenn er geladen wird. Könntest Du die Dockerkennung vielleicht noch etwas erweitern? Wenn er den Start-Befehl bekommt und er sich innerhalb von, sagen wir mal, 10 Zentimetern von seiner Dock Position befindet, dann soll er erstmal gerade rückwärts fahren (er hat ja noch keine genaue Richtung ohne Kompass, falls er gerade erst eingeschaltet wurde), bis er den vorletzten Docking Punkt erreicht? Da sie per Definition in gerader Linie verbunden sind, müsste das ja eigentlich immer klappen.
 
afaik schaltet er sich gar nicht aus wenn er geladen wird. Nur wenn ersteht sollte er ausgehen. Er lädt ja auch nur wenn er an ist.

Sinnvoll wäre noch das der Mähmotor erst startet und dann 2~3 sekunden später erst das fahren anfängt. wenn er z.B. ein Hindernis erkannt hat und dann wieder gestartet wird, dann fährt er mit geringer messerdrehzahl direkt übers Gras.
 
@holunder Ja, das hatte ich auch schonmal angemerkt. Bei unserem Mower dauert es gefühlt 10 Sekunden bis die Scheibe mal auf Nenndrehzahl ist.

@greymfm76 Alexander, ich weiß, wir sind hier nicht bei "Wünsch dir was" ;) aber vielleicht kannst Du irgendwo eine öffentlich einsehbare Ideensammlung aufmachen? Eventuell können sich die "Kunden" dann besser abstimmen und sehen auch woran schon gedacht oder gearbeitet wird.
 
@greymfm76 Ich beobachte periodische Prüfsummenfehler, die genau jede Minute auftreten. Das kann kein Zufall sein? Habe ich vergessen eine bestimmte ublox Nachricht zu deaktivieren die nicht erwartet wird?

10:40:58.012 -> ublox chka error, msgclass=1, msgid=14, msglen=24: 5!=7F
10:41:58.036 -> ublox chka error, msgclass=1, msgid=14, msglen=24: 29!=C
10:42:58.019 -> ublox chka error, msgclass=1, msgid=14, msglen=24: 2A!=DC
10:43:58.033 -> ublox chka error, msgclass=1, msgid=14, msglen=24: 5!=FF
10:44:58.001 -> ublox chka error, msgclass=1, msgid=14, msglen=24: 8A!=44
10:45:58.023 -> ublox chkb error, msgclass=1, msgid=7, msglen=5C: B5!=27
 
@greymfm76 Nein, noch nicht, guter Tipp. Ich habe aber deine Prüfsummenberechnung und den Zustandsautomaten verstanden, die ublox Telegramme mal mitgeschreiben. Sieht gut aus. (y) Ich meld mich gleich wieder wenn ich den Puffer vergrößert habe...

Ja, das hat definitiv geholfen. Außer kurz nach dem Reset gibt es jetzt keine Prüfsummenfehler mehr.

13:40:36.520 -> WIFI (ESP8266) not found!
13:40:36.520 -> MPU ID=0x68
13:40:36.520 -> MPU6050/9150 found
13:40:37.826 -> CHARGER CONNECTED
13:40:37.826 -> enableCharging 1
13:40:38.027 -> temp=998.0 humidity=998
13:40:38.027 -> ctlDur=inf op=0 freem=40879 volt=28.88 chg=0.01 tg=0.00,0.00 x=0.00 y=0.00 delta=0.00 tow=560456000 lon=8.x lat=52.x n=0.00 e=0.00 d=0.00 sol=0 age=7.51
13:40:38.128 -> ublox chka error, msgclass=1, msgid=3C, msglen=40: 28!=D7
13:40:38.931 -> IMU gyro calibration (robot must be static)... 1
13:40:39.987 -> IMU gyro calibration (robot must be static)... 2
13:40:41.040 -> IMU gyro calibration (robot must be static)... 3
13:40:42.098 -> IMU gyro calibration (robot must be static)... 4
13:40:43.049 -> ctlDur=inf op=0 freem=40879 volt=28.72 chg=0.71 tg=0.00,0.00 x=0.00 y=0.00 delta=0.00 tow=560462200 lon=8.x lat=52.x n=0.00 e=0.00 d=0.00 sol=0 age=0.07
13:40:43.149 -> IMU gyro calibration (robot must be static)... 5
13:40:44.209 -> IMU gyro calibration (robot must be static)... 6
13:40:45.298 -> IMU gyro calibration (robot must be static)... 7
13:40:46.356 -> IMU gyro calibration (robot must be static)... 8
13:40:47.408 -> IMU gyro calibration (robot must be static)... 9
13:40:47.408 ->
13:40:47.461 -> setOperation op=2
13:40:47.825 -> enableCharging 0
 
Zuletzt bearbeitet:
Nein, doch kein Bug - ich habe die Berechnung mitsamt Formeln mal im Code erklärt...
 
Zuletzt bearbeitet:
@greymfm76 Naja, doch ein Bug, aber anders als wir dachten. ;) Ich hatte mich über die Anzeige vom Ladestrom 1,2A gewundert, weil ich mit einem Konstantstrom 2,5A geladen habe. Gestern Abend noch schnell am INA nachgemessen: Spannungsabfall über dem Widerstand 250mV (2,5A*0,1Ohm, passt), Output 2,5V -> 2,5V/2,5A = 1. Die Sache ist allerdings, dass der INA scheinbar nie mehr als 2,5V rausgibt, egal wie hoch der Strom ist. :) Für mein Netzteil müsste ich also den 5A Bereich am INA wählen und den Multi in der Software ändern. Wäre also schön, wenn Du den Multi in die config.h packst, damit ihn jeder für sich einstellen kann.

Das Standard-Netzteil macht doch 2A (zumindeest nach Aufdruck) und somit müsste der INA damit auch schon in Begrenzung gewesen sein. Warum fiel das bisher nicht auf? Hatte der Mega früher eine IOREF=5V? Dann würde es das erklären. Der Due hat IOREF=3,3V. [Nachtrag: Ja, genau so ist es.) Nach Datenblatt des INA169 liegt sein maximaler Ausgangspegel bei:
typ. (V+) - 0,9V = 3,3V - 0,9V = 2,4V (Das passt dann zu meiner Messung von gestern...)
max. (V+) - 1,2V = 3,3V - 1,2V = 2,1V <=> 1,05A bei x20 bzw. 2,1A bei x10
bzw. nach Kap. 7.3.1: (V+) - 0,7V - (Vin+ - Vin-) = 3,3V - 0,7V - 0,5V [bei 5A]= 2,0V

Demnach müsste man in der Aufbauanleitung eigentlich schreiben, dass die 5A Brücke standardmäßig gesetzt werden und der currentFactor=1,0 sein sollte?
Genaugenommen handelt es sich hier auch um AVREF(AREF), nicht IOREF. Diese sind allerdings auf dem Due Board verbunden.

Der INA169 Stromsensor

Der INA169 Stromsensor wir in dem Ardumower und in der Ladestation verwendet um verschiedene Ströme zu messen
forum.ardumower.de
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben