Kennt das jemand ? HC-Sr04 messen Mist...

Hallöle.
Da brauche ich mich nicht wundern, wieso mein Monster nicht zurecht kommt. In der Front zwei HC-SR04 verbaut (jaha, die billigsten die zu kriegen waren), aber die Dinger funktionieren- jedenfalls bis ca. nen Meter.
Darüber- ab und zu.
Seltsam: nen Timeout gibt es nie, es wird immer irgendwas gemessen- bis rauf zu ungefähr 1.80m (ich habs echt mit verschiedenen Programmen versucht, auch mit verschiedenen Triggerzeiten usw, das Ergebnis ist immer hgalbwegs ähnlich), aber wenn ne Messung 1.70 ergab, bringt die nächste (ich habs auch mit 2s Verzögerung getestet, um irgendwelche Echos auszuschliessen) nur noch die Hälfte oder-irgendwas anderes.
Das Problem tritt bei beiden Sensoren (ich hab noch mehr, die aber jetzt nicht probiert) auf, es ist auch dann, wenn ich sie in der Hand halte (hatte schon was wie Körperschall vermutet, dürft sich so auch ausschliessen lassen), im Freien tritt es ebenfalls auf (auch, wenn ich sie senkrecht nach oben richte)- aber es gibt _immer_ ein Echo, jedoch nie weiter als knappe 2m.

Zugegeben: es sind etwas längere Kabel dran (~ 30 cm), aber _das_ dürft nicht das Problem sein, oder?
Versorgt werden die Brüder mit nem Stepdown-Wandler, es liegen fein 5.27V an..
Kennt das Problem jemand?
Gibts ne Lösung?

Hallo Sly !

Ich habe für mein Sokuti (Solarkunsttier) 5 Stück aus China bei ebay gekauft und warte auf Lieferung. Inzwischen habe ich mich bischen umgeschaut und etwas gelernt: https://www.roboternetz.de/community...ch-vom-HC-SR04 .

Angeblich würde ich davon nur den selektiven Verstärker mit LM324 verwenden und alles Übrige entfernen. Momentan kann ich dir nur empfehlen ohne der 30 cm langen "Antennen" und mit sauberer Spannungsversorgung aus Akku probieren. ;)

Neben den elektrotechnischen Fehlerquellen kann ich mir auch noch eine messtechnische vorstellen:
Es gibt 2 Messmethoden
Methode 1:
Die Dauer des Echopulses wird gemessen (Methode, die das Datenblatt vorschlägt).
Methode 2:
Zeit, die vergeht, bis der Sensor nach Triggerung einen Echo-Puls sendet, wird gemessen.

Ich sebst besitze keinen dieser Sensoren, also kann ich das nicht testen.
Ich hab mal einen Arduino-Testprogramm vorbereitet, das beide Methoden verwendet.
Das Ergebnis könnte aufschlussreich sein.

Code:

---

// Ultraschall-Test
// testet die Genauigkeit eines HC-SR04 Ultraschallsensors
// mit 2 Messmethoden:
//  1. measureAirTime
//      Zeit, die vergeht, bis der Sensor nach Triggerung
//      einen Echo-Puls sendet, wird gemessen.
//  2. measurePulseTime
//      Die Dauer des Echo-Pulses wird gemessen.
//
// Datenblatt:
// https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsB-x2qR4vP8saG73rE/edit?pli=1
//
// Sisor, 23.08.2014

#define PIN_TRIG 8 // Hier Anschluss-Pins definieren
#define PIN_ECHO 9

void trigger() {
  digitalWrite(PIN_TRIG, HIGH);
  delayMicroseconds(10); // 10 µs Triggerzeit (siehe Datenblatt)
  digitalWrite(PIN_TRIG, LOW);
}

long measureAirTime() {
  unsigned long now;
  now = micros();
  trigger();
  while(digitalRead(PIN_ECHO) == LOW);
  return micros() - now;
}

long measurePulseTime() {
  // muss sofort nach measureAirTime()
  // ausgeführt werden!!!
  unsigned long now;
  now = micros();
  while(digitalRead(PIN_ECHO) == HIGH);
  return micros() - now;
}

void printResult(unsigned long airMicros, unsigned long pulseMicros) {
  Serial.print("measured air time  : " );
  Serial.print(airMicros );
  Serial.println(" us");
 
  Serial.print("measured pulse time: " );
  Serial.print(pulseMicros );
  Serial.println(" us");
 
  Serial.println("---");
}

void setup() {
  pinMode(PIN_TRIG, OUTPUT);
  digitalWrite(PIN_TRIG, LOW);
  pinMode(PIN_ECHO, INPUT);
  Serial.begin(57600);
}

void loop() {
  unsigned long airMicros, pulseMicros;
 
  // Messung durchführen
  airMicros  = measureAirTime();
  pulseMicros = measurePulseTime();
 
  // Ausgabe über Serial-Monitor
  printResult(airMicros, pulseMicros);
 
  delay(100);
}

---

Danke euch beiden schonmal.
Zur Stromversorung: es handelt sich um so ein Modul: http://www.dx.com/de/p/dc-3-2-40v-to...w#.U_hekfxX18E
Meiner allerdings ist mit 2A angegeben-die Dinger verwende ich dauernd und bin damit eigentlich bestens bedient bisher..die Spannung für das Ding kommt aus nem Akku.
Umbauen ist nicht, da ich halbwegs die volle Reichweite auch brauche (evtl. reichen 2-3m aber die sind das mindeste).

Dein Programm hab ich eben mal probiert- airTime ist nix, womit man was anfangen könnte. Der Wert liegt, auch wenn ich die Hand fast direkt vor das Ding halte, immer so um die 450 herum, ebenso (er schwankt leicht, aber nicht sehr), auch bei grösseren Entfernungen.
Das funktioniert also nicht.
pulseTime dagegen nimmt proportional mit der Entfernung zu. Den Wert durch 58.2 sollte cm ergeben, das haut, so leidlich, hin, aber nur bis 1.20m, ungefähr. Danach wird es einfach nicht mehr...

Die Beispielprogramme zu diesen Sensoren sehn so aus:

Code:

---

const int TrigPin = 29;
const int EchoPin = 28;
float cm;
void setup()
{
Serial.begin(9600);
pinMode(TrigPin, OUTPUT);
pinMode(EchoPin, INPUT);
}
void loop()
{
digitalWrite(TrigPin, LOW); //Low-high-low level sent a short time pulse to TrigPin
delayMicroseconds(2);
digitalWrite(TrigPin, HIGH);
delayMicroseconds(10);
digitalWrite(TrigPin, LOW);
cm = pulseIn(EchoPin, HIGH) / 58.0; //Echo time converted into cm
cm = (int(cm * 100.0)) / 100.0; // retain two decimal places
Serial.print(cm);
Serial.print("cm");
Serial.println();
delay(1000);
}

---

Allerdings ergibt auch das nur Entfernungen bis ungefähr 1.20. :(
Hab da schon extra ne Sekunde Verzögerung eingebaut, um irgendwelche "wilden" Echos auszuschliessen, hilft nix.
Merkwürdig finde ich, dass ganz offenbar das Echo ja empfangen wird- nur die Zeit stimmt irgendwie absolut nicht.
Ausserdem schwanken die Werte extrem: bei beiden Programmen sieht das ungefähr so aus:

Code:

---

122.63cm
93.12cm
76.56cm
88.37cm
90.70cm
74.18cm
91.18cm
121.86cm
77.96cm

---

Das ist die Ausgabe des von mir geposteten Programms, während der Zeit hat sich vor dem Sensor _nichts_ bewegt- aber mit dem Programm von Sisor sieht es ähnlich aus.

Hallo Sly,

aktuell beschäftige ich mich in einem kleinen Team, aber eher am Rande, mit Ultraschall. Dabei waren mir eklatante Messfehler bei einem bestimmten Messaufbau aufgefallen. Als Grund dafür vermute ich Echos, die von einem anvisierten Objekt ausgestreut werden.

Zitat:

---

... Das ist die Ausgabe ... während der Zeit hat sich vor dem Sensor _nichts_ bewegt- ...

---

In dem Rahmen habe ich einen SRF02 getestet - eher nur auf Funktion geprüft :

Code:

---

// ============================================================================= =
//      Daten lesen vom Sensor SRF02, SLAVESR02 = 0xE0/224dez; Ausgabe auf uart0
//              Messvorgang
//      Um einen Messvorgang durchzuführen muss zuerst das Register 0 durch den
//      Startbefehl (zum Beispiel Code 81/0x51) gestartet werden.
//      Danach fügt man einfach einen Wartebefehl von 65 Millisekunden ein und
//      fragt anschließend Register 2 und 3 nach der Entfernung ab. Das war´s scho
// - - - - - - - - - - - - - - - -

---

Die Genauigkeit hat mich (als alter IR-Sharp-Messfreak) schon begeistert, auch wenn er meine offene Zimmertür auf 2 m Entfernung als Hindernis anmisst. Aber eine Messreihe lief total aus dem Ruder. Dabei lag der Sensor auf dem Tisch und schallte senkrecht hoch an die Decke. Aktueller Messabstand rund 1m 76. Die hatte der Gute auch brav angemessen. Nach ner Weile streuten die Messwerte ähnlich wie Deine. Der Sensor war verschoben worden und peilte nun ne Deckenlampe an - so ne flachgedrückte Papierlampe. Offenbar war diese Lampe beim Anmessen zur Echo-Membran geworden, die mir die Messergebnisse verhunzte. Ein in die Lampe eingelegtes Stück Druckerpapier (80g/m³) beendete den Spuk, das Ergebnis war ziemlich konstant 1,48. Auch wenn ich das Papierblatt vor die Lampe hielt waren die Ergebnisse sinnig und recht ruhig.

Könntest Du ähnliche Probleme in Deinem Messaufbau haben ?

Zitat:

---

Dein Programm hab ich eben mal probiert- airTime ist nix, womit man was anfangen könnte. Der Wert liegt, auch wenn ich die Hand fast direkt vor das Ding halte, immer so um die 450 herum, ebenso (er schwankt leicht, aber nicht sehr), auch bei grösseren Entfernungen.
Das funktioniert also nicht.

---

Ups, dann hatte ich die Funktion des Sensors falsch eingeschätzt.
Der Sensor schaltet also nach Triggerung den Echo-Ausgang solange HIGH, bis ein Echo auftritt.

---
User Manual S.7

Zitat:

---

When the sensor detected ultrasonic from receiver, it will set the Echo pin to HIGH and delay for a period (width)...

---

Dieser Teil der Anleitung ist also ist also falsch. Das Echo Pin wird immer sofort nach Triggerung auf HIGH gesetzt, und nicht erst nach einer Ultraschall-Impulsantwort.

Hm, wenn ich das da: http://arduino.cc/en/pmwiki.php?n=Reference/PulseIn richtig interpretiere, dann ist dem tatsächlich so:
nach dem Triggern wird der Echo-Pin (vom Sensor selber) HIGH gesetzt, und wenn das Echo eintrifft, geht er auf LOW.
Die Zeit wird demnach gemessen, denn in den Beipielprogrammen wird ja immer

Code:

---

cm = pulseIn(EchoPin, HIGH) / 58.0; //Echo time converted into cm

---

benutzt.

Und diese wildgewordenen Echos-hm, ich glaubs nicht, denn ich hab zum einen in einigen Messreihen bewusst immer nach jeder Messung ne Sekunde (ich glaub, auch zwei schon) getrödelt, damit sich irgendwelche Echos verflüchtigen können und: selbst draussen, wenn ich den Sensor zum Himmel gerichtet hatte, gab es das Problem. Und nee: soo niedrig waren die Wolken auch wieder nich, dass ich schon mitm Kopf drin steckte. ;)

Ich hatte zuerst ja vermutet, dass die Dinger einfach zu "leise" sind (es sind wirklich die billigsten, die ich gefunden hab), aber dann gäb es gar kein Echo- das aber eben ist _nicht_ der Fall-es gibt immer eins, nur irgendwie viel zu schnell.
Und: inzwischen hab ich dreie von denen probiert-überall das selbe, auch mit etwas kürzerem Kabel.

Als nächstes werd ich mir wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung), und das so, dass ich die Ausgabe noch irgendwie ablesen kann, auf 4m erkenn ich auf dem 16x2 LCD nämlich nicht mehr wirklich was.
Mal gucken, ob die soweit reichen oder nicht.
Möglicherweise trödelt der Sensor einfach intern irgendwo rum, und man kanns raus rechnen....

1. pulseIn() kannte ich noch nicht, ist aber definitiv die richtige Wahl.
2. Ist deine Reflexionsfläche eine ebene harte Fläche, wie z.B. eine Zimmerdecke?

Zitat:

---

... wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung) ...

---

Das mache ich in der Testphase eigentlich immer. Ist doch egal welche Längeneinheit man hat - ob ADC-Werte, russische Werst oder Parsec - Umrechnen kann man immer noch später. Und meist bleibt der Code bei mir dann auch drin - allenfalls auskommentiert.

Zitat:

---

... Und diese wildgewordenen Echos-hm, ich glaubs nicht ...

---

Na ja, bei mir wars purer Zufall. Und ein schauderschönes Beispiel von Chaos, Interferenz, ungerichteter Abstrahlung etc. Eine (für mich wirklich unwahrscheinliche) Möglichkeit wäre noch ein vibrierender Sensor. Seit ich minikleine Brüllwürfel hab hüpfen sehen . . . aber bei Ultraschall müssten das schon s..schnelle Vibrationen sein; glaub ich hier nicht.

Zitat:

---

Als nächstes werd ich mir wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung), und das so, dass ich die Ausgabe noch irgendwie ablesen kann, auf 4m erkenn ich auf dem 16x2 LCD nämlich nicht mehr wirklich was.
Mal gucken, ob die soweit reichen oder nicht.
Möglicherweise trödelt der Sensor einfach intern irgendwo rum, und man kanns raus rechnen....

---

Da bin ich aber mal gespannt: Das Problem ist doch, dass der Sensor anscheinend beim gleichen Testaufbau unterschiedliche Werte ausspuckt.