-         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Seltsames Phänomen mit Gabellichtschranken

  1. #1
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    53
    Beiträge
    1.960

    Seltsames Phänomen mit Gabellichtschranken

    Anzeige

    Hallöle.
    Ich hab hier zwei Motoren (die berühmtem gelben TT-Motoren).
    Motortreiber ist ein MX1508.

    Unter den Motoren hockt jeweils eine Gabellichtschranke (fertige Module), und die werden von selber gedruckten Encoderscheiben auf der Abtriebswelle unterbrochen.
    Die Scheiben haben 20 Öffnungen, das müsste also pro Radumdrehung 40 Ticks geben.
    Ausgelesen wird per Interrupts:

    Code:
    attachInterrupt(digitalPinToInterrupt(odoLinksPin), odometerLinks, CHANGE);   // Gabellichtschranken an Interrupts
    Die ISR haben ne kleine Entprellung (20ms) drin:

    Code:
    void odometerLinks() // ******************** ISR linkes Odometer ****************************************
    {
      if((millis() - alteZeitL) > entprellZeit) { 
        odoTickLinks ++;
        alteZeitL = millis(); // letzte Schaltzeit merken      
      }
    Das Testprogramm, was da läuft, sieht so aus:

    Code:
    void motorTest()
    {
      analogWrite(motorR1,255); // einmal Vollgas bitte
      analogWrite(motorR2,0);
      analogWrite(motorL1,255);
      analogWrite(motorL2,0);
      delay(3000);
      analogWrite(motorR1,0);   //alles stop
      analogWrite(motorR2,0);
      analogWrite(motorL1,0);
      analogWrite(motorL2,0);
      
      
      Serial.print("Links= ");    // was haben wir denn da....
      Serial.print(odoTickLinks);
      Serial.print("     ");
      Serial.print("Rechts= ");
      Serial.println(odoTickRechts);
      odoTickLinks=0;             // Odos auf Null setzen
      odoTickRechts=0;
      
       Serial.println("Odometer zuerueckgesetzt!");
       Serial.println();
    Also nix besonderes: Motoren starten, 3 Sekunden laufen lassen, stoppen, die Odoticks ausgeben, zurücksetzen und das Ganze von vorne.
    Das läuft auch, nur sieht die Ausgabe so aus:

    Klicke auf die Grafik für eine größere Ansicht

Name:	freddietest.jpg
Hits:	24
Größe:	47,7 KB
ID:	35407

    Das Ganze ist reproduzierbar- immer die ersten vier Male tauchen wesentlich weniger Odoticks auf als dann später.
    Ausser den Odoticks, die in jeder Pause zurückgesetzt werden, wird _nichts_ im Programmablauf während der Zeit geändert.
    Die Ausgabe der Odoticks nach dem zurücksetzen hab ich als Kontrolle eingebaut, weil ich dachte, das zurücksetzen klappt nicht- aber das tut es ja, wie man sieht.

    Jemand eine Idee?
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.561
    Blog-Einträge
    29
    Sieht so aus, als ob die eine kleine Zeit brauchen, bis die schneller drehen (Masse in Schwung bringen z.B.). Von Mal zu Mal werden die angezeigten Zählerstände größer: 126, 138, 139, 1017 dann scheint es zu nach unten und oben zu pendeln.


  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.416
    N guten Morgen Sly,
    und alles Gute im Neuen Jahr.

    .. Ich hab hier zwei Motoren (die berühmtem gelben TT-Motoren) ..
    Code:
    ..   analogWrite(motorR1,255); // einmal Vollgas bitte ..
    Also nix besonderes .. immer die ersten vier Male tauchen wesentlich weniger Odoticks auf als dann später ..
    Das passt nach meinen Erfahrungen zu der Testaufgabe.

    Ich hatte mit meiner ersten fahrenden Coladose beim Ausarbeiten der Regelung zum Bestimmen der Regelungsparameter umfangreiche Tests mit Sprungantworten (Drehzahländerung über die Zeit nach Bestromen der noch NICHT geregelten Motoren) durchgeführt. Dabei wurden immer die Ticks der Gabellichtschranken beider Fahrmotoren des Zweiräders mit Zeitwerten erfasst, gespeichert und nach Testende als Liste ausgegeben - genau wie Du das tust. Also keine Datenausgabe während der kurzen Hochfahrphase! Damit ist die Datenerfassung in einem sehr feinen Zeitraster möglich. Gesamter Zeitbedarf meist im zwei- bis dreistelligen Millisekundenbereich. Zeitbasis ein Timer mit 50µs-Interrupts ("tupsi" = TimerUnitsPerSensorInterrupt)

    Die ersten Ergebnisse noch etwas diffus. Später wurden zeitliche Unterschiede im Anfahrverhalten deutlicher. Mit einiger Erfahrung und einer besser - "gleichzeitigeren" - Ansteuerung der Motoren konnten die Daten sauberer erfasst bzw. dargestellt werden. Das Ziel waren möglichst genaue Werte zu Motorzeitkonstanten und Totzeiten (nicht nur vom Antriebsstrang sondern meist von Antrieb mit dem gesamten Gefährt!). Damit konnte ich nach dem ziemlich guten Regelungsbeitrag im RN-Wissen von waste et alii für meine DC-angetriebenen (nicht Schrittmotoren) Gefährtchen wirklich gut passende Regelparameter errechnen - das ist aber dann ein anderer Abschnitt - wäre hier OT (geht etwa so weiter - siehe Regelschema und Diagramm . . .), hatte sich aber in den folgenden Projekten sehr bezahlt gemacht.

    Wünsch Dir guten Fortgang!

    Nachtrag: ein mögliches Drehzahl-Regelschema aus dem Forumswissen "Regelungstechnik"
    Geändert von oberallgeier (02.01.2021 um 11:21 Uhr)
    Ciao sagt der JoeamBerg

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    1.009
    In 3 Sekunden Zählzeit passen bei 20ms Entprellzeit maximal 150 +/-2 Inkrementierungen; mehr können das eigentlich nicht werden.

    Eine Entprellung von 20 ms kommt mir unnötig lang vor, sollte das Ergebnis aber nur nach _unten_ verfälschen können.

    Hast du nach der "Methode des genauen Hinsehens" mal abgeschätzt, wieviele Signalflanken in 3 Sekunden etwa auftreten können?

    Willst du wirklich die Beschleunigungsphase mitzählen lassen, die Bremsphase aber abschneiden? Es könnten z.B. die Motoren gestartet werden, dann 1000ms Wartezeit zur Stabilisierung, dann Zähler nullen und Zeitmerker mit millis() initialisieren, dann 3000ms Meszeit. danach sofort Zählerstände kopieren, Motoren abschalten und die serielle Ausgabe abwickeln. (ggf. noch ein delay vor erneutem Messzyklus).

    @Moppi, @oberallgeier: Sprungantworten und Trägheitsmomente scheinen hier nicht im Fokus zu stehen.
    Geändert von RoboHolIC (02.01.2021 um 13:04 Uhr) Grund: edit: Initialisierung vor Beginn der eigentlichen Messung

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    53
    Beiträge
    1.960
    Hm, Missverständnis: die Motoren drehen 3s Vollgas, dann werden sie gestoppt. Dort erfolgt die Ausgabe und anschliessend das Zurücksetzen der Zähler.
    Dann wird der Zyklus wiederholt.
    Die starten jedesmal aus dem Stand raus.

    Getestet hab ich aufgebockt (naja, ich hatte Freddie II in der Hand..da konnten die Räder frei drehen), als ohne Last- die Motoren mussten nur die Encoderscheibchen und die Räder drehn.
    Dass das aussieht, als würde da erst was hochlaufen, ist mir auch aufgefallen- kann aber nicht sein.
    Ich hab sogar die Gegenprobe gemacht (um, auch wenns eh hirnrissig wäre, auch noch Sachen wie kalte Lager ausschliessen zu können): den Zyklus sechs-achtmal durchlaufen, das Programm gestoppt, und wieder neu gestartet- auch_dann_ ergeben die ersten vier Zyklen viel niedrigere Werte als die späteren.

    Und, richtig vermutet, Jo: das Ganze war dazu gedacht, um rauszufinden, wieviele Ticks pro Zeiteinheit ich habe- die will ich nämlich als Basis für eine Regelung benutzen.
    Grob sieht der Plan so aus, dass die PID-Regler einfach eine Sollgeschwindigkeit /Ticks/Zeiteinheit) vorgesetzt kriegen.
    Theoretisch sollte, wenn die Regler gut eingestellt sind, die Fuhre dann schnurgerade fahren.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.561
    Blog-Einträge
    29
    Dann probiere doch mal folgendes und mache am Schleifenanfang auch das delay(3000) rein. So dass wirklich alles richtig zur Ruhe kommen kann, bevor es neu startet. Schau Dir die Werte dann noch mal an.

    MfG

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    53
    Beiträge
    1.960
    Hab ich eben auch versucht.
    Das Resultat bleibt das gleiche- mehr oder weniger (mal passiert es beim dritten Durchlauf, mal beim vierten).
    Aber offenbar haut was mit dem entprellen nicht hin.
    Im Anhang hab ich das Entprellen mal auf einer Seite komplett rausgenommen, das sieht dann schon besser *) aus.
    Klicke auf die Grafik für eine größere Ansicht

Name:	FreddieTest2.jpg
Hits:	5
Größe:	48,1 KB
ID:	35408

    *) Allerdings bin ich skeptisch bei dem Wert: so weit ich es mit den Augen mitzählen konnte, gibts aktuell etwa 15 Umdrehungen in 3s.
    Da die Odoscheiben nur 20 Fensterchen haben, und ich die Interrupts auf CHANGE stehen hab, dürften da nur ungefähr 600 Ticks rauskommen.
    Das probiere ich gleich noch mal mit niedrigerer PWM, so dass ich mitzählen kann.
    Aber vorher muss ich mal den Akku laden- Freddie ist ein ziemlicher Stromfresser...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.657
    Blog-Einträge
    133
    Vielleicht wird der Motortreiber warm und gibt dann mehr Strom ab

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.561
    Blog-Einträge
    29
    Deine Encoderscheibe hat 20 Löcher. Erzeugt 40 Impulse pro Umdrehung, bei "change". Bei 4 Umdrehungen pro Sekunde bekommst Du 4 mal 40 Impulse, also 160 pro Sekunde. 1 durch 160 sind 0,00625. Also 6.25ms pro Impuls. bzw. 6250 µs. Wenn Impulse eintreffen und Du zählst nur einen Impuls alle 6ms, kann ein Rad nicht schneller drehen, als 4 Umdrehungen pro Sekunde. Bei 20ms Wartezeit kämst Du auf etwa 1 Umdrehung pro Sekunde. Wenn es langsamer dreht, sollten also alle Impulse gezählt werden. Etwa 15 Umdrehungen in 3s sind 5 Umdrehungen pro Sekunde. "entprellZeit" müsstest Du auf th. 5ms herunter setzen. Besser weniger, wenn Du denkst, dass es noch schneller drehen könnte.

    MfG

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    53
    Beiträge
    1.960
    Das Problem scheint vom Tisch gefallen zu sein.
    Mich hatte ja die ganze Zeit gewundert, wieso ich einen CHANGE-Interrupt überhaupt entprellen soll....
    Nach meiner Logik ist das völlig unnötig- und es stimmt auch.

    Auf die Spur des Übels (viel zu viele Ticks für die paar Umdrehungen) hat mich dann das hier geführt.
    ich benutze zwar nicht genau diese Lichtschrankenmodule, aber bekanntlich gucken die Chinesen ja gerne voneinander ab, und die Bauteile auf dem Ding sehen meinen zu ähnlich, um es nicht einfach mal auszuprobieren...
    Also hab ich kurzerhand mal nen Kondensator mit 100nF an den Stecker, zwischen Signal und Masse, gelötet.
    Und schon funktionierts- entprellen erübrigt sich nun.

    Bei ungefähr zehn Radumdrehungen hab ich rund 400 Impulse, das passt.
    Auch bei höherer oder niedrigerer Geschwindigkeit sind die Impulszahlen stimmig.
    Ich werd noch einige Tests veranstalten (mal ein Rad ne halbe Umdrehung drehen lassen, sowas), aber ich glaube, ich habs.

    Falls wer ähnliche Probleme mit diesen Dingern hatte (Moppi-sagtest du nich neulich auch sowas..?)-einfach mal ausprobieren.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Quadraturencoder mit Gabellichtschranken und Zahnrad
    Von mausi_mick im Forum Sensoren / Sensorik
    Antworten: 35
    Letzter Beitrag: 21.02.2019, 04:12
  2. seltsames Phänomen bei CD4017BE
    Von Jul-ian im Forum Elektronik
    Antworten: 5
    Letzter Beitrag: 10.03.2006, 01:22
  3. Seltsames Phänomen der UART
    Von rapo im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 10.01.2006, 19:37
  4. Gabellichtschranken als Digitaler Schalter für C-Control
    Von ze_sniper2 im Forum Sensoren / Sensorik
    Antworten: 0
    Letzter Beitrag: 19.10.2004, 08:28
  5. C-control zwei gabellichtschranken?
    Von kyburz1 im Forum Controller- und Roboterboards von Conrad.de
    Antworten: 6
    Letzter Beitrag: 04.08.2004, 18:12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •