Roboter soll mir hinterherfahren

  • Finde diesen Bereich "laufende Projekte und Ideen" ganz toll und Eure unterstützenden Gedanken sind echt super. Vielen Dank mal an dieser Stelle.

    Gnatz:

    ok, gute Ansätze bei US ... muss Schmalz in die Software, aber so könnte es gehen. Der max. Abstand soll 3 - 4 m betragen.

    @__deets__:

    Ja, schaue ich mir dann mal genauer an. Wenn sich was in C++ findet und es geht nicht total über meinen Horizont hinaus :geek:

    Mir ist noch ein weiterer Lösungsansatz in den Sinn gekommen - ein akustischer Ton. Umstehende Personen würden den Ton dann auch hören - wäre aber mal kein Problem.

    Identifizierung über Frequenz oder Tonfolge: Ein tiefer Ton wäre nicht schlecht jedoch schwer erzeugbar mit kleinem Lautsprecher - dafür aber nicht so gerichtet wie ein hoher Ton. Bei spezieller Frequenz müsste man diese dann nach dem Mikrofon bestmöglich heraus filtern. Bei Taktung die Tonfolge identifizieren.

  • Hallo,

    bei mir geht es jetzt erst weiter.

    Habe einen Arduino als US-Sender und einen Raspi als US-Empfänger und versuche jetzt auf dem Raspi ein HIGH einzufangen. Klappt aber nicht. Anbei beide Programme als Ausschnitt:

    Beide HC-SR04 sind zueinander gerichtet. Später soll der Empfänger auf einen Servo montiert werden um die Senderrichtung zu identifizieren.

    Mache ich da einen Gedankenfehler?

    Danke

  • Hallo bug_reporter,

    Dein Empfänger schläft 1 Sekunde und horcht und guckt nur einmalig. Wenn in dieser kurzen Zeitspanne nichts reinkommt, dann schläft er wieder.

    Das ist so, als wenn Du im Objektschutz arbeitest und pro Stunde 59 Minuten schläfst - tief und fest. Und in der einen Minute drehst Du Dich einmal im Kreis herum - aber Du entdeckst niemals einen Einbrecher.

    Wenn morgens die Ablösung kommt ist die Firma leergeräumt.

    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.

  • Neben der richtigen Anmerkung von Andreas wäre ich mir nicht so sicher, das die HC-SR04 überhaupt so kommunizieren können. Die sind integrierter als man so denkt, der Echo pin löst nicht einfach aus, wenn er was hört. Sondern das ist abhängig von einem vorher gesandten Impuls. Wenn es dir hier um eine Lokalisation zb einer Basisstation geht, würde ich eher eine IR Lösung anstreben, mit einem entsprechenden Fokus durch abschattung.

  • Hallo __deets__,

    Neben der richtigen Anmerkung von Andreas wäre ich mir nicht so sicher, das die HC-SR04 überhaupt so kommunizieren können. Die sind integrierter als man so denkt, der Echo pin löst nicht einfach aus, wenn er was hört. Sondern das ist abhängig von einem vorher gesandten Impuls. Wenn es dir hier um eine Lokalisation zb einer Basisstation geht, würde ich eher eine IR Lösung anstreben, mit einem entsprechenden Fokus durch abschattung.

    irgendwas in der Richtung meine ich im Datenblatt gelesen zu haben...

    [EDIT:]

    Hallo bug_reporter,

    wenn es mit den beiden verwendeten Modulen funktionieren sollte, dann nur so:

    • Sender sendet permanent mit geringstmöglicher Wartezeit auf Rückmeldungen - denn die Rückmeldungen sollen ja nicht ausgewertet werden
    • Empfänger sendet ebenfalls permanent mit maximaler Wartezeit auf Rückmeldungen, um den ECHO-Pin scharf zu schalten - ohne Scharf-Schalten wird nichts "gehört" werden können. Das "erste" Signal beendet dann den "Horch"-Modus.

    Dies funktioniert nur, dann, wenn der Empfänger auch auf andere Quellen als sich selbst erkennt. Wie gesagt, da stand was im Datenblatt.

    Berichte bitte, was dabei herausgekommen ist.

    [/EDIT]


    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.

    3 Mal editiert, zuletzt von Andreas (29. Juli 2020 um 17:36)

  • Hallo bug_reporter,

    mein EDIT hast Du umgesetzt?


    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.

  • War das so gemeint? Geht leider nicht.

    Arduino:

    Code
    void loop(){
      pinMode(VG_PINGPIN, OUTPUT); 
      digitalWrite(VG_PINGPIN, LOW);
      delayMicroseconds(2);
      digitalWrite(VG_PINGPIN, HIGH);
      delayMicroseconds(5);
      digitalWrite(VG_PINGPIN, LOW);
    }

    Raspi

  • Hallo bug_reporter,

    War das so gemeint? Geht leider nicht.

    Nö ... ich schaue noch mal ins Datenblatt und korrigiere Deinen Code...

    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 (29. Juli 2020 um 19:57)

  • Das du den pin nur high machst ist? ist schon mal sinnlos. Ob das Protokoll das hergibt - da erwähnt Andreas zu recht das Datenblatt.

  • Hallo bug_reporter,

    die Funktion pulseIn() hat drei Argumente:

    1. Echo-Pin,
    2. Zustand des Pins bei Eingang eines Signals = HIGH
    3. timeout

    Hier sollst Du beim Sendeprogramm für timeout einen sehr kurzen Wert eintragen, damit der Sender ohne nennenswerte Unterbrechung in kurzen regelmäßigen Abständen seine Schallpakete sendet.

    Beim Empfängerprogramm dagegen sollst du den timeout auf einen (unsinnig) hohen Wert setzen, damit der Empfänger die Möglichkeit hat, irgendwas von den vielen Sendungen empfangen zu können und möglichst wenig in irgendwelchen Waits und Sleeps verlorengeht. Die Funktion pulseIn() beim Empfänger ist dann nach dem Empfang des ersten Pakets erfolgreich beendet.

    Wichtig: Sowohl Sender muss auch proforma auf Empfang stehen (sonst funktioniert die Sache nicht rund) als auch der Empfänger muss senden (um überhaupt mal auf Empfang gesetzt zu werden).


    Jetzt bist du dran, die Funktion pulseIn() mit sinnvollen Argumenten anzuwenden.


    Wenn das - algorithmisch korrekt umgesetzt - nicht funktioniert, dann hast Du Dich in diesem Thread auf den Einsatz einer ungeeigneten Technik verleiten lassen oder die Schalte von Sender und Empfänger entspricht nicht den jeweiligen Programmen.

    Beispiel für den Sender:

    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.

    4 Mal editiert, zuletzt von Andreas (29. Juli 2020 um 21:17)

  • Man bekommt natürlich nicht wirklich gute Datenblätter. Oder ich finde die nicht. Alles was ich sehe sind microcontroller, die an sich generisch sind, aber natürlich mit einer bestimmten Firmware programmiert sind. Und das die ohne Aussendung nur empfängt- das kann ich mir schwer vorstellen. Deren Sinn und Zweck besteht ja genau darin, zb mehrfache Echos zu unterdrücken.

    Edit: hier mal eine Erklärung mit Schaltbild & dem uC der verwandt wird. http://www.pcserviceselectronics.co.uk/arduino/Ultrasonic/electronics.php

    Ich habe ja schon mal “Kamera” gesagt. Ich sag’s nochmal.

    Einmal editiert, zuletzt von MistyFlower59469 (29. Juli 2020 um 21:13)

  • Ich habe ja schon mal “Kamera” gesagt. Ich sag’s nochmal.

    Kamera ist nicht meins :thumbdown:und bischen Spass soll es ja machen. Lieber mach ich da bissle Elektronik und bau eigenen US-Sender und US-Empfänger ... oder aber erstmal IR (muss aber "codiert" gesendet werden sonst spielen andere Wärmequellen wie Sonne mit rein)

    Beim Empfängerprogramm dagegen sollst du den timeout auf einen (unsinnig) hohen Wert setzen, damit der Empfänger die Möglichkeit hat, irgendwas von den vielen Sendungen empfangen zu können und möglichst wenig in irgendwelchen Waits und Sleeps verlorengeht. Die Funktion pulseIn() beim Empfänger ist dann nach dem Empfang des ersten Pakets erfolgreich beendet.

    Als Empfänger habe ich "digitalRead" (wiringPi Raspi) ohne timeout-Einstellmöglichkeit. Weis nicht wie lange der horcht, versuche derzeit mit vielen Befehlswiederholungen was zu ergattern. Beim Sender am Arduino habe ich deinen Code im Einsatz.

    Einmal editiert, zuletzt von bug-reporter (30. Juli 2020 um 13:57)

  • Bei Ultraschall (und vom Prinzip her auch bei Infrarot) haben käufliche Module den Nachteil, dass die guten nur "ihr eigenes" Signal auswerten und die schlechten jedes halbwegs passende Signal. Beides ist für diese Anwendung gleichermaßen unpassend. HC-SR04 scheint zu den "guten" Modulen zu gehören. Es sendet einen Impuls und nur wenn es das passende Echo bekommt, gibt es den Empfangsimpuls aus. Damit kann man einen Abstand messen (und wird durch "fremde" Ultraschallsignale nicht gestört), aber schon die Erkennung einer Richtung ist so nicht einfach möglich. Was man für diese Aufgabenstellung braucht sind ein Sender und 2 Mikrofone im Roboter. Das Sendesignal kommt bei den Mikrofonen nur gleichzeitig an, wenn die verfolgte Person mittig zum Roboter steht. Weicht die Person von der Richtung her ab, ist zwischen den Empfangssignalen ein kleiner Zeitunterschied. Aus der Laufzeit kann man die Entfernung und aus dem Zeitunterschied die Richtung herleiten. Damit der Aufbau sein eigenes von fremden Ultraschallsignalen unterscheiden kann, muss entweder die Empfangsfrequenz sehr genau gemessen und mit der Sendefrequenz verglichen werden. (Das macht man früher mit speziellen Bausteinen LM556 oder NE556 oder dem 4046 bzw. 74HC4046 PLL-Baustein plus etwas Zusatzlogik.) Der Frequenzvergleich klappt da recht gut. Alternativ kann man das Sendesignal modulieren und nur, wenn das Empfangssignal die gleiche Modulation hat, wird es "anerkannt". Das wäre also der erste Schritt. Den zeitliche Abstand zwischen den einzelnen Ultraschallimpulsen kann man aus dem Abstand zwischen verfolgter Person und Roboter wie folgt berechnen:

    Maximaler Abstand 3 bis 4 m bedeutet, dass der Schall 6 bis 8 m zurücklegen muss (Hinweg Roboter zur Person plus Rückweg von der Person zum Roboter). Bei einer Schallgeschwindigkeit von 345 m/s (bei etwa 25°C) kann es knapp 25 ms dauern, bis das Echo ankommt. (Man muss ja mit berücksichtigen, dass der Impuls selbst auch eine gewisse Länge hat.) Damit müsste der Abstand zwischen den Impulsen mindestens 30 ms betragen.

    Wenn man nun sicher sein möchte, dass der Roboter der "richtigen" Person folgt, muss diese das Signal ja auch empfangen (und später selbst einen Kennungsimpuls aussenden). Die Person empfängt den Sendeimpuls nach 10 bis 12 ms (Laufzeit für 3 bis 4 m). Dann muss sie warten, bis der Originalimpuls beim Empfänger angekommen ist und erst dann darf sie den Bestätigungsimpuls aussenden. Das könnte zeitlich so aussehen:

    Der Roboter sendet seinen Impuls. Dieser kommt (bei maximalen Abstand zur Person) dort nach etwa 12 ms an, wird reflektiert und erreicht den Roboter nach weiteren 12 ms für den Rückweg. Jetzt könnte auch der Identifikationssender an der Person den Bestätigungimpuls losschicken, der dann nach weiteren 12 ms den Roboter erreicht. Der Roboter empfängt also 24 ms nach Aussenden seines Impulses dessen Echo und etwa 35 ms nach dem Aussenden den Identifikationsimpuls.

    Nun könnte ja das Echo von einer fremden Person ausgelöst sein und der Identifikationsimpuls von der richtigen Person. Um das auszuschließen, muss ein wenig Mathematik her und die Zeit zwischen Empfang des Impulses und Absenden des Bestätigungsimpulses genauer definiert sein. Dann weiß der Roboter dass der Bestätigungimpuls genau um diese festgelegte Zeit nach dem Echo kommen muss, sonst hat er die falsche Person im Visier.

    Der HC-SR04 hat eine Messreichweite von 3 m. Für die maximal zulässige Entfernung zur Person muss also die Verstärkung etwas höher sein, zumal Personen meist Kleidung tragen, die weniger stark reflektiert als glatte Oberflächen. Ich hoffe, dass meine Darstellung nicht zu verwirrend (und entmutigend) war. Aber für solche Aufgabenstellungen kann man nur selten auf "fertige" Hardware und Softwaremodule zurückgreifen. So ganz genau ist die Zeitmessung in C oder Phyton auch nicht. Wenn ich so etwas machen musste, habe ich jedenfalls immer in Assembler arbeiten müssen (damals mit Prozessoren der ATMEL 8051-Familie).

    Wie anfangs erwähnt, Infrarotsignale sind auch nicht einfacher auszuwerten. Und einfach ist die Mustererkennung einer Bildauswertung auch nicht - jedenfalls nicht, wenn man daraus auch noch Steuersignale für die Geschwindigkeit und Richtung des Roboters ableiten will. Dafür lernt man sehr viel und es macht Spaß, wenn zum Schluss alles richtig funktioniert.

  • Danke Gnatz,

    alles super analysiert und dargelegt

    Damit kann man einen Abstand messen (und wird durch "fremde" Ultraschallsignale nicht gestört), aber schon die Erkennung einer Richtung ist so nicht einfach möglich. Was man für diese Aufgabenstellung braucht sind ein Sender und 2 Mikrofone im Roboter

    ja ok

    Wenn man nun sicher sein möchte, dass der Roboter der "richtigen" Person folgt,

    Kann man vielleicht über unterschiedliche Pulslängen steuern


    Und einfach ist die Mustererkennung einer Bildauswertung auch nicht

    Ob das funktioniert wenn man seitlich zum Roboter steht oder teilweise verdeckt steht?

    Will jetzt mal bei US bleiben und einen US Empfänger vom HC-SR04 ablöten und versuchen mal auf dem Oszi ein Empfangssignal zu bekommen. Dann bin ich nicht mehr so blind und habe die Elektronik und die codierung des Modules vom Hals. Unterlagen wie dieser beschaltet werden muss sind sehr willkommen (OPV erforderlich oder nur ein Transistorverstärkung ??).

    Danke nochmals

  • ... habe ich versucht zu verstehen, ist aber ziemlich komplex :conf:

    Nächste Vorgehensweise: Nein, nicht ablöten sondern werde versuchen den Ultraschall-Empfang am HC-SR04 irgendwo nach Verstärker und Filter mit dem Oszi abzunehmen. Den Sender werde ich mit einem bestimmten Takt arbeiten lassen um den evtl. Empfang identifizieren zu können.

    Hoffentlich sehe ich das nicht zu unbedarft :blush:

  • Kannst ihn abnehmen, da wird schon was zu sehen sein. Nur enthält der uC ja ne Menge Code, um aus dem was da reinkommt ein Signal zu destillieren. Wenn du daran schrauben willst, wirst du schon was ähnliches machen müssen. Und der pi ist zumindest für die datenaufnahme zu langsam. Da wird also noch ein uC fällig.

Jetzt mitmachen!

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