Menü
Aktuelles
Von:
Filter

ZS-X11D1 (JYQD2021) Treiber und Sunray

EinEinach schrieb:
Jetzt ist natürlich die Frage, ob wir 500ms brauchen oder reicht es den Brake Pin und Dir Pin einfach kurz zurückzusetzen. Und mein Code ist natürlich quick und durty mit dem delay(500) lege ich natürlich den ganzen Programablauf still. Das kann man deutlich besser machen
Zum Vergrößern anklicken....
ja delay ist immer etwas tricky...probieren geht über studieren :)

Code hab ich schon auf meine fette Herbine geschrieben, heute sind auch noch die sehnlichst erwarteten Mosfettrigger für die stärkeren Mähmotoren gekommen, die werde ich jetzt mal an den Enable-Ausgang des Brushlessadapters anschließen. Montag geht dann das Testen los
 
So heute bin ich mit dem delay(200) gefahren und es gab einen Recovery Versuch, hat auch funktioniert.

Im nächsten Schritt schmeiße ich den delay komplett weg.

Gruß
Alexander
 
So heute endlich mal dazu gekommen bisschen rum zu testen... aber richtig schlau bin ich nicht geworden.

Bild 1:
Roboter aus dem Keller geholt, angesteckt und Software aufgespielt mit dem Pin Reset + Delay auf 200ms (Fehlermeldung steht noch 500ms)
Gebootet und 1 Meter vor und zurück gefahren und am laufenden Band die Recoverys drin gehabt.
Der Roboter lies sich aber perfekt steuern, keine Ausfälle gehabt.


Danach den Code angepasst und Pin Reset + Delay rausgenommen aber den Console Print drin gelassen um zu sehen ob er den Recovery Prozess durchläuft.
Dann 100x hin und zurück gefahren, kein einziger Fehler! Egal was ich versucht hab, konnte das nicht provozieren.

Bild 2:
Testweise den Roboter 10min stromlos in die Ecke gestellt und danach gestartet... dann dauerhaft Meldungen im Monitor gehabt aber Roboter lief weiterhin perfekt.
Keine Ahnung warum der Linke Motor die ganze zeit Meldungen wirft, Steuerung nimmt er aber perfekt an.
Selbst im Stillstand gehen die Meldungen im Endlosstream weiter, er schafft aber keinen Recovery.


Bild 3:
Also nochmal den Code mit 200ms Delay und Pin Reset rein und Roboter stromlos gemacht.
Hier kam dann nur 1x die Meldung mit Reset der erfolgreich war, denke aber das war mehr Zufall denn im Bild 1 hat er den "Recovery" ja auch scheinbar nicht geschafft.

Jedenfalls alles doch sehr schwer zu reproduzieren, Ausfall von einem Rad (ohne Reset+Delay Code) konnte ich trotz 100x hin und her fahren nicht provozieren.
Beim Karten einmessen vor paar Wochen ist mir da jeweils das Rad (beide Seiten) nach gefühlt 1min mehrfach weg geflogen.
Ich lasse jetzt mal den Reset + 200ms Delay drin und teste mal das einmessen der Karte erneut, ob er das erfolgreich ohne Ausfall schafft.

Hab auch noch einen weiteren Treiber hier... eventuell tausch ich mal den linken bzw. kontrollier mal alle Kabel, nicht dass es einfach ein Hardware Problem ist aber mit dem eigentlichen Problem gar nichts zu tun hat.
 

Anhänge

  • 1.png
    1.png
    102,1 KB · Aufrufe: 11
  • 2.png
    2.png
    161,3 KB · Aufrufe: 11
  • 3.png
    3.png
    91 KB · Aufrufe: 11
Oh du hast
Code: 
// should the motor fault (error) detection be enabled?
#define ENABLE_FAULT_DETECTION  true
drin

Der Pin ist bei uns nicht angeschlossen, bzw. wir haben keinen Fault Pin. Stell das auf false. Dann sollten die Fehlermeldungen verschwinden
 
Das würde dass natürlich auch erklären, nehme ich mal raus und beobachte es weiterhin.
Wobei echt seltsam wie random dass dann scheinbar auftritt.
 
EinEinach schrieb:
So heute bin ich mit dem delay(200) gefahren und es gab einen Recovery Versuch, hat auch funktioniert.

Im nächsten Schritt schmeiße ich den delay komplett weg.

Gruß
Alexander
Zum Vergrößern anklicken....
Guten Morgen,
also mir ist gestern Abend beim Mähen, als der Rover den Mähmotor gestoppt und wieder gestartet hat wegen zu hohem Gras, eine Seite wieder ausgefallen.
delay hatte ich komplett aus dem Code genommen. Werde ihn wieder mit rein nehmen und auf 200ms setzen.
 
Algo schrieb:
Guten Morgen,
also mir ist gestern Abend beim Mähen, als der Rover den Mähmotor gestoppt und wieder gestartet hat wegen zu hohem Gras, eine Seite wieder ausgefallen.
delay hatte ich komplett aus dem Code genommen. Werde ihn wieder mit rein nehmen und auf 200ms setzen.
Zum Vergrößern anklicken....
Jap, kann ich bestätigen, hatte ich heute auch. Gehe auf 100ms hoch
 
Die 100ms gehen auch, hatte gestern 2 erfolgreiche Recovery Vorgänge. Ich denke dabei belasse ich es erstmal und gehe andere Baustellen an. :)
 
Erster Versuch ohne Erfolg... Mäher ist nach 4h liegen geblieben und hat sich im Kreis gedreht.
Linkes Rad war ausgefallen, die App hat aber keinen Fehler erkannt und auch Serial Monitor hat nichts angezeigt.
Der Mäher hat sich nur andauernd in Halbkreisen gedreht weil er die Bahn weiter fahren wollte aber entsprechend natürlich nicht vorwärts kam.

Blöde Verständnisfrage... wie wird denn überhaupt die Motor Error Funktion ausgeführt wenn ich die Enable Fault Detection deaktiviere?
Die RPM Errors die ich von dem A4931 Treiber kenne kamen nicht.
//#define ENABLE_FAULT_DETECTION true
#define ENABLE_FAULT_DETECTION false

#define ENABLE_RPM_FAULT_DETECTION true
//#define ENABLE_RPM_FAULT_DETECTION false
Zum Vergrößern anklicken....

Hab dann mal das Delay auf 200ms erhöht und mal die Enable Fault Detection aktiviert.
Dann bleibt er aber alle 2m stehen und macht ein wildes Stop und Go, im Serial Monitor dann auch am laufenden Band die Motor Restore Funktion mit Delay am aufploppen.

Die also wieder deaktiviert und 200ms drin gelassen.
Danach weitergefahren und mal 2 lange Bahnen mit dem Laptop und Serial Monitor hinterher gelaufen.
Kein Thema, also Stop in der App gedrückt, USB Kabel abgesteckt, in der App wieder Start gedrückt... und linkes Rad wieder tot... Roboter dreht im Kreis.

Laptop wieder dran, Serial Monitor auf und wieder gar nichts zu sehen.

Hab ich irgendwo in der Config.h noch eine Failure Detection übersehen die ich aktivieren muss damit er erkennt das ein Rad steht und den Recovery startet?
Oder linke Treiber eventuell einen Schlag?
 

Anhänge

  • config.h.txt
    33,2 KB · Aufrufe: 14
  • AmRobotDriver.cpp.txt
    27,3 KB · Aufrufe: 13
Zuletzt bearbeitet:
Ah ich sehe gerade, es ist bei dir nicht aktiv, dann funktioniert recovery nicht. Aktivier mal die Odometriefehler, dann sollte es klappen
 
Werde ich ausprobieren, danke! :)
Die hatte ich glaube deaktiviert weil die bei den JYQD 2017 Treibern ohne Bremse recht häufig angesprungen ist wenn er aus der Bahn gerutscht ist am Hang.
 
Der Treiberausstieg läßt sich verhindern,
1. Ist der PWM an 0 bis 5Volt Pin, dann 100k zwischen Brake und GND.
2. Brücke einlöten und externen PWM Pin nehmen. Dieser Pin ist anders geschaltet und die Motoren laufen exelenc langsam oder schnell. GGF. noch einen 1K Wiederstand parallel auf 5V schalten.
Der ODO Pin liefert ein sauberes Rechtecksignal, was über einen Pegeleandler 5 zu 3.3 Volt direkt an den Odopin am Prozessor angeschlossen werden kann. Der ggf. auftretende Odoteilerfehler wird umgangen. Der Odoteiler ist ehe nicht nötig teilt nur die Takte durch 2 oder mehr je nach Brücke.
 
Hallo Hartmut,

konntest du den Treiberausstieg provozieren? Mich würde interessieren unter welchen Umständen steigt der Treiber aus.

Gruß
Alexander
 
Hab in der Zwischenzeit glaube noch 5x oder mehr die jeweils 6h gemäht, seit deiner Skriptanpassung mit dem Delay kein einziges Problem mehr gehabt! :)
 
Wie zuvor beschrieben steigen die Treiber mit der Handsteuerung unmittelbar nach sehr kurzer Zeit aus. GND an Brake und der Treiber läuft wieder bis zum nächsten Ausstieg. Die 100k an Brake und GND verhindern das.
Bei der 2. Variante PWM an externen PWM Eingang mit Brücke geschlossen treten keine Fehler auf. Auch läuft der Motor nun schneller und absolut stabil auch mit der Handsteuerung.
 
Was meint Ihr mit der Handsteuerung? Über die RC Buchse oder Sunray App? Das erste habe ich nicht, über Sunray App konnte ich den Treiber nicht in Fehlerzustand bringen.
Hab in der Zwischenzeit glaube noch 5x oder mehr die jeweils 6h gemäht, seit deiner Skriptanpassung mit dem Delay kein einziges Problem mehr gehabt!
Zum Vergrößern anklicken....
Dito, keine Ausfälle mehr. Funktioniert gut.

Seit dieser Woche ist der Mäher eingemottet, das Umpining von Hartmut werde ich wohl nächstes Jahr testen können.

@Hartmut ändert sich was an den Reglerparametern durch das bessere Ansprechverhalten der Treiber über das PWM PIN?
 
Hartmut schrieb:
Der Treiberausstieg läßt sich verhindern,
1. Ist der PWM an 0 bis 5Volt Pin, dann 100k zwischen Brake und GND.
2. Brücke einlöten und externen PWM Pin nehmen. Dieser Pin ist anders geschaltet und die Motoren laufen exelenc langsam oder schnell. GGF. noch einen 1K Wiederstand parallel auf 5V schalten.
Der ODO Pin liefert ein sauberes Rechtecksignal, was über einen Pegeleandler 5 zu 3.3 Volt direkt an den Odopin am Prozessor angeschlossen werden kann. Der ggf. auftretende Odoteilerfehler wird umgangen. Der Odoteiler ist ehe nicht nötig teilt nur die Takte durch 2 oder mehr je nach Brücke.
Zum Vergrößern anklicken....
Das ist ja interessant Hartmut!
Ich hatte auch schon mal die PWM Eingänge der Treiber verwendet allerdings subjektiv keinen Unterschied zu dem 0-5V Eingang feststellen können...verwendest Du den Brushlessadapter und die originalen BLDC Motoren, weil Du schreibst die drehen nun schneller?
Achso und welche PWM-Frequenz nutzt Du? Du hattest bei den "alten" JYQD doch andere Werte mal verwendet...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben