Fehler im Quelltext des Roboters

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Beim abbrechen des Programms kommt folgende Meldung

  • Hallo Bastelstube,

    zur verzögerten Ausgabe (Beitrag #31 ?) hätte ich diesen Link. Vielleicht passt das?

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Selbstverständlich kommt die. Du hast dein Programm ja mit Ctrl+C, also einem SIGINT unterbrochen und damit in Python eine KeyboardInterrupt Exception ausgelöst. Der von gpiozero gestartete Thread im Hintergrund stört sich entsprechend daran, gewaltvoll abgebrochen zu werden. Zu Schaden kommt letztenendes aber keiner.

    Achso okay danke für die Info.


    Hast Du denn sonst eine Lösung für mein Problem, da ich die ganze zeit wie verrückt nach einer Lösung suche.

  • Hallo Bastelstube,


    zur verzögerten Ausgabe (Beitrag #31 ?) hätte ich diesen Link. Vielleicht passt das?


    Beste Grüße


    Andreas

    Leider gibt es in diesem Beispiel keinen Code an dem man den Fehler ableiten kann, dadurch fällt es mir gerade schwer zu verstehen was dort gemeint ist bzw. wie ich diese Funktionen in das Bsp. Scipt einfüge.

  • Hallo Bastelstube,

    folgender Code aus Beitrag #31 dieses Threads erzeugt nach Deiner Aussage erst nach 30 Sekunden eine Ausgabe...

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • zur verzögerten Ausgabe (Beitrag #31 ?) hätte ich diesen Link. Vielleicht passt das?

    Kann ich mir nur schwer vorstellen... print tut nämlich implizit ein \n anhängen (Keyword-Argument end="\n") und flusht den Buffer auch direkt, im Gegensatz zu sys.stdout.write, wo unter Umständen ein Aufruf sys.stdout.flush nötig wäre.

  • Hallo Bastelstube,

    folgender Code aus Beitrag #31 dieses Threads erzeugt nach Deiner Aussage erst nach 30 Sekunden eine Ausgabe...

    Beste Grüße

    Andreas

    Achso ja sorry.

    Es müsste aber doch die gleiche Ausgabe erfolgen wie mit der GPIO library bei gleicher Verkabelung. Sprich der Sensor misst in meinem Fall vom Tisch bis Decke ca. 160cm. Da frage ich mich warum wird dies nicht auch mit der GPIOzero library ausgegeben. Ich bekomme ja immer den selben Wert (100.0) zurück.

    Gruß

    Bastelstube

  • Ich glaube wir brauchen langsam einen Schaltplan als Bild. In Prosa kam da viel zu oft nur Murks raus, frag mal den jar. An der Software liegt's bestimmt nicht, das Beispiel ist ja minimal und von den Entwicklern getestet worden.

    Was ist Prosa?

    Dann muss ich mir mal ein Tool suchen um einen Schaltplan erstellen zu können. Speziell jetzt für raspberry.

  • Hallo Bastelstube,

    Code
    sudo apt-get install fritzing

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Meine Vermutung ist dass das Initialisieren des Sensor's zu lange dauert. Ob es am Ausgabebuffer liegt lässt sich doch super einfach debuggen:

    Python
    from gpiozero import DistanceSensor
    from time import sleep
    
    sensor = DistanceSensor(echo=18, trigger=17)
    print("Starte Schleife")
    while True:
        print('Distance: ', sensor.distance * 100)
        sleep(1)

    Ich persönlich würde aber eher weiterhin beim RPi.GPIO oder pigpio Module bleiben - wenn es damit auch 30sec dauert bis eine Messung erfolgt liegt es eindeutig an der Hardware oder Aufbau/Abstand.

    https://github.com/meigrafd/Sampl…igpio_HCSR04.py

    https://github.com/meigrafd/Sampl…pio_HCSR04_2.py

    https://github.com/meigrafd/Sampl…04_interrupt.py

    https://github.com/meigrafd/Sampl…_interrupt_2.py

  • Okay. Habe gerade auch nochmal die Verkabbelung geprüft es scheint alles richtig zu sein.

    frag mal den jar

    bin schon hier

    Habe gerade auch nochmal die Verkabbelung geprüft es scheint alles richtig zu sein

    das glauben immer viele auch Profis.

    Aus meiner beruflichen Praxis:

    Zu jeder Schaltung wird stets ein Schaltplan erstellt, mit Eagle, es kann aber auch Fritzing oder Karopapier sein.

    Dann wird die Schaltung aufgebaut, Steckbrett, Lochraster Platine mit Schaltdraht, oder freiverdrahtet mit Litze, alles egal ABER:

    Nach jeder gelegten Verbindung wird diese gemessen zu den Knoten muss Durchgang nahe 0 Ohm haben und zu Nachbarn ohne Verbindung unendlich Ohm haben, dann erst DANN gilt sie als gelegt und wird mit einem Textmarker im Plan nachgezeichnet.

    Wenn alle Verbindungen gemarkert sind erst dann erfolgt der Test und wenn der fehlschlägt ein Blick genügt und man sieht den Fehler, "vergessene Leitung".

    Auch Kollegen mit 30 Jahren Berufserfahrung musste ich erst die "Abkürzungen" austreiben, 5 Leitungen legen und 6 abstreichen im Glauben das sie doch 6 gelegt hatten, der Fehler hat mich schon öfter unnötige Fehlersuche gekostet weil die Leitung ja "abgestrichen" war aber in Wirklichkeit fehlte.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • dazu gehört,

    "Wir haben keine Zeit es richtig zu machen, aber immer genug Zeit es doppelt zu machen."

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ich habe leider nie die Erfahrung mit Schaltplänen gemacht - werde aber mein bestes geben und einen Plan anfertigen.

    Ich persönlich würde aber eher weiterhin beim RPi.GPIO oder pigpio Module bleiben - wenn es damit auch 30sec dauert bis eine Messung erfolgt liegt es eindeutig an der Hardware oder Aufbau/Abstand.

    Beim RPi.GPIO dauert es noch nichtmal 1sec bis der Sensor den richtigen wert ausgibt, daher verstehe ich auch nicht warum es jetzt so Probleme gibt.

    Die RPi.GPIO ist aber veraltet oder etwads nicht? Wenn die GPIOzero vieles verinfacht durch die library warum sollte man dies dann nicht aktiv nutzen?

  • Nö wieso? Du bist ja nicht auf aktuelle Features angewiesen und solange du keine Probleme hast, who cares?

    pigpio ist aber auch ein aktuelles und weiterhin gepflegtes Module - wenn du darauf Wert legst.

    Erst mal geht es darum festzustellen ob es am Script oder der Hardware liegt. Also mach mal bitte das worum ich dich in Beitrag#54 gebeten habe.

    Wenn mit pigpio das Verhalten ähnlich ist liegts nicht am Script. Wenns mit RPi.GPIO besser funktioniert wieso nicht das nutzen?


    Dein Hauptproblem worum es hier ursprünglich ging bezog sich auf deinen Anfängerstatus mit Python, da du gerade erst damit anfängst.

  • Sorry das ich mich seit einer Woche nicht gemeldet habe, dies hatte gesundheitliche Gründe.

    Erst mal geht es darum festzustellen ob es am Script oder der Hardware liegt. Also mach mal bitte das worum ich dich in Beitrag#54 gebeten habe.

    Wenn mit pigpio das Verhalten ähnlich ist liegts nicht am Script. Wenns mit RPi.GPIO besser funktioniert wieso nicht das nutzen?

    Die Ausgabe sieht wie folgt aus:

    Er gibt dauerhaft den selben wert aus auch wenn ich einen Gegenstand vor den Sensor halte. Habe auch mal die Kabel vom Trigger und vom Echo getauscht, hierbei kam gar keine Ausgabe zustande. Somit habe ich die Verkabelung wieder zurück gebuat und schließe darauf das Sie richtig war.


    Im Vergleich mal das ganze mit RPi.GPIO.

    Ausgabe (Habe dort auch mal einen Gegenstand vorgehalten um zu schauen ob der Sensort es erkennt um einen Hardware defekt auszuschließen.)

    Scipt

    2 Mal editiert, zuletzt von Shaq (6. Dezember 2017 um 13:11)

  • warum soll ich es wiederholen?

    Fehler im Quelltext des Roboters

    mache einen Schaltplan prüfe die Ausführung und dann die SW

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo zusammen,

    mache einen Schaltplan prüfe die Ausführung und dann die SW

    hier nun einmal der Schaltplan von dem ganzen (siehe Anhang). Mit RPi.GPIO funktioniert dieses, jedoch nicht mit gpiozero.

    Hier noch eine kurze Erklärung zur Verkabelung:

    VCC = 5V [Pin2 (RPi)] = Braun

    Trigger = Pin B1 [Voltage Translator] = Rot

    Echo = Pin B2 [Voltage Translator] = Grün

    GND = Masse [Pin 6 (RPi)] = Gelb

    VCCb = 5V []Pin 04(RPi) = Weiß

    VCCa = 3,3V [Pin 01(RPi)] = Lila

    Pin A1 = GPIO20 [Pin 38(RPi)] = Gelb

    Pin A2 = GPIO21 [Pin 40(RPi)] = Orange

    GND = Masse [Pin 14(RPi)] = Schwarz

    LG

    Bastelstube

Jetzt mitmachen!

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