[Python] Unsinnige Werte vom HC-SR04

  • Hallo zusammen,

    dies ist mein erster Beitrag hier, und daher möchte ich mich und mein Projekt kurz vorstellen. Ich bin von Haus aus Luftfahrtingenieur und nutze den Raspberry Pi 3B V1.2 mit Python um einige Messwerte für meine Masterarbeit zu ermitteln. Ich habe grundlegende Kenntnisse im Programmieren, was man aus dem Studium und kleineren Progrämmchen nebenher halt kennt. Python ist da ja sehr dankbar und leicht verständlich. Mein Kerninteresse gilt also nicht der Elektrotechnik oder dem Rechner an sich, sondern ich interessiere mich für die kleinen Computer als kosteneffizientes Werkzeug vor allem zum Messen und Regeln von Daten und Geräten. Im Rahmen meiner Masterarbeit habe ich vor, die Wasserlasten auf ein kleines Flugboot zu bestimmen. Für die Validierung der Berechnung möchte ich einige Messungen machen, wofür sich der Pi (ggfs. unterstützt von ein paar Arduinos als I/O-Erweiterung) eigentlich ganz gut eignen sollte. Insbesondere, weil man ihn sehr gut im Flugzeug mitnehmen kann und einfach an allen möglichen Stellen unterbringen. Die Wasserlasten möchte ich durch DMS an der Struktur ermitteln, die ich über eine Viertelbrückenschaltung "auslesen" gedenke. Nun muß ich allerdings auch die Eindringtiefe ermitteln, was ich über den HC-SR04 versuchen wollte. Der Abstand zur Wasseroberfläche ließe mich sehr einfach die Eindringtiefe des Flugbootrumpfes berechnen.

    Dazu habe ich einem der unzähligen Tutorien folgend einen derartigen Sensor auf einem Breadboard verdrahtet und mit einem Spannungsteiler (1k zwischen Echo und Pin 21, und 2k zwischen Pin 21 und GND) angeschlossen. Das ganze hat auch soweit zufriedenstellend funktioniert, in einem Test im KFZ lieferte mir der unverkleidete Sensor noch bis 160 km/h akzeptable Werte - zwar etwas verrauscht, aber ich habe noch keinen Filter eingebaut.

    Da ich bei den höheren Geschwindigkeiten und auch variierenden Distanzen die Temperaturkorrektur als sinnig erachte, habe ich einen 18B20 angeschlossen, der auch tadellos funktioniert. Nach dem Test habe ich das Breadboard auf einer kleinen Lochrasterplatine nachgebaut. Der 18B20 funktioniert auch immernoch tadellos, der HC-SR04 macht allerdings unsinn, und zwar jenseits jeglichen Rauschens.

    Zum Vergleich: Der Log vom ersten Test mit Messwerten im Abstand von etwa einer Sekunde in cm angegeben, bei ca. 150 km/h:

    Nach dem Neuverdrahten und der Temperaturkorrektur bekomme ich allerdings so etwas aus einer statischen Messung:

    Die Einheit sind diesmal Meter, der Sensor "sieht" in einem Kegel von rund 90° Öffnungswinkel (also 45° zu jeder Seite) nur eine Wand in 28 cm Abstand.

    Hier der Code, den ich verwende:

    Hier ist mein Verdrahtungsplan:
    https://www.dropbox.com/s/yh8ecs7by9q3…001949.jpg?dl=0

    Und hier mein letzter Versuchsaufbau:
    https://www.dropbox.com/s/7qf4r2wonzvz…001958.jpg?dl=0

    Weitere Informationen:
    * Der Spannungsteiler ist bei beiden Messungen identisch, die Widerstände und Verbindungen habe ich alle bis zum Pi-Ende des Flachbandkabels gemessen, die stimmen mit dem Plan überein.
    * Es macht keinen Unterschied, ob der HC-SR04 vom GPIO oder von einem Labornetzgerät mit Strom versorgt wird.
    * Ich habe 5 Sensoren mit gleichem Ergebnis eingesteckt.
    * Mit kurzem oder langem (für die Messungen vorgesehenen) Kabel angeschlossen, der Fehler bleibt der gleiche.
    * Die Berechnung der Entfernung aus der Zeit stimmt, der Fehler ist auch bei direkter Ausgabe der Zeit identisch.
    * Ein kompletter Neuaufbau des Lochraster-Breakouts brachte keinen Unterschied
    * Eine Reduktion des Scripts auf die reine Messung des Ultraschallabstands, also ohne die 1Wire-Temperatur auszulesen, liefert das gleiche Bild der Messdaten.


    Da ich ja prinzipiell ein Signal bekomme, ist meine Überlegung, daß meine Hardware gerade nicht das Problem ist. Auch sind wohl die richtigen GPIO-Ports angesteuert, sonst hätte ich sicher garkeine Daten, und ich nehme an, daß nicht gleich 5 Sensoren einen gleichen Baufehler haben. Meine Überlegungen gingen gerade in die Richtung, daß mir mein Python-Skript (oder ggfs etwas anderes) mein Timing versaut, also so dazwischenfunkt, so daß zwar noch die Zeit vom Schalten des ECHO auf high, aber die Zeit beim Schalten des ECHO auf low nicht mehr korrekt genommen wird.

    Das ist jetzt etwas mehr Text geworden als ich dachte --- (aber wenn ich schon eine Frage stelle, muß ich mir ja nicht alle Informationen aus der Nase ziehen lassen :) ). Mir gehen langsam die Ideen aus. Wie gesagt, ich bin hier eher interessierter Laie und kann daher schnell etwas offensichtliches übersehen.

    Während ich schreibe kommt mir noch die Idee, daß ggfs der 1Wire selber recht langsam sein kann? Ich lese ja nur eine "Datei" aus, und triggere keine Messung an sich mit meinem Python-Skript, oder? Auch ist mir aufgefallen, daß der Prozessorlast-Monitor schon bei 70% steht, obwohl zu dem Zeitpunkt gerade kein Programm läuft.

    Also für Denkansätze oder Hinweise, wie ich mein Problem weiter angehen kann, wäre ich sehr dankbar.

    Beste Grüße,
    Malte

    Einmal editiert, zuletzt von mhoeltken (20. Juli 2017 um 03:02)

  • Willkommen im Forum.
    Ich habe Deinen Aufsatz gelesen. Du bist einer der Wenigen, die Willens und in der Lage sind, bereits im ersten Beitrag so viele Informationen zu liefern, dass man auch etwas dazu sagen kann. Das finde ich gut. Den Hinweis von fred0815 solltest Du beherzigen und die Bilder direkt hier im Forum hoch laden.

    Was ich merkwürdig finde, ist dass es mit der fliegenden Verdrahtung funktioniert hat, auf der Platine verlötet aber nicht mehr.
    Wenn Du nichts an der Software geändert hast, kann es eigentlich nur an Deinem Aufbau liegen. Software ist nicht mein Steckenpferd, daher sagt mir das Script nicht viel.

    Zum DS18B20 solltest Du aber wissen, dass er zum einen eine Pause von mindestens rund 800ms zwischen dem Erfassen und dem Auslesen des Messwertes benötigt. Sonst könnte es passieren, dass als Fehlerhinweis 85 Grad angezeigt werden. Liest man den DS18B20 in zu kurzen Intervallen aus, führt dies zu einer Eigenerwärmung des Sensors und damit zu verfälschten Werten. Von den hoch auflösenden Angaben lass Dich übrigens nicht täuschen. Der Sensor hat laut Datenblatt nur eine Genauigkeit von +-0,5'C. Wenn Du es so exakt wie möglich brauchst, könnte man aus verschiedenen Chargen einige Sensoren verwenden und aus dem Ergebnis einen Mittelwert bilden.

  • Hi zusammen,

    vielen Dank für die schnelle Antwort schonmal. Beim Stöbern im Forum heute bin ich auch auf die Argumentation hinter den Bildern gestolpert, das ergibt natürlich sinn. Ich habe mal den Versuch gewagt und mit Fritzing gekauft und die Verdrahtung nachgebaut (so ganz virtuos bin ich mit dem Programm noch nicht, aber ich hoffe man kann erkennen, was ich verlötet habe).

    Da die Pins nicht beschriftet sind: Beim HC-SR04 von oben nach unten: VCC, TRIG, ECHO, GND. Beim DS18B20 von links nach rechts VDD, DS, GND. R1 hat 1k, R2 hat 2k und R3 hat 4k7. Das GPIO des RPi ist ja bekannt mit 3V3 oben links und Pin 20 (GND) unten rechts.

    Ich hatte die Ansteuerung des DS18B20 bezüglich der Aufrufe aus dem RPi falsch verstanden, erneutes Lesen meiner Dokumentation zum Sensor zeigt daß es unsinn ist, den zu jeder Distanzmessung erneut zu bemühen. Ich werde das mal entzerren in meiner nächsten Iteration. Die Temperaturänderungsrate ist ohnehin nicht so hoch, als daß mir da nicht auch ein Update jede Minute reichen würde. (Ich werde noch suchen müssen, wie ich das in Python am geschicktesten umsetze... ) Zumal der Temperatureinfluß auf die Messung ja doch recht gut konditioniert ist.

    Was mich jetzt beim überlegen nochmal stutzig gemacht hat, ist die hohe Prozessorlast im Performancemonitor. Ich habe hier im Forum zwar schon gelesen, daß die Art auf die Eingabe zu warten sehr ressourcenunfreundlich ist, aber dachte bisher daß der RPi damit wenig Probleme haben sollte, zumindest für diesen Test. Wenn ich das script laufen lasse lese ich rechts oben 99% Prozessorauslastung. (Und einen Blitz, trotz Nutzung des mitgelieferten Netzteils... )

    Ich werde die Änderungen am Script heute oder morgen ausprobieren und Euch auf dem Laufenden halten. Bis hier auf jeden Fall schonmal Danke!

    Zur Vollständigkeit Die beiden Bilder von oben:

    Die handschriftliche Verdrahtung:

    Der freie statische Messbereich des Sensors:

    Beste Grüße,
    Malte

  • Hallo Zentris,

    Zitat von "Zentris" pid='291892' dateline='1500642561'


    Ist da eine (Glas) Scheibe vor dem Sensor ????

    das würde die verblüffend geringen Entfernungen erklären.

    Hallo Malte,

    herzlich Willkommen in unserem Forum!

    Ein sehr gelunger Debütantenauftritt - sieht man gern öfters.


    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.

    Einmal editiert, zuletzt von Andreas (21. Juli 2017 um 15:29)

  • Zitat von "Zentris" pid='291892' dateline='1500642561'


    Ist da eine (Glas) Scheibe vor dem Sensor ????


    Hi,

    ja das ist eine Glasscheibe, in 28 cm Abstand. Der Sensor liefert nur alles zwischen 20 cm und 3 m...

    Andreas: Danke!

    Beste Grüße,
    Malte

  • Hallo Malte,

    Zitat von "mhoeltken" pid='291903' dateline='1500657644'


    ja das ist eine Glasscheibe, in 28 cm Abstand. Der Sensor liefert nur alles zwischen 20 cm und 3 m...

    dann wundern mich die Ergebnisse jetzt nicht so sehr. Bei meinem Projekt "Tischsonar" habe ich die Erfahrung gemacht, dass Glas / Bildschirme die Ultraschallwellen nicht nur in die Richtung des US-Senders reflektieren (Einfallwinkel 90 °) oder gemäß Reflektionsgesetz (Ausfallwinkel = Einfallwinkel) reflektieren sondern auch ganz konfus in alle Richungen reflektieren.

    Was Du dann messen kannst, sind irgendwelche Wege zwischen US-Sender, Glasscheibe, Wand, ..., bis mal irgendwas beim US-Empfänger ankommt. Blöderweise muss das empfangene Echo noch nicht mal von dem Signal stammen, das Du gerade abgeschickt hast - es kann (eine entsprechende Raumgröße und Geometrie vorausgesetzt) auch das Echo eines früheren Signals sein. Dann kannst Du auch mal Ausreißer von extrem kurzen Entfernungen haben.


    Erschwerend kommt hinzu, dass der HC-SR04 alles im Winkel +/- 15 ° - also einen Kegel von 30 ° - einfängt. Damit wird er für so ziemlich alle denkbaren Wege des US-Schalls empfänglich. Das erste eintreffende Signal gewinnt - egal wie alt es ist.

    Meiner Meinung nach müsstest Du mit einem Timeout arbeiten, der in der Größenordnung der maximal erwarteten Abstände liegt. Kommt in der Zeit kein Signal an, ist's vorbei. Und zwischen zwei Messungen musst Du auch solange warten, dass keine "verirrte" Welle noch unterwegs sein kann, um Dein Ergebnis verfälschen zu können.


    Meine Versuche damals haben allerdings reproduzierbare Ergebnisse geliefert (s. Abbildung).

    Beste Grüße

    Andreas

    Bilder

    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.

    Einmal editiert, zuletzt von Andreas (21. Juli 2017 um 20:06)

  • Zitat von "mhoeltken" pid='291903' dateline='1500657644'


    ja das ist eine Glasscheibe, in 28 cm Abstand. Der Sensor liefert nur alles zwischen 20 cm und 3 m...

    Wie, um alles in der Welt, kommst du auf die Idee, dass die Glasscheibe für das Ultraschallsignal "transparent" wäre ??? :daumendreh2:

    Im optischen Spektrum ist Glas mehr oder weniger tansparent, im akustischen Spektrum ist das ein Reflektor, also ein Hindernis.

    Aufgrund der Nähe und der großen Fläche werden die auftreffenden US-Wellen überlagernd zurückgeworfen (weil der US-Schallkegel kein dünner Schall-"Strahl" sondern eher ein "Fächer" ist.

    Durch die Überlagerung der Schallwellen erhälst du am Empfänger mehr oder weniger zufällig ein Signal oder nix (Auslöschung der Schallwellen durch Überlagerung) - ähnlich dem Doppelspaltexperiment. Daher deine "chaotischen" Messwerte...

    Nimm doch mal die Scheibe weg :-):thumbs1:

  • Hallo Andreas,

    Zitat von "Andreas" pid='291905' dateline='1500658523'


    Hallo Malte,


    dann wundern mich die Ergebnisse jetzt nicht so sehr. Bei meinem Projekt "Tischsonar" habe ich die Erfahrung gemacht, dass Glas / Bildschirme die Ultraschallwellen nicht nur in die Richtung des US-Senders reflektieren (Einfallwinkel 90 °) oder gemäß Reflektionsgesetz (Ausfallwinkel = Einfallwinkel) reflektieren sondern auch ganz konfus in alle Richungen reflektieren.
    [...]

    Nun, die Entfernungsmessung zur Scheibe hat vorher mit der fliegenden Verdrahtung funktioniert. Und auch bei diffuser Reflexion wird der Reflexionsgrad in der senkrechten zur Wand ja nicht gleich Null werden, also sollte der Teil des senkrecht reflektierten Echos also als erstes wieder eintreffen und demnach ECHO auf Low ziehen. Es sei denn, die Intensität reicht tatsächlich nicht aus um den Eingang zu triggern, aber bei 28 cm Abstand halte ich das für zumindest unwahrscheinlich. Hinzu kommt, daß ich natürlich auch das Ziel des Sensors verändert habe - ob Zimmerdecke, Schreibtischplatte, Fußboden, Wand - das Ergebnis ist das gleiche.. In meiner späteren Anwendung habe ich eh nur die Wasseroberfläche in Reichweite des Sensors.

    Zitat


    Meiner Meinung nach müsstest Du mit einem Timeout arbeiten, der in der Größenordnung der maximal erwarteten Abstände liegt. Kommt in der Zeit kein Signal an, ist's vorbei. Und zwischen zwei Messungen musst Du auch solange warten, dass keine "verirrte" Welle noch unterwegs sein kann, um Dein Ergebnis verfälschen zu können.
    [...]

    Laut Dokumentation hat der HC-SR04 ja ein Timeout von 0,2 Sekunden eingebaut, danach zieht er in jedem Fall ECHO auf low. Daher habe ich ja auch die Abtastfrequenz nicht höher gezogen, obwohl ich eigentlich nach Nyquist-Shannon auf mindestens 200 Hz gehen müsste um das Springen des Flugbootes zu erkennen. Dein Einwurf mit dem Timeout eigentlich ganz gut, nur müsste sich dies an der tatsächlichen Entfernung anpassen. Das ist aber Schritt zwei, glaube ich, eine dynamische Abtastfrequenz einzubauen. Die 200 Hz würden mir dann physikalisch eine Entfernungmessung von etwa 80 cm erlauben, natürlich vorbehaltlich der Frage, ob Software und Hardware das mitmachen.
    Ich habe gerade im Datenblatt noch einmal nachgesehen, mehr als 50 Hz gibt der Sensor nicht her, ich werde mit der Auflösung leben müssen ... Sehr guter Einwand, Danke.

    Darf ich fragen - ich habe hier im Board Dein Projekt nicht gefunden - wie Du die Abfrage des Sensors implementiert hast? Ich habe die Befürchtung, daß die Abfrage über "while [] : pass" zu aufwändig ist, um meine anderen Messungen (Temperatur, Lage im Raum, Beschleunigung, DMS, Gesamtdruck, statischer Druck, Steuereingaben) mit aufzunehmen.


    Zitat von "Zentris" pid='291932' dateline='1500669256'


    Wie, um alles in der Welt, kommst du auf die Idee, dass die Glasscheibe für das Ultraschallsignal "transparent" wäre ??? :daumendreh2:


    Was, um alles in der Welt, macht Dich glauben, daß ich diese Annahme träfe? :daumendreh2:

    Zitat


    Im optischen Spektrum ist Glas mehr oder weniger tansparent, im akustischen Spektrum ist das ein Reflektor, also ein Hindernis.

    Licht lässt sich gut als elektromagnetische Welle modellieren, Schall ist eine Druckschwankung in einem Medium, es geht also weniger ums Spektrum, also die Frequenzzusammensetzung, sondern um den Mechanismus des Wellentransports. Dabei wäre es allerdings theoretisch schon möglich, auch durch eine Glasscheibe zu messen, aber das ist dann nicht mehr trivial und vermutlich auch nicht mit dem HC-SR04 zu bewerkstelligen. (Man unterliegt dabei allerdings ziemlich vielen Rahmenbedingungen über Erregerfrequenz, Lehr'sches Dämpfungsmaß, Phasenverschiebung der Antwort, Empfindlichkeit des Empfängers...

    Zitat


    Durch die Überlagerung der Schallwellen erhälst du am Empfänger mehr oder weniger zufällig ein Signal oder nix (Auslöschung der Schallwellen durch Überlagerung) - ähnlich dem Doppelspaltexperiment. Daher deine "chaotischen" Messwerte...

    Die Möglichkeit der Auslöschung durch Phasenverschebung habe ich durch Variation des Abstandes ausschließen können.

    Zitat


    Nimm doch mal die Scheibe weg :-):thumbs1:


    Dann kann ich den Abstand zur Scheibe ja nicht mehr messen :-):thumbs1:

    Beste Grüße,
    Malte

    Einmal editiert, zuletzt von mhoeltken (22. Juli 2017 um 16:12)

  • Ein kleines Update:

    Ich habe das Skript nun von Vorne aufgebaut. Dadurch sank sowohl die Prozessorlast, als auch meine Timingschwierigkeiten. Hier der neue Code:

    Und hier der Output bei bekanntem Objektabstand (ca. 30 cm).

    Der HC-SR04 wird ja jetzt per PWM getriggert und durch die Angabe der Startzeit weiß ich, daß ECHO auf HIGH gezogen wurde. Das sollte (laut Datenblatt) bis ca. 50 Hz eigentlich ganz gut funktionieren. Offenbar allerdings bekomme ich kein Signal zurück, ECHO wird erst nach 200 ms auf LOW gesetzt, was der Timeout ist für den HC-SR04. Andere Sensoren zeigen ähnliche komische Verhalten, was mich dazu bringt gleich die Anschlüsse (Spannungsteiler und Leitungen) neu aufzubauen.

    Ich schreibe dann später ob ich mehr herausgefunden habe. Für Hinweise auf Fehler würde ich mich natürlich immernoch sehr freuen.

    Besten Gruß,
    Malte

    Einmal editiert, zuletzt von mhoeltken (23. Juli 2017 um 17:27)

  • Ich habe mittlerweile (es sind ein paar zu messende Parameter hinzugekommen) den RPi zur Steuerung von mehreren Arduinos vorgesehen. Auf dem Arduino laufen meine Sensorschaltungen wie gewünscht, ich hatte offenbar in Problem mit dem Python-Code. Da ich eine für mich nutzbare Lösung habe, habe ich nicht weiter an dem Problem gearbeitet.

    Vielen Dank für den Input, alle. Ich hoffe, beizeiten kann ich auch bei Fragestellungen behilflich sein (bis dato ist mein Wissen um die RPis noch sehr lückenhaft :) )

Jetzt mitmachen!

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