Menü
Aktuelles
Von:
Filter

Ultraschallsensoren - bitte um Hilfe

W

wolodk

Member
Hej, mein Name ist Wolfgang Lohmann und ich lebe in Dänemark.

Letzten Herbst bin ich zufällig auf dieses Forum gestossen und habe mich über den Winter von Eurer Begeisterung anstecken lassen. Tolles Projekt und tolles Forum - vielen Dank für die vielen tollen Beiträge.

Vor ein paar Monaten habe ich mir das komplette Set aus dem Shop gekauft und - leider noch ohne Platine - mit Lüsterklemmen und Steckbrettern aufgebaut. Soweit habe ich, wie ich glaube, das meiste hinbekommen und - auf der Werkbank - läuft der Mower. Er lässt sich über die App steuern und auch im Auto-Modus macht er was er soll.

Der erste "Feld"versuch ging dann buchstäblich nach hinten los. Der Mower wollte nur noch rückwärts fahren. Beim Auslesen der US Werte habe ich dann gesehen, dass diese bei allen drei Sensoren um die 300 schwankten, obwohl kein Hindernis vor den Sensoren war. Zurück auf die Werkbank und - alles funktioniert und die Werte für die US Sensoren liegen ohne Hindernis wieder auf 0.

Ich habe das Forum daraufhin durchsucht und auch einige Beiträge mit dem gleichen Erscheinungsbild entdeckt, doch leider keine Lösung gefunden, wie das Verhalten der US Sensoren geändert werden kann.
Deshalb an dieser Stelle meine Frage nach einer Lösung - ein Hinweis auf mögliche Lösungsansätze wäre auch schon hilfreich.

Meine Konfiguration:
- Komplettset aus dem Shop
- 2 x 12V 7Ah Blei/Gel Batterien

- Software version 590
[ul]
[li]Odometri - ja[/li]
[li]Ultraschall - ja[/li]
[li]IMU - nein[/li]
[li]Perimeterschleife - nein[/li]
[li]Ladekontrolle - nein[/li]

[/ul]
Gruss
Wolfgang
 
Hey Wolfgang,

zufällig habe ich auch gerade das gleiche Problem gehabt.
Er schiebt permanent mit State "REV" rückwärts und sowie man Sonar deaktiviert funktioniert das Fahren korrekt.
Ich bin mir im Moment noch nicht sicher ob das am Einbau liegt oder an Reflexionen.
Bei mir sind die Sensoren ziemlich tief eingebaut. Das muß ich mal eingrenzen.
Vor einiger Zeit habe ich auch in einem Thread gelesen, daß ein Einbau, bei dem die Sender- und Empfängerkapsel mechanisch über das Gehäuse verbunden sind (bei mir sind es Maßgeschneiderte Bohrungen in der Frontstoßstange) die Ursache für Rückkopplungen sein können.
Selbst im Testaufbau hatte ich bei einem Sensor im eingebauten Zustand häufig den Fall, daß dieser einen geringen Digitwert (bei in etwa 6cm) lieferte ohne das ein Hindernis vorhanden war.

In welcher Höhe sind den die Sensoren beim Original-Ardumower-Gehäuse montiert?
Liegen die Kapseln in der Gehäuseaufnahme frei?

Was ist, wenn Du ihn vorn etwas aufbockst, sodaß die Sensoren quasi leicht gen Himmel gucken?

Gruß
Aiko
 
Hej Aiko,

der Bodenabstand der Sensoren beim Ardumower ist ca. 155mm.
Bei mir sind die Sensoren in die vorgesehenen Löcher eingebaut. Hierbei entsteht Kontakt zu den Sensorgehäusen, welches evtl. zu Rückkopplungen führen kann.
Was ich nicht verstehe ist, dass auf der Werkbank alles funktioniert - an der frischen Luft leider nicht, selbst wenn ich ihn in die Luft schauen lasse.

Ich werde am Wochenende die Sensoren ausbauen und vor der Frontplatte montieren - mal sehen ob das hilft.


Gruss
Wolfgang
 
Hallo Aiko,

ich habe, wie angekündigt, die Sensoren vor die Frontplatte gesetzt und leider die gleichen Ergebnisse erhalten. Die Werte der Sensoren schwanken um die 300 und der Mower fährt nur rückwärts. Ich habe daraufhin die US Sensoren auf einem Testaufbau getestet und auch noch mal die Verkabelung überprüft - war alles OK.
Daraufhin habe ich die "Brechstange" angesetzt und im Code (drivers.cpp) alle Werte unter 400 auf 0 (NO_ECHO) gesetzt.
Die ersten "Stehversuche" im Freien sehen positiv aus. Gefahren bin ich noch nicht aber der Mower verhält sich im Freien jetzt wie auf der Werkbank.

Gruss
Wolfgang
 
Hallo Wolfgang,

Sorry, bin grad beruflich ziemlich eingespannt. Deshalb erst jetzt...

Ich bin unabhängig von Deinem Test am Wochenende auf die gleiche Erkenntnis gekommen und habe bei mir schwankende Werte zwischen 170 und 280 festgestellt. Diese habe ich genauso auf NO_ECHO gesetzt. Leider ist mir wieder mal ein HC-05 abgeraucht, was weitere Tests grad verschoben hat.

Habe aber noch jenes gefunden:
http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html

Dieser Emil hat festgestellt, daß es offenbar ein konstruktiv bedingtes Problem mit diesen Sensoren geben muß.
Mit einer neuen Platine und anderer Software hat er diese Reflektionen in den Griff bekommen.
Es scheint also nicht an unseren Aufbauten zu liegen. Ich werde das demnächst mit überarbeiteter Bluetoothmodul-Anbindung und der Brechstange im Echtbetrieb testen. Im Moment betreibe ich ihn nur mit Button ;)

Gruß
Aiko
 
Hallo Aiko,

danke für den Link - der Artikel ist sehr interessant - davon kann ich ableiten, dass meine Werkstatt zu klein ist, da der US Sensor immer noch auf einen harten Hintergrund trifft :)

Im Freigelände funktioniert es soweit mit der Änderung im Code. Sollten andere auf das gleiche Problem stossen, könnte man in der App vielleicht einen weiteren Schieberegler erwägen, mit dem man dann alle Werte unter einem bestimmten Limit auf NO_ECHO setzt.

Gruss
Wolfgang
 
Bei meinen Sensoren ist immer ein Wert grösser Null wenn die Motoren anlaufen oder stoppen. Deswegen werde ich erstmal die Motoren versuchen zu entstören. Dann sehen wir mal weiter.
 
Keine Ahnung, wie es im aktuellen Code gemacht wird, wichtig ist ja auch immer, dass der Trigger-Impuls des einen Sensors nicht ein Echo bei einem der beiden anderen Sensoren auslöst.

Bei mir hat testweise geholfen, die Sensoren mit doppelseitigen Schaumklebeband draußen vor das Gehäuse zu kleben (und zwar die Stecker werden angeklebt, nicht die Platine oder gar die Schallemitter). Im Code habe ich eine kleine Verzögerung eingebaut, zwischen dem Triggern der einzelnen Module. Und schon lief es problemlos.

Gruß,
Jem

PS: Und ja, es ist keine schöne Lösung, aber im Test hat es funktioniert. Diese Erkenntnis ist ja auch was wert :)
 
Bei mir hat ein Widerstand von 10K zwischen Trigger und GND die Sache beruhigt. Bin zufrieden damit
 
I run my Ardumower's first real life test today and I was having the same problem: the poor beast could do nothing but drive backwards all the time.

Jemihi schrieb:
...
Im Code habe ich eine kleine Verzögerung eingebaut, zwischen dem Triggern der einzelnen Module. Und schon lief es problemlos.
...
Zum Vergrößern anklicken....

This did the trick for me. Many, many thanks to you.

Gruss

Manuel

P.S.: Sorry for using English here. If any of you could please translate this to German so other users can possibly benefit from a workable solution ...
 
Zuletzt bearbeitet von einem Moderator:
@Jem: Kannst Du Deinen Codeschnipsel mal hier mit einstellen?

Die Verzögerung und/oder den Pulldown-Trick von Gerd würde ich auch mal bei Gelegenheit ausprobieren.
Hatte bis jetzt die Sonar-Geschichte nicht mehr weiter verfolgt, da der Flitzer auch so draussen immer unterwegs ist.

Danke und Grüße
Aiko
 
Das mit den Widerständen hat auch nur geholfen solange ich den Mähmotor noch nicht am laufen hatte. Der muß jetzt erstmal ordentlich entstört werden, und dann hoffe ich gehts auch wieder. Bei den Antriebsmotoren hat es ja auch geholfen.
 
In case anyone has a use for it, I am posting my changes here. Nothing fancy, just a quick and easy fix.

In robot.h, declare variable senSonarTurn:


Code: 
// code version 
#define VER "1.0.2a3-Azurit"
 

// sensors
enum {
  SEN_PERIM_LEFT,        // 0..MAX_PERIMETER
  SEN_PERIM_RIGHT,       // 0..MAX_PERIMETER
...
...
...
  SEN_SONAR_CENTER,      // 0..SONAR_TRIGGER_DISTANCE
  SEN_SONAR_LEFT,        // 0..SONAR_TRIGGER_DISTANCE
  SEN_SONAR_RIGHT,       // 0..SONAR_TRIGGER_DISTANCE
  SEN_BUTTON,            // LOW = pressed
  SEN_IMU,             
  SEN_MOTOR_MOW_RPM,
  SEN_RTC,
  SEN_RAIN,
} senSonarTurn;


In robot.cpp, use a switch construct to run each of the 3 sensors in turns instead of reading all of them in the same iteration, and do it every 80 milliseconds:


Code: 
if ((sonarUse) && (millis() >= nextTimeSonar)){
//    nextTimeSonar = millis() + 500;
//    nextTimeSonar = millis() + 250;
    nextTimeSonar = millis() + 80;

    switch(senSonarTurn) {
      case SEN_SONAR_RIGHT:
        if (sonarRightUse) sonarDistRight = readSensor(SEN_SONAR_RIGHT);
        senSonarTurn = SEN_SONAR_LEFT;
        break;
      case SEN_SONAR_LEFT:
        if (sonarLeftUse) sonarDistLeft = readSensor(SEN_SONAR_LEFT);
        senSonarTurn = SEN_SONAR_CENTER;
        break;
      case SEN_SONAR_CENTER:
        if (sonarCenterUse) sonarDistCenter = readSensor(SEN_SONAR_CENTER);
        senSonarTurn = SEN_SONAR_RIGHT;
        break;
      default:
        senSonarTurn = SEN_SONAR_RIGHT;
        break;
    }

   // if (sonarRightUse) sonarDistRight = readSensor(SEN_SONAR_RIGHT);
   // if (sonarLeftUse) sonarDistLeft = readSensor(SEN_SONAR_LEFT);
   // if (sonarCenterUse) sonarDistCenter = readSensor(SEN_SONAR_CENTER);
 }


Hope it helps.

Manuel
 
Also ich habe das gleiche Problem.

Sobald ich das USB Kabel am Megabord dran habe um in die Variablen zu schauen läuft alles wunderbar.

Lass ich dann Alles (Motoren und Board) über den Akku laufen fährt der Mover rückwärts.

Also kann es doch kaum an den Sensoren liegen. Demzufolge habe ich erst am DC/DC Wandler die Spannung etwas geändet und hatte Teilerfolge, und der Mover fuhr für (ca. ein Stunde) draußen in der Kälte stabil und die Sensoren haben wunderbar funktioniert. Nach dem Ausschalten , einer kleinen Pause von 10 Minuten, und dem Wiedereinschalten ging dann wieder nichts mehr, nur noch rückwärts.

Demzufolge habe ich das Bord vom Hauptakku getrennt und dieses über einen extra Akku 7V Lipo über den Dc/DC Wandler mit ca. 5 Volt Laufen lassen. Und das läuft stabil. Also liegt das Problem doch bei der Spannungsversogung.


Wie bekomme ich denn jetzt das Teil mit nur dem Hauptakku zum laufen? Würde vielleicht mal einen anderen DC/DC Wandler probieren?

MfG LoKO
 
Hallo LoKo,

die US-Sensoren sind nicht unkritisch was Störungen auf der Versorgung angeht. Das liegt schon an der Art und Weise wie die Laufzeiten vom Schall in den Mega kommen. Was hast du den in der PfodAPP eingestellt. Zum Test würde ich hier erstmal sehr niedrige Werte einstellen, auch wenn dann die Sensoren viel zuspät reagieren würden. Einfach um zu sehen ob du es hier mit masiven Störungen auf der Versorgung zu tun hast. Verdrillte Sensorleitungen sind eine weitere Möglichkeit. Auch 100nF Keramik-Kondensatoren mit je einem Elko von 10uF/16V am Versorgungsanschluss der Sensoren können helfen. Ich setze mal voraus, dass die Motoren entstört sind. Am besten ist es natürlich wenn das Protector-Board zum Einsatz kommt, denn das schluckt auch noch mal einiges weg, dass sich sonst im System breit macht (siehe die Workshops dazu).

Da die Sensoren einen Öffnungswinkel von 15 - 22 Grad haben, sind diese im erkennen von Hindernissen oft etwas überfordert. Das passiert dann wenn Hindernisse eine positive oder negative Neigung zum Sensor aufweisen. Was z.B.: bei einer Füllstandsmessung von Vorteil ist, wir bei veränderlichen (durch die Bewegung des Mower) Objekten zum Verhängnis.

Wir arbeiten gerade an einer neuen Lösung hier im Video mal ein kleiner Ausblick.

Gruß

Jürgen

[video]http://https://www.youtube.com/watch?v=C3fT0GGqUOs[/video]

ArduMower-Ultra-Schall-Radar.zip

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/2370/ArduMower-Ultra-Schall-Radar.zip/
 
Zuletzt bearbeitet von einem Moderator:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben