US-015 Sensor auslesen

  • Hallo zusammen

    ich habe folgende Sequenz im Arduino zum auslesen des Sensors programmiert:

    Die Versuchsanordung besteht aus dem Roboter mit dem Sensor und eine Schachtel im Abstand 25cm vor dem Roboter.

    Wenn ich die übertragenen Werte mit der Arduino Entwicklungsumgebung anschaue sehe ich in der Reihe

    viele richtige Werte mit 24 und 25 cm
    eingestreut der Wert 400cm (timeout) einmalig oder mehrmals hintereinander

    Ich kann mich also nicht auf die Messung verlassen!

    Mach ich was falsch oder sind die Sensoren nicht verlässlich?

    Der Arduino läuft mit einem Zyklus von ca. 400 ms

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

  • Hallo Wolfgang,
    mal ganz objektiv betrachtet mir folgende mögliche Ursachen dazu ein:

    • Der Sensor ist "falsch", d.h. die Daten kommen vom Sensor schon falsch (in deinem Fall gar nicht)
      Die Ursache kann dabei entwerder sein, dass der Sensor nicht startet, oder er tatsächlich nichts erkennt (Zu klein, Absorption).
    • Der Arduino ist "falsch", das würde bedeuten, dass der Arduino entweder den Start nicht richtig sendet, oder er die Daten des Sensors nicht richtig erkennt
      Die Gründe dafür können z.B. Störungen sein (Stichwort EMV), kurze Einbrüche der Spannungsversorgung, einen zu niedrigen Pegel des Sensors Wie verhält sich die PulsIn Funktion eigentlich, wenn der Pin bereits als HIGH beim Aufruf der Funktion erkannt wird? Dieser Fall kann auftreten, wenn der Arduino "zu langsam" ist.


    Hast du ein (digitales) Oszilloskop? Falls ja könntest du dir die Signale vom Sensor mal live anschauen. Wenn der Wert tatsächlich ab und zu sehr oft hintereinander falsch gelesen wird, sollte das Problem zu erkennen sein. (Bei einem digitalen Oszilloskop hilft dir vllt. auch der externe Trigger, den du im Fehlerfall vom Arduino aus triggern kannst (Datenblatt für Spannungen anschauen!!))

    Gruß
    Chris

    Einmal editiert, zuletzt von ChrisvA (30. April 2016 um 22:22)

  • Hi Chris
    Die Stromversorgung des Arduino ist ein NiMH Akku mit 10'000 mAh (8x 1.2 V Typ D) , ich würde mal Spanungseinbrüche ausschliessen.

    Analysewerkzeuge darauf ansetzen ist eher mühsam bei zyklischen Ereignissen mit sporadischem Effekt.

    Die Sequenz im Arduino wird möglicherweise durch die ISR der Encoder unterbrochen.

    Kann man die Sensor Sequenz schützen vor dieser Unterbrechung?

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (30. April 2016 um 23:46)

  • Naja, so simpel war meine Frage natürlich nicht gemeint :)

    Der US Sensoren hat ein Timeout von 23ms eingestellt (Begrenzung des Messbereiches auf 400 cm)

    Klar kann ich die Interrupts verhindern, das hat natürlich Folgen, ich verliere Interrupts für das Abtasten der Encoder, was im 1 ms Zyklus passiert. (Die Pulsänge der Encoder beträgt etwa 2ms)

    Die Frage ist ob diese Interrupts überhaupt stören können?
    Wenn ja, muss ich das Lesen der US Sensoren evtl auch per Interrupt tun.

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (1. Mai 2016 um 14:09)

  • Die Logik erschliesst sich mir nun nicht, raten kann ich auch selber, es geht um Wissen.

    so wie ich die Spezifikation von PulseIn verstehe ist sie ebenfalls interruptgesteuert. d.h. das Programm wird angehalten bis der Impuls von high auf low geht bzw. bis timeout.
    In meinem Fall würde das bedeuten der Impuls bleibt auf high und der timeout schlägt zu.

    Insofern sollte ein anderer Interrupt nicht stören, höchstens das Zeitverhalten geringfügig verändern, was bei der Encoder routine kaum der Fall sein wird, da die Befehlsfolgen minimal sind.

    Was stören kann, ist das Unterdrücken der Interrupts (cli(), sei() während der Ausführung der IRS der Encoder. damit könnte ein anderer Interrupt verloren gehen, wenn ich das richtig interpretiere.

    Code
    int16_t QuadratureEncoderReadRt( void ) // read single step encoders
    {
     int16_t val;
     cli();
     val = encDeltaRt;
     encDeltaRt = 0;
     sei();
     return val; // counts since last call
    }

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (1. Mai 2016 um 16:06)

  • Hi Wolfgang,
    ich habe die sharp gp2y0a41sk0f, wie auch die HC-SR04 getestet (mit den Sensoren etwas gespielt).
    Alle meine Teste haben ergeben, dass die "dinge" ehe grobe Präzision besitzen. Wie bei Dir paar Werte waren richtig, viele fast richtig und etwas 20% inakzeptable "nirvana werte".

    Als ich den WENGLOR CP35MHT80 Laser Distanzsensor getestet habe, bekam ich immer einen, immer gleichen und immer den richtigen Wert.
    (Solche Sensoren kann ich mir aus der Arbeit ausleihen.)

    Gruß
    Georg

    Sollte ich "Müll- reden" :blush: - bitte mich (?) "auf die Nuss" hauen. :huh:

    Einmal editiert, zuletzt von georg-Lu_1963-1 (1. Mai 2016 um 19:01)

  • interessant, ich bin schon etwas im Zweifel ob ich die richtige Hardware verwendet habe.

    Das Rover5 Chassis kann nicht geradeaus fahren ich muss in den beiden PWM Ansteuerungen 30% Differenz einstellen damit der Roboter geradeaus fährt. Dadurch ist der Antrieb einseitig (rechts wird mitgezogen) und die Odometriedaten sind mit einem Fehler beaufschlagt.
    Das Chassis hatte eine Differenz zwischen dem linken und rechten encoder...
    Die Entfernungsmessung ist unzulänglich mit US-015

    Bin kurz davor das Projekt als gescheitert hinzuschmeissen

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]WENGLOR CP35MHT80 ist ja nicht ganz billig und für einen Roboter etwas gross[/font]

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (1. Mai 2016 um 19:16)

  • Was WENGLOR CP35MHT80 angeht, es war NUR ein Vergleich / Beispiel für exakte Werte. Ich meinte damit nicht den Einsatz in Deinem Roboter!
    Man sieht in der Literatur wie auch auf Youtube ... vielen Roboter, die somit (RPI und US-015 ... HC-SR04) funktionieren - also nicht aufgeben. Mit Arduino kenne ich mich nicht aus.

    Gruß
    Georg

    Sollte ich "Müll- reden" :blush: - bitte mich (?) "auf die Nuss" hauen. :huh:

  • ich versuchs nochmal auf diesem Weg:

    Drei Werte lesen und nur übernehmen wenn sie gültig sind (nicht out of range), davon dann den Mittelwert bilden.

    Da ich den Wert nur für die Erkennung eines Hindernisses verwende könnte das reichen.

    Ich habe auch herausgefunden, dass die Fehlerquote (out of range) mt den eingestellten Werten 20/10 us am tiefsten ist (ca. 20%)

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (2. Mai 2016 um 15:19)

  • So hier noch eine verbesserte Version

    Ein alter Wert wird im Schieberegister behalten und zwei neue dazugelesen (Gewichtung der neuen Werte).
    Damit erreiche ich zumindest eine Verteilung +- 6cm bei ca. 30 Werten.

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (2. Mai 2016 um 17:37)

Jetzt mitmachen!

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