Mit Latein am Ende - Hall Sensoren an GPIOs interferieren!

  • Hallo,

    ich habe zwei DC brushed Motoren [Anzeige] mit Encoder (2 Hall Sensoren) an meinen Raspberry Pi angeschlossen.

    Der Encoder benötigt Vin, GND und hat zwei Signalausgänge, von jeweils zwei Hall Sensoren (mit zwei ließe sich auch die Drehrichtung bestimmen).

    Etwas genauere Angaben zu den Sensoren gibt es hier.

    Ich verwende nur jeweils ein Hall Sensor pro Motor um die Umdrehungen über die GPIOs am Raspberry Pi zu erfassen. (Die Drehrichtung kenne ich ja, da auch von RPI über Treiber definiert)

    Die Vin der Encoder hängen am 3,3V des RPi, ebenso die GNDs. Jeweils von einem Motor/Encoder hängt ein Signalausgang an einem GPIO Port (also zwei insgesamt)

    Für mich nicht verständlich, interferieren die Signale irgendwie. An den GPIOs zähle ich die Signalimpulse mit meinem Script mit (GPIO interrupts). Seltsamerweise detektiert es öfters an beiden GPIO Ports Signalimpulse, auch wenn sich nur ein Motor dreht. Wie kann das sein? Das Setup ist ja eigentlich ziemlich simple. Jeweils ein Hall Sensor von einem Motor an einen GPIO Port ...

    Es scheint definitiv die Hardware-Installation zu sein, nicht die Software.

    Bin dankbar für sämtliche Ideen, da ich momentan mit meinem Latein am Ende bin.

  • Mit Latein am Ende - Hall Sensoren an GPIOs interferieren!? Schau mal ob du hier fündig wirst!

  • Servus haemse,

    ich denke mal, da spucken Dir die Latenzzeiten des OS in die Suppe ...

    mit meinem Script mit (GPIO interrupts)

    mal abgesehen davon, dass es imho keine gute Idee ist, mit einer script-Sprache mehr oder weniger hochfrequente Impulse zu zählen, kennt der Raspi im Userspace keine Interrupts, auch wenn die Events oft fälschlicherweise als solche bezeichnet werden.

    Durch das Multitasking enststehen zwangsläufig Latenzen, die durch das (für Dich nicht sichtbare) Mappen IRQ -> Event noch verstärkt werden. Das kann schon mal 1 bis 2 ms ausmachen ... bei Interpretersprachen evtl. noch mehr.

    Jetzt hast Du zudem zwei Eventhandler auf verschiedenen GPIOs ...

    Ich würde zum Zählen einen µC (Arduino) einsetzen (der durch das nicht vorhandene OS praktisch keine Lazenzzeiten und zudem "echtes" Interrupt-Handling hat) und den dann entspannt via SPI/I2C/UART abfragen.

    cu,

    -ds-

  • Ja, dein punkt ist definitiv valide. Dennoch, es funktioniert mit einem Motor blendend und das ist auch keine Erklärung, weshalb er an dem anderen GPIO Impulse mitzählt obwohl sich der Motor nicht bewegt. Für das brauch ich eine Lösung.

    Wenn ich einen Sensor abstecke wird dort auch nicht mitgezählt.

  • Wo steckst du den Sensor ab? Klemmst du das Kabel direkt am Pi-GPIO ab? Dann häng mal ein langes Kabel an den Pi - ohne Sensor. Vielleicht sind es Störsignale von den Motoren. Du schreibs "brushed" - also Bürstenmotoren... die produzieren doch ständig Störfunk...

    Veränder mal die Position der Motoren oder schirme sie mit nem Blech gegeneinander ab, um zu sehen, ob das Verhalten sich ändert.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Moin haemse,

    hier mal ein Auszug von der dfrobot-Seite

    Zitat

    Specification

    • EncoderOperating Voltage: 5 V

    Das machst du ja auch. Ich denke das aus dem encoderausgang auch 5Volt kommen.

    Aber die Pins der GPIO dürfen nur 3,3Volt!!!

    Hast du pull-up/down angeschlossen? Oder bist du dir sicher, das der Encoderausgong auf einem bestimmten Pegel gehalten wird. Ein paar Fragen fallen mir bestimmt noch ein...

    Aber eigentlich ist das alles egal, weil der dreamshader schon alles geschrieben hat.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Node.js mit npm package pigpio, im wesentlichen (zusammengesetzt aus größerem Prj):

  • interessant ist auch, dass bei bestimmten Stellungen des Magnetrades von Motor 2, an dem die Hall Sensoren angebracht sind, die Durchgangsprüfung zwischen Sensor Kabel von Moto 1 und Motor 2 postitv ist - das Multimeter gibt den Pipston von sich.

    Wo steckst du den Sensor ab? Klemmst du das Kabel direkt am Pi-GPIO ab? Dann häng mal ein langes Kabel an den Pi - ohne Sensor. Vielleicht sind es Störsignale von den Motoren. Du schreibs "brushed" - also Bürstenmotoren... die produzieren doch ständig Störfunk...

    Veränder mal die Position der Motoren oder schirme sie mit nem Blech gegeneinander ab, um zu sehen, ob das Verhalten sich ändert.

    ja, direkt am RPi

    nein, Encoder stecken an 3,3V - geht auch mit einem Motor ganz gut.

    Die Impulse spielen sich im Millisekundenbereich ab, das sollte auch das Node Script hinbekommen - tut es auch ;)

    • Offizieller Beitrag

    die Durchgangsprüfung zwischen Sensor Kabel von Moto 1 und Motor 2 postitv ist

    Wie misst Du das? Zwischen GPIO 17 und 27?

    haemse Bitte keine zwei oder mehr Beiträge nacheinander posten! Du kannst Beiträge auch bearbeiten. Das ist sinnvoll, solange noch kein anderer User darauf geantwortet hat.

  • Die Impulse spielen sich im Millisekundenbereich ab, das sollte auch das Node Script hinbekommen - tut es auch

    Unter Linux ... na klar, und das absolut verlässlich :rofl:

    Ne, sorry, aber so einen Unsinn kann ich einfach nicht unkommentiert stehen lassen. Das könnte noch jemand glauben und sich dann auch noch auf der Forum berufen :fies: ...

    ciao und viel Erfolg noch,

    -ds-

  • Unter Linux ... na klar, und das absolut verlässlich :rofl:

    Ne, sorry, aber so einen Unsinn kann ich einfach nicht unkommentiert stehen lassen. Das könnte noch jemand glauben und sich dann auch noch auf der Forum berufen :fies: ...

    ciao und viel Erfolg noch,

    -ds-

    Das ist nicht das um was es bei meinem Problem geht, daher möchte ich darüber nicht streiten. Du hast dich ja leider eh schon von der Diskussion verabschiedet. Es geht mir nicht um das genaue timing der interrupts, dass aber über tausend pro s ankommen hab ich halt direkt vor mir auf dem Screen, wenn ich den Motor übersteure ... aber wie gesag, das ist nicht das Thema.

  • Hallo,

    haemse : der Punkt von dreamshader ist - > die Hard- / Software des Pi ist da am Limit, im "normalen" Betrieb. Davon ausgehend, dass du Raspbian benutzt: es läuft ein normales Linux Betriebssystem, wo sich etliche Prozesse die Rechenzeit teilen. Wann welcher Prozess Rechenzeit bekommt bestimmt alleine der Linux Kernel. Und im Millisekunden Bereich bist du halt an dem Punkt, wo es sein kann, dass dein Skript nicht genug Rechenzeit bekommt, um so schnell / genau zu messen.

    Dabei spielt es in dem Bereich auf dem Pi IMHO auch nicht mehr so die große Rolle, ob du Python mit seinem Bytecode Interpreter, node.js mit der V8 JavaScript Engine oder kompiliertes C hast.

    In den Bild, was du gepostet hast, steht ja "up to" - nur schweigt sich das Datenblatt über die Randbedingungen aus, wenn der Wert aus. Das wird ja gerne so gemacht. Klar kann es sein, dass der Wert "irgendwie" erreichbar ist, aber halt nicht unter der normalen "real world" Bedingungen.

    Wenn es zuverlässig schnell sein muss, fährst du mit einem Mikrocontroller IMHO in der Tat besser, wurde ja auch schon vorgeschlagen. Wenn du beo node.js bleiben willst -> es gibt auch eine node.js Implementierung für Mikrocontroller, habe ich eben im Internet gesehen.

    Gruß, noisefloor

  • Ich verstehe das und natürlich ist ein Microcontroller da besser geeignet. Nur bei mir kommt es nicht auf so eine krasse Genauigkeit an. 1. läuft der Motor ohnehin zwischen 20-80 Schritten nach dem Stoppen weiter durch das vorhandene Drehmoment und zweitens ist 1 Mio events/s noch mit viel Luft bestückt, auch wenn es „up-to“ ist. Ebenso beziehen sich die Angaben auf das npm Package.

    Ja, wenn es mir im microsekunden geht und exaktes timing, wäre dieses Setup nicht meine Wahl. Bei mir geht es nur darum, dass der Motor mit gearbox einen Schlüssel dreht und ungefähr an einer Position halten muss.

    Hat aber alles - für mich zumindest nicht nachvollziehbar - mit meinem Problem zu tun.

  • Also: Habe nun die Kabel für die Hall Sensoren zum GPIO zum debuggen komplett gewechselt. Zuvor waren es Litzen eines 5m langen, eingebauten Netzwerkkabel. Nun hab ich 1m lange Kupferdrähte genommen.

    Genau das selbe Spiel.

    Neue Erkenntnis ist aber, dass es von der Lage des anderen Motors, bzw. dessen Magnetrades welches die Hall Sensoren triggert - abzuhängen scheint, ob dieser auch mitzählt, obwohl er still steht. Manchmal zählt der inaktive Motor mit, manchmal nicht ... und das in beiden Fällen.

    Würdet ihr sagen, dass die Verkabelung laut Schema eigentlich passt? Oder sind hier Interferenzen zu erwarten?

    Einmal editiert, zuletzt von haemse (22. Dezember 2018 um 16:49)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!