Menü
Aktuelles
Von:
Filter

Sunray modding Spielwiese

Okay, die letzte Version 318 und 319 war sehr verbuggt. Diese am besten nicht laden..

Ich hab mir die Zeit genommen und etwas Debugging betrieben:

- Mähmotor ein/aus scenarios verringert..
- Fährt nicht mehr irgendwohin und kidnpped sich selbst...
- Wartet jetzt auf den Mähmotor mit MOWSPINUPTIME
- ESCAPELAWNWAITTIME zur erholung der Mähmotordrahzahl funktioniert jetzt

was immer noch nicht behoben ist:
-escapelawn führt manchmal dazu, das der mower danach umdreht un eine retrylastmowpoint operation macht, das heißt er fährt die bahn oder die bahn zum letzten obstaclepunkt nocheinmal
- wenn in einer obstacle avoidance oder bei drehen zum nächsten nahen punkt an bahnenden kommt es manchmal kurz zu unbeabsichtigten sehr langsamen mowergeschwindigkeiten wenn der mower in einem retryslow oder keepslow state vom adaptive speed ist

Hab diese Version getestet und funktioniert bis auf die BUGs sehr gut, Cassandra läuft auch super:

Sunray-master_follow_working-319mod.zip

Achso, am besten SD-Log ausschaltenwenn es dann gut läuft!
 
Mr. Tree schrieb:
Japp, genau das habe ich auch so diagnostiziert. Manuelles minimales Drehen des Motorshafts behebt den Fehler.
Das Problemi ist, Sunray will den Treiber ja resetten und schickt auch das Signal... Nur nützt es nichts. Dieser HAL fehler lässt sich nicht resetten.
Es liegt ein unlogischer Status an den Halleingängen vom TreiberChip an, z.b UVW:0,0,0... es muss aber mindestens einer eine 1 haben, der Treiber weis in diesem Moment nicht was er machen soll... Bis ich etwas dazu im Netz gefunden hatte hab ich ewig recherchiert. Irgendwer wollte eine Turbine oder so bauen, und nach längerer Standzeit ging das nicht mehr an... DRV8.. irgendwas.. also der gleiche chip wie die April Ardumower Treiber.
Wenn du da Recherchieren willst, schau dir auch die Treiber configs im src Ordner an.

Wegen Motortest: Ich glaube es ist Motor::plot, das sollte dir einen Graphen ausspucken im SerialPlot Tool

Ich habe gerade wieder den Originalen Code reingezogen...
Zum Vergrößern anklicken....
Hallo Mr Tree,
Habe mir wie gesagt den Code hierzu angesehen und die entsprehenden Foren gelesen. Stand der Feststellungen:
  1. Ja, es gibt Benutzer bei denen ein ungültiger Status der HAL Sensoren ansteht (ungültig ist 0,0,0 und 1,1,1). Dies ist abhängig vom den mechanischen Positionen der HAL Sensoren im Motor und sollte nicht vorkommen. Dies führt unweigerlich dazu dass der Controller nicht weiss was er tun soll und der Motor nicht startet sondern einen Fehler ausgibt. Bei mir startet der Motor aber trotz einer gültigen Hall-Sensor Messung (nachgemessen) nach einer Weile trotzdem nicht.
  2. Ich denke dass auf dem Schema von Bernd's Brushles Motordriver eine Inkonsistenz mit der Platine ist. Die Widerstandsbatterie die an Pin 20,21,22 (Break, Dir, Enable) des DRV8308 hänkt, ist keine 4,7kOhm, sondern eine 10kOhm. Ausserdem denke ich, ist der Enable Pin auf der Platine nicht über den Widerstand auf Ground sondern an VREG drauf. Bernd könnte das eventuell bestätigen. Der Enable hat einen internen Pulldown im DRV8308, mit dem externen Pulldown würde es schwer den aus dem float zu bekommen.
  3. In der Doku zum Controller steht dass der Controller Enabled werden soll, aber auch disabled (!Enable) wenn nicht gebraucht. ActiveLow setzt den controller in den Standby Modus. Obwohl auf der Platine und in der Software vorgesehen, wechselt der ENABLE Ausgang bei mir nie. Dies tut er nicht, da in der AmRobotDriver.cpp die Variable DRV8308.disableAtPwmZeroSpeed auf "false" steht. Setzt man sie auf true, klappts trotzdem nicht, da in der Funktion "setMotorPwm" der enableMow nur gesetzt wird wenn der mowPwm gleich 0 ist. Dies wird er nie da der minPwmSpeed für den DRV8308 auf 2 steht. Habe jetzt folgende Anpassungen gemacht:
    DRV8308.disableAtPwmZeroSpeed=true; //war auf false

    und folgende Zeilen in der setMotorPwm Funktion angepasst:
    // disable driver at zero speed (brake function) bool enableGears = gearsDriverChip.enableActive;
    bool enableMow = mowDriverChip.enableActive;
    if (gearsDriverChip.disableAtPwmZeroSpeed){
    if ((abs(leftPwm) <= gearsDriverChip.minPwmSpeed) && (abs(rightPwm) <= gearsDriverChip.minPwmSpeed)){
    enableGears = !gearsDriverChip.enableActive;
    }
    digitalWrite(pinMotorEnable, enableGears);
    }
    if (mowDriverChip.disableAtPwmZeroSpeed){
    if (abs(mowPwm) <= mowDriverChip.minPwmSpeed) {
    if (mowDriverChip.disableAtPwmZeroSpeed){
    enableMow = !mowDriverChip.enableActive;
    }
    }
    digitalWrite(pinMotorMowEnable, enableMow);
    }
    Damit wird der Controller jetzt aktiviert und deaktiviert (habs nachgemessen). Weiss noch nicht wie die Brake steht, kann also sein dass diese jetzt nicht mehr wie gewünscht funktioniert (er im Hang also nicht mehr stehen bleibt). Die nächsten Tage werden zeigen ob er nach einigen Stunden Stillstand wieder anläuft und mit dem ankommenden ENABLE das Problem gelöst ist.
NACHTRAG: Hat nichts gebracht, obwohl das Enable Signal am Controller ankommt, stehen jetzt alle 3 nach einer Stunde Standzeit. Der DRV8308 treibt mich noch in den Wahnsinn...

Die Spannungsversorgung (HAL+) der HAL-Sensoren einmal auftrennen, erweckt den Controller wieder zum Leben und damit läuft auch der Motor wieder. Hal+ sollte an VREG liegen, und VREG sollte bei deaktiviertem ENABLE seine 5V runterfahren, tut er aber nicht. @BerndS, ne Idee warum er das nicht tut?

NACHTRAG 2: Zusätzlich dazu dass es das Problem mit dem Controller nicht gelöst hat, funktioniert die Bremse beim deaktivieren des Enable auch nicht mehr. Der Mower läuft bei jeder kleinen Pause am Hang Richtung Tal. Hab die DRV8308.disableAtPwmZeroSpeed wieder auf "true" gesetzt.

@Mr Tree, weisst du wie stark man die Ausgänge (Arduino Pin 28 3,3V) zum Enable belasten kann? Die müssten ja über einen Level Shifter zum Brushless Treiber kommen (hier messe ich 4,8 Volt, kommen aber eventuell von VReg aus dem Controller). Da das Enable so ja keinen Sinn macht, könnte man diese nicht als Spannungsversorgung für die HAL Sensoren nutzen? Dann hätte man die Möglichkeit die HAL's Spannungsfrei zu schalten, ohne ein Relais zu verbauen.... das wird dann wohl die nächste Untersuchung werden ;-)
 
Zuletzt bearbeitet:
Vielen Dank für deine Arbeit...ich wollte heute auch direkt testen. Bekomme aber leider eine Fehlermeldung beim kompilieren.

1716138628394.png
 
Wow @Horsi70 , da hast du ja eine Recherche hinter dir!
@spranz : lad dir einfach die running median bibliothek Im Arduino ide oder compiler deiner Wahl runter oder ersetze die rc_model.cpp und .h mit der originalen.

Bedeutet das, das ein einfaches Relais auftrennen des hal signals eine lösung wäre?
 
Wenn der Treiber disabled wird, verliert er also nie seine vreg Spannung am Eingang.. da wäre also auch ein Ansatz Punkt... Aber die Hardware dazu hatte svolo schon beschrieben. Läuft auf ein Relais Mut ein paar widerständen hinaus.
 
Mr. Tree schrieb:
Wenn der Treiber disabled wird, verliert er also nie seine vreg Spannung am Eingang.. da wäre also auch ein Ansatz Punkt... Aber die Hardware dazu hatte svolo schon beschrieben. Läuft auf ein Relais Mut ein paar widerständen hinaus.
Zum Vergrößern anklicken....
Nochmal danke für deinen Einsatz. Die Geschichte von svolo habe ich komplett verbaut jedoch unterstützt deine Version das nicht. Bei svolos letzter Version waren viele andere Probleme so das ich das nicht mehr testen konnte ob es funktioniert. Dann war er nicht mehr im Forum. Es ist auch jemand Fall eine 100% Lösung wenn sie von der Software unterstützt wird, einmal vor dem ausdocken. Schau mal ob du das noch eingebaut bekommst.
 
Also das sollte recht einfach über ein relais sein... im fall des motorfaults muss einfach das relay ein signal bekommen für eine halbe sekunde aus und dann wieder einzuschalten. der rest macht der motorfaultresetcode bzw. muss das nur da mit rein und am besten nur wenn noch docked also chargerconnected == true.
 
So, ich habe nochmal ein wenig aufgeräumt, besonders die debugginng logs die noch gespamt wurden. Mower läuft bei mir gerade sehr gut, auch bei hochgras.

Weiterhin habe ich die escapelawnwaitime zur erholung der mähmotordrehzahl nur beim zweiten versuch innerhalb des resettimers verändert. Dann bleibt die dynamik erhalten, aber wenn er an eine hartnäckige stelle kommt nimmt er sich bei wiederholungen zeit, weil dann liegt da ja auch ne menge weed rum.

Sunray-master_follow_working-319.1mod.zip
 
@Mr. Tree
besten Dank für Deine unermüdliche Arbeit. Deine Version 319.1mod hat das potential meine neue Standart-Version zu werden.

Ich bin eigentlich fast nur am lesen und testen... falle aber immer auf meine alte 1.0.284 zurück weil da für meinen Garten das meiste passt. Doch Deine 319.1mod läuft bis jetzt so riesig... ich bin begeistert. (y)

Beste Grüße

Martin
 
Danke für die Blumen, wenn du auf Bugs triffst dann dokumentier die bitte kurz hier. Freut mich das es für dich erstmal gut funktioniert.
Ansonsten Happy Testing und cheers.
 
Hi,
hier noch ein Beitrag zum Thema, dann beweg ich den Mower halt regelmäßig in der Station, damit die Halls nicht in den Zustand 000/111 fallen.
Ziel ist. den Mower nach einer definierten Zeit ein wenig Rückwärts zu bewegen, zu stoppen und wieder vor zu bewegen. Das klappt auch ganz gut, ein Langzeittest steht aber aus, da grade Dauerregen.
In die config gehören dazu 3 Zeilen:
Code: 
#define MOVE_REGULARLY 1 //kk: move mower to keep 8308 alive
#define MOVE_AGAIN_AFTER 0.25 //kk:  move the mower every xx minutes
#define MOVING_TIME 250    //kk: time (ms) moving backwards

Die eigentliche Arbeit findet dann in der src/op/ChargeOp.cp statt, die hab ich angehängt. Die zusätzlichen Passagen sind gekennzeichnet.
Die Tests hab ich mit einer 1.0.311 gemacht.

Viele Grüße,
Jürgen
 
Wenn das klappt Bau ich das auch gleich ein!

Du musst mal gucken, Dateianhänge funktionieren meistens nicht. Vllt einfach als Code Tag posten
 
JSON Karte importieren:
Datenquellverwaltung 1716448726609.png -> Vektor -> Datei->Vektordatensätze: DeinGarten.json -> Hinzufügen -> Layer hinzufügen
Raster: Verarbeitung -> Werkzeugkiste (so, dass rechts Verarb. Werkzeuge zu sehen) -> Vektorerzeugung -> Gitter erzeugen (Doppelklick) -> Gitter KBS: EPSG:5833 wählen aus Compound -> Gitterausdehnung wählen -> Abstände wählen, z.B. 10 cm -> Überlagerung soll 0 bleiben -> Starte -> Schließen

1716449212691.png


Das ist DAS Werkzeug zur Kartenbearbeitung!!! Vielen Dank für den Fund, Mr. Tree!
 
Ich habe ein kleines Update gemacht:

- escapefForward bei Obstaclerotation ist in der config.h wieder aktiviert
- ROTATION_TIMEOUT in der Obstacle sektion der config.h eingefügt, war standardmäßig fest auf 15000. Jetzt 8000 (langer trigger um escapeforward auszulösen)
- ROTATION_TIME in der Obstacle sektion der config.h eingefügt, war standardmäßig auf 3000. Jetzt 2000 (schneller imubasierter trigger der eine winkeldifferenz erkennt und escapeforward auslöst)

Sunray-master_follow_working-319.2mod.zip
 
In dieser Version ist der Versuch von @jklotzek die DRV8308 treiber vor dem Hängen bleiben softwareseitig zu hindern integriert.
Muss aber aktiviert werden! Dafür in der config.h oben in der tuning sektion MOVE_REGULARLY = True setzen.
Den PWM DRV8308_FIX Versuch habe ich jetzt standardmäßig wieder deaktiviert... Wer damit noch rumprobieren will muss es auch erst wieder aktivieren.

Sunray-master_follow_working-319.3mod.zip
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben