obstacle avoidance / Hindernissumfahrung | sunray 1.0.97

Der Roboter hat offensichtlich kein "IMU-Recovery" probiert bei Dir - Ich habe das "IMU Recovery" etwas getuned - er sollte jetzt bei Dir ein Recovery probieren und bei einem I2C Fehler den I2C Bus resetten und das Mähen fortsetzen.
 
Zuletzt bearbeitet:
Super, vielen Dank.
Momentan steht er noch in der LS, ich will eigentlich nur sehen ob er alleine nach Ladevorgang raus kommt und die restlichen 3 Meter noch mäht.
Ansonsten, wirklich begeistert vom Mover, über 3h ohne irgendwelche Probleme gemäht. Ich musste mich überhaut nicht um ihn kümmern.
 
Ja, es wird langsam (sieht auch hier viel besser aus als vor einigen Wochen) - aber es braucht eine Zeit bis man alle Problemstellen nach und nach in den Griff bekommen hat :) (Technik halt...)
 
Zuletzt bearbeitet:
Ladestation klappt auch super, ist raus gekommen und wollte auch gleich fleißig loslegen.
Problem ist nur, wenn er aus der LS kommt ist er erst einmal immer etwas verwirrt. D.h. seine eigentliche Position unterscheidet sich gut 2 Meter von seiner Position in der Karte. Tagsüber bekommt er dann nach ein paar Minuten einen FIX oder zumindest die Genauigkeit von unter 0,05m und dann passt es meisst. Heute Abend scheint es etwas länger zu dauern ...

Geht das eigentlich nur mir so das er immer etwas Zeit braucht wenn er aus der LS kommt?
Meine LS ist nach oben geschlossen, ist schon klar das er da kein vernünftiges Signal bekommt.
Ich muss mal schauen ob ich nicht doch noch eine Plexiglasscheibe einarbeite damit zumindest der GPS - Empfänger freie Sicht nach oben hat. Des weiteren steht die LS auch direkt am Haus. Mitten auf dem Rasen habe ich keinen Strom, abgesehen davon ist die LS unterm Haus auch noch etwas geschützter.

Noch eine kurze Frage zur Ladezeit bzw. den Stromverbrauchsangaben in der App:
In der App wird ein ungefährer Stromverbrauch von 0,5A beim Mähen angezeigt und er mäht mit einer Akkuladung ungefähr 3h.
Die Ladeleistung wird in der App mit ca. 0,9A angezeigt und er lädt bei leerem Akku ungefähr 4h. Irgendwie passt das nicht oder habe ich einen Denkfehler?
In meiner config.h steht folgendes: #define CURRENT_FACTOR 0.5 // (non-bridged INA169, max. 2.5A)
INA habe ich nicht gebrückt.
 
Irgendwas passt glaube ich generell nicht an der A und V anzeige / Berechnung in der App. Die Voltzahl lt. App ist geringer als die tatsächliche.
Würden die 0.5A verbraucht bei dir stimmen, würde der Standardakku ja auch ~9h statt 3h reichen. Das Netzteil aus dem Shop hat auch einen Ladestrom von 2A; in der App geht der Ladestrom nicht über 1A
 
Ja, habe ich mir schon irgendwie gedacht. wobei ich es ziemlich nebensächlich finde.
Hauptsache, man sieht in der App das geladen wird, ein einfaches Batteriesymbol mit Balken würde bestimmt auch reichen und ist eh massentauglicher. Meine bessere Hälfte kann mit den Zahlen gar nichts anfangen, deswegen habe ich ihr in die Ladestation noch eine grüne und rote LED eingebaut.
IMG_20200905_084638724.jpg
 
Die Stromverbrauchswerte (A) werden einzeln über alle Motortreiber ermittelt und dann eine Summe gebildet. Der Stromverbrauch des Rest-Systems kann übrings mit PCB1.3 nicht ermittelt werden. Da die Motortreiber im niedrigeren Strom-Bereich (ca. unter 500mA) auch gern mal nur die Hälfte anzeigen ergeben sich dann in der Summe ziemlich ungenaue Gesamt-Verbrauchswerte.
Und dann spielt auch noch die PWM-Frequenz bei der Ansteuerung eine Rolle um eine einigermaßen lineare Kennlinie aus den Treibern für die Stromwerte zu bekommen ( hier wurde mal eine Vergleichsmessung für verschiedene PWM-Frequenzen und linear ansteigende Motorlast gemacht und man sieht schön wie die Treiberstrom-Kennlinien dabei verlaufen : https://wiki.ardumower.de/index.php?title=Wheel_Motor#Control_principal_:_PWM_frequency ).
Ich werde schauen ob wir die PWM-Frequenz ändern können um die Messgenauigkeit der Motortreiber im unteren Bereich etwas zu erhöhen.
 
Zuletzt bearbeitet:
Warum nicht einfach einen Stromsensor direkt hinter den Akku und über den Bus die Werte auslesen? So hätte man doch die realen Werte ohne die ganzen Störfaktoren.

Ganz so nebensächlich finde ich es nicht, denn immerhin sind die ermittelten Werte ja auch die Grundlage dafür wann ein Akku leer ist oder wann eine Überlastung auftritt. Im Moment denkt der Mäher das der Akku leer ist und er laden will; obwohl er eben noch nicht leer ist. Dadurch sinkt ja der nutzbare Bereich des Akkus.
Wenn die A Zahl zu gering gemessen wird, kann es auch sein das die PCB überlastet und ne Sicherung fliegt. Ist nicht das dringenste, aber schon sinnvoll wenn es funktioniert.
 
@kermi Du kannst einen einfachen Mikroschalter an die Bumper-Pins (Left/Right) anschliessen (Pins Left/Right gegen Masse/GND). Es wird bei Betätigung ein Hindernis-Trigger ausgelöst.
 
Wenn dann der Bumper funktioniert macht dann überhaupt noch das Sonar Sinn? Wird bei der Hinderniserkennung dann eine Kombination aus Bumper und Sonar herangezogen oder wird einfach ein reagiert, egal, wer auslöst?
 
Es wird alles gleich behandelt (Ultraschall-Auslöer, Bumper-Auslöser, keine GPS-Bewegung) und dann ein Hindernis ausgelöst. Je nachdem was in der config.h aktiviert werden die Sensoren aktiviert.
 
Super, vielen Dank.
Die wirklich sicherste Methode für Hinderniserkennung sollte dann ja wohl der Bumper sein. Hätte den Vorteil das der Mäher bei z.B. schnell gewachsenem Löwenzahn keinen Bogen herum macht und auch bei herunter hängenden Zweigen weiter fährt.
 
Ein Bumper wie der Bosch Indego 1200 wäre top, wo nicht nur unten im Mähbereich sondern auch oben am Gehäuse, oder von beiden Seiten bei Drehbewegung gegen einen Baum reagiert. Und eventuell noch ein Bumper für das Rückwärtsfahren gegen einen Baum, sofern der Ardumower auch in so eine Situation kommt. Obwohl Bosch es beim Indego 1200 bis heute nicht fertig gebracht hat, das dieser dann vorwärts fährt, anstatt noch mehr gegen das Hinderniss im Rücken und dann stehen bleibt. Vielleicht könnte man ein Art Gehäuse oben drüber bauen auf vier Federn lagern und in der Mitte ein Joystick aus der Zeit des Commodore C64 oder Amiga als Sensor verwenden.
 
Man müsste erst einmal schauen wie man das technisch vorne mit dem federgelagerten Bumper löst. Dipschalter kann man ja ein paar mehr anbringen und dann parallel schalten. Ich glaube das wird eine lustige Bastelaufgabe für den Winter.
 
Es wird alles gleich behandelt (Ultraschall-Auslöer, Bumper-Auslöser, keine GPS-Bewegung) und dann ein Hindernis ausgelöst. Je nachdem was in der config.h aktiviert werden die Sensoren aktiviert.
Certainly it's better to use the Ultra sonic to only reduce the speed and leave the bumper do the real contact. ;)
This avoid reverse under very high grass or some tree like weeping willow tree.It's what append here:
Anhang anzeigen sonar.mp4
 
Zuletzt bearbeitet:
Oben