Fehler im Quelltext des Roboters

Ein neuer Artikel wurde veröffentlicht
  • Beim abbrechen des Programms kommt folgende Meldung


  • 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.

  • 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

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - ser. Devices - kein Support per PM / Konversation

    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,


    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

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - ser. Devices - kein Support per PM / Konversation

    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.

  • 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.

  • Hallo Bastelstube,


    Code
    1. 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

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - ser. Devices - kein Support per PM / Konversation

    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
    1. from gpiozero import DistanceSensor
    2. from time import sleep
    3. sensor = DistanceSensor(echo=18, trigger=17)
    4. print("Starte Schleife")
    5. while True:
    6. print('Distance: ', sensor.distance * 100)
    7. 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/Sa…b/master/pigpio_HCSR04.py

    https://github.com/meigrafd/Sa…master/pigpio_HCSR04_2.py

    https://github.com/meigrafd/Sa…igpio_HCSR04_interrupt.py

    https://github.com/meigrafd/Sa…pio_HCSR04_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 am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr


  • 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