Tips zum Umbau von ferngesteuert auf selbst fahrend für mein Roboter

Der Sinn einer Abschirmung liegt darin, dass sie eben verhindert, dass von aussen Störungen eingespeist werden können.
Wenn die _irgendwo_ unterbrochen ist, funktionierts natürlich dann nicht.
Wenn du das Zündkabel abgeschirmt hattest- hast du die Abschirmung dann auch geerdet (an Masse angeschlossen)?

Hm-man könnt versuchen, das mal zu messen:
Echo-Kabel ab vom Arduino (Trigger kann auch ab, muss aber nicht) und dann den Mäher laufen lassen- OHNE den Sensor messen zu lassen.
Also nichts auf den Trigger geben, und dann mal schauen, was am Echo-Kabel so ankommt, das dürft mit nem einfachen Multimeter schon gehen.

Was du noch gar nicht erwähnt hast: wie genau misst du eigentlich? Ununterbrochen oder nur ab und zu mal? Ich frage das deshalb, weil dein Gerät recht langsam ist, und es sicher keineswegs nötig ist, pausenlos die Umgebung zu beobachten-bei 4m Reichweite hat man Zeit!
Wenn du, sagen wir 1x pro Sekunde misst, könntest du versuchen, die Ergebnisse zu filtern, und so womöglich ziemlich nahe an die Wirklichkeit kommen.
Andere Möglichkeiten gibts schon-aber wohl nicht in den Preisklasssen hier-einige Autohersteller verbauen statt Ultraschall- Radarsensoren. Kostet aber sicherlich dann schon einiges mehr.

Lach nein hab ich natürlich nicht an Masse angeschlossen, hab beides nur mit Alufolie umwickelt.
Ja momentan in meinem Code prüfe ich alle 50 Millisekunden .... was ja aber nicht nötig ist - wie du richtig erwähnt hast!
Also müsste ich dann ins delay von meinem void scan 1000 schreiben? oder meinst du ich sollte nicht ganz eine Sekunde prüfen?

Ich lass den US Sensor e nur mit drei Pins laufen - sprich 5V - GND und SIG.

Was ich mir grade so überlege wo ich neben meinem Roboter sitze - müsste nochmals prüfen ob am Heck meines Roboters der Sensor
einwandfrei arbeitet. Dann währe es doch auch möglich - aus Not mach Tugend ;-) - die Sensoren am Heck zu befestigen, da der US Sensor
nicht nach unten strahlt sondern nur zur Seite. Das würde doch rein theoretisch gehen oder ? mit einer kleinen Brücke, und da dann jetzt
testweise einen und nachher meine drei US Sensoren zu befestigen, das hat bist jetzt auch noch keiner^^

- - - Aktualisiert - - -

also einfach mal getestet ...... wenn ich den Sensor, so anbringe wie ihr auf den Bildern sehen könnt, funktioniert es.
Weil es weiter vom Motor entfernt ist! Der Sensor misst sauber trotz das der Rasenmäher an ist!

Währe das für euch auch eine einfach aber funktionierende Lösung?

Anhang 28838Anhang 28839

also mein Gedanke war wahrscheinlich nicht schlecht, aber ein Denk Fehler von Gottes Gnade -.-

Es hat anfangs funktioniert weil ich den Abstand auf 50cm Entfernung eingestellt hatte, dann hab ich ja den Anstand auf 1.5 Meter eingestellt,
weil mein Roboter ein Meter lang ist. Abstand soll 50cm sein!.
Es hat nicht funktioniert weil der Ultraschall natürlich genau über den Mäher muss und wird somit auch gestört!

Also steh ich wieder am Anfang! Ein gutes hat es ich weis das es ned am Kabel liegen kann weil das garnicht in der Nähe des Mähers ist! Also stört der
Mäher wirklich den Weg des Ultraschalls!

So meine nächste Idee ist euch nochmals zu Fragen was ihr von Infrarot haltet? - Ja ich weis es ist nur punktuell und evtll nicht ganz das praktische.
Ich will euch aber sagen, das ich kein Problem habe von mir aus geschätzte 6 Infrarot Sensoren neben einander und drüber immer zwischen zwei, nochmals
eine Reihe von 5 Infrarot Sensoren zu platzieren! Was haltet ihr von der Idee?

delay() ist böse.
Ganz böse-um nicht zu sagen: das Böse schlechthin.
Wenn du nämlich in deinem Unterprogramm ein delay(1000) einbaust, macht der Controller in dieser ganzen Sekunde-nichts. Gar nichts, ausser warten, dass die Zeit um ist.
Zeitschleifen macht man anders, entweder indem man sich nen Timer programmiert, der ab und zu nen Interrput auslöst (die man zählen kann und damit ne nette Taktbasis hat), oder aber halt simpler, indem man die Millisekunden hochzählt-wie im Beispielprogramm "blink without delay".

Dass dein Sensor weder durch die Blechkiste durch noch drumherum gucken kann, war eigentlich aber klar-oder?
Infrarot ist Mist, weil die nicht viel Reichweite haben. Bei nur einem Meter Reichweite hat dein Mäher keine Chance, rechtzeitig zu stoppen, wenn z.B. ne Katze auf ihn zuläuft!

Aber gut zu wissen, dass es in grösserer Entfernung vom Motor dann doch geht- also ists entweder der Lärm (da kann man z.B. den Auspuff ja nach hinten verlegen) oder eben doch Störungen durch die Zündanlage. Das ist mit ordentlicher Abschirmung in den Griff zu bekommen.

Grins Blechkiste, ist ein Aluminium Rahmen^^

Okay das mit dem Delay hab ich verstanden ....

JA hab gedacht wenn ich den Sensor über dem Roboter anbaue würde es funktionieren. Der US Sensor strahlt nur zur Seite nicht nach unten bzw nur geringfügig!
Nur hab ich nicht dran gedacht das die Zündanlage auch nach oben strahlt!

Ich brauch doch aber ned mehr wie 50 bis 70cm ..... ist das mit dem Infrarot wirklich so schlecht? Weil ich möchte mir jetzt ned nur wegen den Umständen ein anderen
Rasenmäher kaufen!! Bin von den Akku Teilen nicht wirklich überzeugt und den wo ich im Auge hab, is auch ein Benzin Mäher und da wird das gleiche Zündungsproblem sein -.-

Wie meinst du denn das was Sisor ja auch schon geschrieben hat, das dass mit der Zündanlage richtig abzuschirmen kein Problem sei??

Meiner Meinung nach sendet das Mähwerk Ultraschall aus. Schallquelle ist das Metallgehäuse des Mähwerks. Hohe Frequenzen lassen sich leicht bedämpfen, weil sie energiearm sind und sich nicht um Hindernisse hinwegbeugen. Für 40 kHz sollte z.B ein Stück Teppich reichen, dass bündig unter den Mäher gehängt / geklebt wird und bis etwa zum Boden reicht.

Abbildung zeigt nach rechts das Problem und nach links eine mögliche Abhilfe.

also trotz technischer Ausbildung hab ich jetzt nicht verstanden wie du das mit dem Teppich meinst O.O
Unter dem Mäher ist doch das Messer und der Rasen?

- - - Aktualisiert - - -

der Teppich in deiner Darstellung ist aber hinter dem Mäher und der Sensor ist vorne!
Seh ich das richtig?

Zitat:

---

Der Teppich in deiner Darstellung ist aber hinter dem Mäher und der Sensor ist vorne!
Seh ich das richtig?

---

Ja, ich wollte Problem und Lösung in die Zeichnung bringen.
Statt Teppich kannst du natürlich nehmen, was du da hast.

okay also wenn ich das richtig verstehe gehen die Impulse von der Zündung nicht durch Dinge hindurch?

Aber es sind noch die beiden Akkus dazwischen und dann noch eine 5mm dicke Aluplatte auch noch dazwischen? das ist dass was mir so suspekt ist!
Hätte nie gedacht dass man bei Sensoren vor solch Herausforderungen steht, aber genau das is dass was das ganze so Interessant mach und auch mega Spaß macht^^

Gardena ( oder sonstige Hersteller ) Mähroboter kann jeder Kaufen ;-)

Ich meine nur die hohen Frequenzen. Meine Theorie ist, dass das Mähwerk hochfrequenten Lärm macht. Dieser Lärm wird von harten Hindernissen reflektiert. Der US-Sensor sendet auch Schall aus, um dann auf das Echo zu warten. Da aber durch den Lärm ein ständiges Echo empfangen wird, ist eine Messung unmöglich.
Der Lärm des Motors sollte durch dein Fahrzeuggehäuse im Hochfrequenzbereich gedämpft werden, so dass er nicht das Problem sein sollte.
Das unter dem Fahrzeuggehäuse hängende Mähwerk allerdings schon.

Ah okay - jetzt hat es Klick gemacht :)

Dann werd ich morgen versuchen mal eine Trennwand einzubauen.
Das die hohen Frequenzen nicht durch kommen.

Aber dann den US Sensor schon vorne an an der Front platte anbringen oder ?

Werde morgen dann berichten ob die Trennwand was gebracht hat. Komme
Aber erst morgen Nachmittag / Abend dazu es hier im Forum dann zu berichten

Ich hoffe das es funktioniert. Mir gefallen die US Sensoren sehr gut.

Muss nur schauen das ich mit der NEW_Ping Library mehrere US Sensoren
Ansprechen kann. Wie ich aber schon gelesen hab anscheinend kein Problem.
Denke werde 5 bis 6 im Einsatz haben ...

Ein Stück dickere Pappe mit Gaffatape befestigt sollte genug sein.

Hey Benny,

ich denke Du begibst Dich so langsam in Bereiche wo besseres Werkzeug definitiv hilfreich wäre. Ich denke hier speziell an ein Oszilloskop. Das wird Dein spezielles Problem zwar nicht zwangsläufig lösen aber es wird Dir helfen potentielle Fehlerquellen auszuschliessen.
Habe keine Ahnung was Dein tatsächliches Problem ist, aber damit kannst Du
- die Versorgungsspannung und eventuelle Störungen erkennen sowie
- den Output Deines Sensors anschauen.

Und das ist schon ziemlich viel! Die beste Software kann nur tun was sie tun soll wenn die Siganle, welche die Elektronik liefert, auch erwartungsgemäß ankommen. Das kann man in diesem Fall mit *irgendeinem* Oszi sicherstellen.

Denn Deine konkrete Situation ist aus elektronischer Sicht ja eigentlich "traumhaft". Schau Dir Spannungen und Signale mit ausgeschaltetem sowie mit laufendem Motor an und Du wirst wissen in welche Richtung Du weiterforschen mußt!

Ich habe mir vor einiger Zeit den Vorgänger dieses Teils hier geleistet (500E, 100MHz):
http://www.reichelt.de/Oszilloskope-...nr=UTD+2102+CM
Und kann das nur ganzen Herzens weiterempfehlen obwohl es ganz klar ein "verachtenswertes" China-Billig-Produkt mit gewissen Einschränkungen ist. Aber es wird meine Privat-Bedürfnisse sicherlich für die nächsten 10 Jahre befriedigen können und Deine wohl auch.

Für Dein aktuelles Problem wäre aber sicherlich beispielsweise auch dieses Gerät für's halbe Geld (250E, 25MHz) ausreichend:
http://www.reichelt.de/Oszilloskope-...nr=UTD+2025+CL

Das Thema "Welches Oszi" ist sicherlich ein Reizthema und einiger Diskussion wert wenn man semiprofessionelle Ansprüche hat - andere Billig-Oszis (die ich nicht persönlich kenne) werden's in diesem Fall sicherlich genauso tun können.

Wenn Du in dieser Richtung weiterarbeitest (Elektronik-basiert) wirst Du früher oder später aber ohnehin feststellen daß ein Oszi unabdingbar ist und es später bereuen daß Du es nicht früher gekauft hast. Es kann unendlich mehr Probleme als ein Multimeter klar darstellen!

@ Sisor - ich werd es heute testen und dann wieder berichten ...
@ CDK - ja das habe ich mir auch schon überlegt zuzulegen - muss ich mir nochmals überlegen :-)
Danke für die Links und die Erklärung :-)

1234567890

also - ich kann heute mit Freude berichten, das es Wirkung gezeigt hat ein abgeschirmtes Kabel zu verwenden!
Jetzt misst der US Sensor sauber durch, ich habe ja selbst versucht mit Alu Folie das hat aber nicht so geholfen!
Heute war ich in der Stadt da hab ich gleich abgeschirmtes Kabel von meinem Elektroladen meines Vertrauens mit genommen
und ausgetestet - I am Happy :-)

Ich hab auch noch wie Sisor das beschrieben hat, ein Stück dickeren Karton montiert, ich hab jetzt nicht probiert ob es auch ohne geht!
Ich muss nur noch bisschen herum probieren wie er am besten fahren soll, das er dann auch über all hinkommt ....
Das möchte ich aber erst probieren wenn ich die anderen Ultraschall Sensoren verbaut habe.

Dann werde ich mir jetzt noch weitere Ultraschall Sensoren bestellen!
Werde mich jetzt an den Sketch machen, bin guter Dinge das ich dies hinbekomme =)
Ich möchte Statt einem US Sensor - sieben Ultraschall Sensoren verwenden, das heist ich muss
dann so programmieren das sie immer mit einem abstand von vllt 40ms angefragt werden einer nach dem anderen.

Dazu hab ich eine Frage, ich verwende die NEW Ping Library, muss ich das dann so machen wie es hier auf der Seite aufgeführt ist?
oder kann ich das für mich auch einfacher programmieren?

http://playground.arduino.cc/Code/NewPing

Dann würde ich noch gerne 4 Taster integrieren, das wenn sie gedrückt werden, das gleiche passieret wie wenn der Ultraschall Sensor meldet
das die gewünschte Distanz erreicht ist ... sollte ich ebenfalls hin bekommen^^

Danke an CDK und an i_make_it für die Elektro Kenntnisse und die Gerätschaften. Da das Projekt ja noch eine Weile gehen wird - grins - werd ich mir
überlegen solch ein Teil an zu schaffen :D

Nein, du musst es nicht "so" machen-wie im Beispiel.
Zu der Bibliothek gehören mehrere Beispiele-guck sie dir mal an.

Zu dem Karton und dem abgeschirmten Kabel-nimm dir die Zeit und finde raus, ob du das eine oder andere-oder beides-brauchst. Es wird nicht das letzte Mal sein, dass du überrascht bist.

1234567890

@ Rabenauge - das hab ich mir schon gedacht, werde mir die Beispiele anschauen und meinen Sketch dann für meine Anzahl Sensoren so anpassen wie ich es brauche.
Wie ich ja schon beschrieben hab, möchte ich auch noch gerne mit Tastern, Bumper bauen, weil die Sensoren ca 40cm über dem Boden montiert sind, und wenn etwas
unter halb der Sensoren zb ein Stein oder ein Ball oder sonst was auf dem Rasen liegt oder sich befindet, natürlich auch erkannt wird!

Ich werd natürlich weiter hin nach der Ursache schauen, grad was den Karton und die Abschirmung angeht!

Ja, das man vor solch Herausforderungen gestellt wird, is natürlich schon Krass, aber genau das is das was so sau mäßig Spaß macht und die ganze geschichte Interessant macht.
Natürlich kostet das Nerven und Gehirnzellen, aber wenns alles so einfach währe würde es kein Spaß machen :)

Hallo Community,

ich bin wie immer am Sketch schreiben und frage mich welcher Weg zum Ziel führt, bzw Welche Schreibweise Vorteilhafter ist?
Da ich im Netz nicht die Antworten gefunden habe, die meine Fragen beantworten!

Mein Code für einen Sensor mit den Variablen und dem Objekt sah so aus:

Code:

---

#define PING_PIN    12
#define MAX_DISTANCE 100 

NewPing sonar(PING_PIN, PING_PIN, MAX_DISTANCE);

unsigned int time; 
int distance; 
int triggerDistance = 70; 
int frontDistance;

---

Jetzt hab ich aber ja wie besagt 5 solcher Sensoren, erste Frage ist ich hab Beispiele gefunden wo sie die ganzen Trigger Pins zusammen auf ein Pin
geführt haben? und Welche wo 5 Tigger und 5 Echo Pins hatten. Was ist denn der Vorteil wenn man die TriggerPins auf einen Arduino Pin legt?

Wobei aber bei meinem jetzigen Code das so habe das ich 5 Trigger und 5 Echos habe, weil so wie ich es jetzt habe, könnte ich für jeden Einzelnen den
Abstand unterschiedlich eingeben! Das würde mir persönlich besser gefallen!

Code:

---

#define sonar_1(4, 5, 70); // Trigger-Pin / Echo-Pin / Distanz zu Hindernis = EchoPin = SIG Pin
#define sonar_2(6, 7, 70);
#define sonar_3(8, 9, 70);
#define sonar_4(10, 11, 70);
#define sonar_5(12, 13, 70);

#define pingSpeed 100

unsigned long pingTimer1, pingTimer2, pingTimer3, pingTimer4, pingTimer5; // Frequenz in Millisekunden
int distance1, distance2, distance3, distance4, distance5;

---

Woran ich komischer weise immer und immer wieder scheitere ist an der IF Anweisung, also wenns drum geht, wenn das passiert tu dies oder das wenn dann
das nicht ist tu dies ansogst das tun!

Das is immer mein Größtes Problem! Aber wenn ihr mir zu der Frage ne Antwort habt, habt ihr mir schonmal weiter geholfen :-)

Wünsche allen einen schönen Sonntag
Mfg Benny

Man kann die Trigger-Pins zusammen legen-das _kann_ funktionieren.
Vorteil: es spart Pins (grad nen Uno hat ja nicht so üppig viele).
Der Haken: es _kann_ passieren, dass die Sensoren dann das Echo der anderen empfangen-und die Entfernungen nicht stimmen. Bei guter Anordnung gehts, bei ungünstiger nicht.
Ausserdem sollte man aufpassen,dass man den Pin, wenn man viele Trigger an einen hängt, nich überlastet...so ganz ohne bisschen Strom gehn die auch nicht.
Die Echo-Pins sollte man unbedingt getrennt hernehmen, sonst merkt man ja gradenoch "vor irgendeinem der Sensoren könnte was sein"- ziemlich nutzlos.
Man kann die HC-SR04 auch umbauen, dann ist Echo und Trigger auf einem Pin möglich-hab ich aber selber noch nicht ausprobiert.

Zur If-Anweisung: dazu gibts dann auch noch die else(), und die else if() auch kann man if()`s beliebig ineinander verschachteln, und in manchen Fällen fährt man mit switch() besser.

also das mit den #define hab ich hinbekommen, also den Code für meine 5 Sensoren ausgelegt!

Nur geht es wie gesagt im loop Teil um die IF Anweisung:

Code:

---

void loop()
{
  scan_FRONT_MIDDLE();                                  // Abstand Messen
  distance_FRONT_MIDDLE = distance;                      // Distanz Vorne = Abstand
  if(distance_FRONT_MIDDLE < triggerDistance)            // Wenn kleiner als vorgegeben dann reagieren
  {
    backward();                              // Zurück fahren
  }
    else
  {
    vorward();                              // Weiter nach Vorne fahren
  }
}

---

So siehts aus wenn ich ein Sensor hab bzw einmal scan_FRONT_MIDDLE abfrage,
jetzt hab ich aber noch :

void scan_FRONT_RIGHT()
void scan_FRONT_LEFT()
void scan_RIGHT()
void scan-LEFT()

und soll ja so sein das er zb im abstand von 50ms die einzelnen scan´s abfragt ..... so währe es doch richtig oder ?
ein scan nach dem anderen abfragen ?

- - - Aktualisiert - - -

ja also ich habe jetzt in meinem Sketch so gemacht, das ich Trigger und Echo Pins habe, da ich ja ein Mega 2560 mit einem Sensor Shield habe,
stört es mich nicht wenn ich 20 Pins für die 5 Ultraschall Sensoren belege!

Sieht bissel wie nen BASIC-Programm aus. ;)
Macht aber nix.
Ich würd es anders machen:

fahre vor()
{
while(hindernisDa)
{ fahreZurück;
frageSensorenAb();
}
frageSensorenAb();
}
So ähnlich mache ichs beim Monstertruck auch: solange er noch weit genug vom Zielpunkt entfernt ist, wird recht sorglos gefahren, und ab und zu halt die Position überprüft.

Wieso brauchst du eigentlich 20 Pins für 5 Sensoren?? Die brauchen _zweie_ jeder- mehr nicht. Sag bitte nicht, dass du die Dinger auch über den Mega mit Spannung versorgst??

Okay das mit dem Code sieht gut aus ich Versuch mal mein Code zu schreiben.

Nein hab mich falsch ausgedrückt. Mit Strom werden die Sensoren von dem Sensor Shield versorgt.
War ein Denkfehler. Ich brauch dann nur 10 Pins für die 5 Sensoren.

- - - Aktualisiert - - -

also würde der loop Teil dann so aussehen?

Code:

---


void loop()
{
  vorward();
  {
    while(scan_FRONT_MIDDLE)
    distance_FRONT_MIDDLE = distance;
    if(distance_FRONT_MIDDLE < triggerDistance)
    {
      backward();
    } 
    while(scan_FRONT_RIGHT)
    distance_FRONT_RIGHT = distance;
    if(distance_FRONT_RIGHT < triggerDistance)
    {
      backward();
    {
    while(scan_FRONT_LEFT)
    distance_FRONT_LEFT = distance;
    if(distance_FRONT_LEFT < triggerDistance)
    {
      backward();
    }
    while(scan_RIGHT)
    distance_RIGHT = distance;
    if(distance_RIGHT < triggerDistance)
    {
      backward();
    }
    while(scan_LEFT)
    distance_LEFT = distance;
    if(distance_LEFT < triggerDistance)
    {
      backward();
    {
  {
{

---

Benutz das Programm da besser nicht.
while() heisst ungefähr: solange()...damit kann man prima Endlosschleifen basten, und sucht sich dann dämlich am Fehler...
Die while()-Schleife wird _erst_ verlassen, wenn (Ausdruck) hinter While nicht mehr zutrifft!
Du musst dort also schon eine Bedingung definieren, die irgendwann unwahr wird-oder das Programm bleuibt ewig in der Schleife gefangen.

Sowas z.B. nehme ich, wenn ich ein Programm endgültig stoppen will:

while(1)
{ //hier geht nix mehr}
Da die "1" nie falsch werden kann, wird in dieser Schleife ewig geblieben.
Benutze ich z.B. beim Monstertruck, wenn er endgültig gestoppt werden soll:
Wenn der Akku zu leer ist um sicheren Betrieb zu gewährleisten, oder die falsche SD-Karte eingelegt ist (ich hab auf der richtigen ne Art "Schlüssel-Datei", nur wenn die gefunden wird, startet das Ding überhaupt -> kleine Spielerei).
Bei dir müsst es ungefähr so sein:

while(hindernis_da=1)
{
fahre etwas zurück;
gucke_ob_Hindernis_da_ist(); //extrem wichtig, damit hindernis_da auch umgestellt werden kann, musst du in der Schleife deine Sensoren auch abfragen!
if(hindernis_nicht_mehr_da) // der Teil kann genausogut in der Sensorenabfrage erledigt werden
{ hindernis_da=0;}
}

okay, das hab ich mir auch schon gedacht das man bei "while" die schelife beenden muss .... nur wie das dann aussieht das es auch funktioniert ?

in etwa so ?

Code:

---

void loop()
{
  vorward();
  {
    while(scan_FRONT_MIDDLE = 1)
    distance_FRONT_MIDDLE = distance;
    if(distance_FRONT_MIDDLE < triggerDistance)
    {
      backward();
      scan_FRONT_MIDDLE();
    }
      if(distance_FRONT_MIDDLE > triggerDistance)
        {
          vorward();
        }
  }
}

---

Ne-also Programme schreiben musst du wirklich noch üben.
Schau dir die Arduino-Referenzen zu den Befehlen mal genauer an.
Insbesondere ein scan_FRONT_MIDDLE wird wohl kaum, oder gar niemals, überhaupt aufgerufen.
Ausserdem hast du vermutlich da die geschweiften Klammern zum dem while() vergessen, somit wird, wenn while() zutrifft, nur die folgende Zeile aufgerufen- aber vermutlich auch die nicht, wenn du Glück hast, merkts der Compiler und schimpft da schon.

Obendrein ist es immer riskant, ein Unterprogramm in sich selber aufzurufen, wie du das da mit vorward() machst.

Nebenbei: gewöhn dir vernünftige Namen an, _merkbare_!
Deine Sache, ob du deutsche oder englische benutzt aber das Wort vorward gibts im englischen nicht, und im deutschen ebenfalls nicht- sowas liest sich echt grauenhaft. Wenn du vielleicht in ein, zwei Monaten noch mal an das Programm musst, kann dich solcher Murks zum weinen bringen. ;)
Bei mir heissen Unterprogramme einfach so:
fahreVorwaerts();
oder
scanneFront();
Da komm ich auch nach nem Jahr noch drauf, was da gemeint sein könnte...
Das Gleiche gilt auch für Variablen, je eindeutiger, umso besser.

Zitat:

---

vorward();

---

Das kann so nich funktionieren. forward schreibt sich mit f ! :)

Tschuldigung das musste sein. Das Wort hat mich aus dem Bildschirm raus angesprungen... ;)

Das doofe ist-den Compilern ist das völlig Wurst ,bis auf die reservierten Wörter kann man da erfinden, wozu man lustig ist.
Das Hauptproblem haben dann die, die den Sermon mal lesen-und verstehn sollen....

@ Rabenauge

ja ich bin noch dabei dies zu lernen, ich mach das noch ned so lang ;-)

Ich brauch halt immer bissle bis es klappt! Okay ich schau mir das an und versuche es zu ändern!
Aber einfach kann man das mit den Sensoren ned programmieren, ich hab das mit "wihle" noch nicht gemacht !!!!
Ist mein erstes mal ^^

Des weiteren leuchtet mir das an deutsche Namen zu vergeben, auch dieser Rat, ist gut - da hast du recht dann kommt man
nicht durch einander und jemand änderst kommt auch damit klar wenn man mir mal unter die Arme greifen will!

Das war der Code der einwandfrei klappt aber halt mit einem Sensor! ( und auch schon mit Deutschen Namen ;-)

Code:

---

void loop()
{
  scan_VORNE_MITTE();                                            // Abstand Messen
  distance_VORNE_MITTE = distance;                        // Distanz Vorne = Abstand
  if(distance_VORNE_MITTE < triggerDistance)            // Wenn kleiner als vorgegeben dann reagieren
  {
    zurueck();                              // Zurück fahren
  }
    else
  {
    vor();                              // Weiter nach Vorne fahren
  }
}

---

- - - Aktualisiert - - -

Das is es auch verstehe kann ich es nicht einfach so schreiben?
Das er einfach so einen nach dem anderen immer und immer wieder abarbeitet?
Natürlich gehts auch mit "while" und so oder sollte ich es so nicht machen ?
Also würde noch mal das gleiche für scan_VORNE_LINKS, scan_RECHTS und scan_LINKS dazu kommen.

Weil wie soll ich sagen? So verstehe ich es ..... in Distanz_VORNE_MITTE schreibt er den Wert hinein was der Sensor für eine
Distanz im Programm scan_VORNE_MITTE ermittelt und wenn der Wert kleiner ist wie in triggerDistanz soll er zurück fahren, drehen und
wieder vor fahren, so verstehe ich diesen Code.

Code:

---


void loop()
{
  scan_VORNE_MITTE();
  distanz_VORNE_MITTE = distanz;
  if(distanz_VORNE_MITTE < triggerDistanz)
  {
    zurueck();
  }
    else
  {
    vor();
  }

  scan_VORNE_RECHTS();
  distanz_VORNE_RECHTS = distanz;
  if(distanz_VORNE_RECHTS < triggerDistanz)
  {
    zurueck();
  }
    else
  {
    vor();
  }

}

---

Hm-liest sich doch gleich besser auf deutsch oder? scan, distance,triggerdistance....viel verständlicher. :) Nix für ungut-ist wirkllich deine Sache, dem Arduino ists egal.

Was ich mich bei deinem jetztigen Code frage ist, wieso distance() nicht gleich von scan_ zurückgeliefert wird.
Würd das ungefähr so erledigen:

Code:

---

int distance;

void scanVM()

{
distance=sensorWert_; //der muss natürlich ausgelesen werden, wie auch immer du das machst
}

---

..und nun kannst du in der main() einfach distance() auswerten.

An deiner Stelle empfehle ich dir, mach dir mal nen Ablaufplan, so auf Papier (nen wirklich effektives Programm für kenn ich auch nicht), was in deinem Programm wann passieren soll, so mit Ausgaben, Eingaben usw. dann blickst du den Ablauf echt besser.
Und da erkennt man auch schnell, wenn man unbeabsichtigt irgendwelche Dinge verdreht.
Dein Programm ist eher simpel, aber ich habs mir angewöhnt, bei etwas mehr Code alles auszulagern. Dann werden in der Hauptschleife nur noch Unterprograme aufgerufen.

ich hab ja schon vieles in Unterprogrammen ..... bzw Unterprogramme für die Scans und die Fahrbewegungen.
würde es helfen wenn ich mal den ganze Sketch poste?

Code:

---

void scan_VORNE_MITTE()
{
  pingTime_VORNE_MITTE = sonar_FRONT_MIDDLE.ping();          // Variable zum Speichern der Zeit, wie lange das Echo zurück braucht
  distance = pingTime_VORNE_MITTE / US_ROUNDTRIP_CM;          // Zeit in Abstand umrechnen
  if(distance == 0)
  {                                    // Wenn kein Echo zurück kommt,
    distance = 100;                    // den Abstand auf Max setzen
  }
  delay(100);
}

---

Zitat:

---

Zitat von Benny1989

.
würde es helfen wenn ich mal den ganze Sketch poste?

---

Weiss nicht, ob dir das helfen würde-ich hab nicht vor, dein Programm zu schreiben. ;)

Du scheinst ne globale Variable für pingTime_VM zu benutzen _und_ eine für distance.
Das ist bissel Verschwendung, da du diese pingTime ausserhalb des Unterprogramms wohl nie brauchst.
Ich verwende da ne lokale- die kann nach einmaliger Benutzung aus dem Spcuer verschwinden:

Code:

---

void scanneFront() // **************vordere US-Sensoren abfragen******************************
{
  int tempVL = vornLinks.ping();
  vorneLinks= tempVL/US_ROUNDTRIP_CM;
  if(vorneLinks==0)
    {vorneLinks=maxDist;}
  delay(70);
  int tempVR = vornRechts.ping();
  vorneRechts= tempVR/US_ROUNDTRIP_CM;
  if (vorneRechts==0)
    {vorneRechts=maxDist;}
  delay(70);
 }

---

Weiters könntest du noch etwas optimieren, da du ja nur wissen willst "ist da irgendwas"- aber die wirkliche Entfernung scheinbar gar nicht brauchst.
Dann kannst du die Berechnung distance = pingTime_VORNE_MITTE / US_ROUNDTRIP_CM; // Zeit in Abstand umrechnen
wohl auch weg lassen, musst halt _einmal_ gucken, in welchem Wertebereich du arbeiten willst.
Das spart zwar nur Millisekunden, aber über ne Betriebszeit von ner halben Stunde läppert sich das. Ich hab es deshalb drin, weil dynamisch reagiert werden soll: je näher das Hindernis kommt, umso mehr muss reagiert werden, bei Geshwindigkeiten > 10km/h gehts bei 4m Reichweite kaum anders.
Ausserdem habe ich, wie du erkennen kannst, maxDist global definiert- die wird für _alle_ meine Sensoren benutzt.
Dadurch brauch ich nicht für jeden Sensor eine und spare wieder bissel Speicher. Und: wenn ich die Entfernung ändern möchte, ändere ichs einmal, und nicht für jeden Sensor einzeln.
Die Eingrenzung des Bereiches mit
if(distance == 0)
{ // Wenn kein Echo zurück kommt,
distance = 100; // den Abstand auf Max setzen ist tückisch- ich hab da allerdings auch noch keine bessere Lösung gefunden.
Wenn nämlich ein Hindernis plötzlich direkt vor den Sensor gerät (Katze??) ist distance auch 0, und dann geht der Roboter davon aus, dass der Weg frei ist!
Kann man so machen, wenn man ganz sicher ist, dass direkt vor den Sensor nichts kommen kann.
Wie gesagt: ne bessere Lösung hab ich dazu auch noch nicht...

so war es auch nicht gemeint, nur zum besseren Verständnis ...

ist bei mir das pingTime_VORNE_MITTE global und dein int tempVL ist dann lokal ? oder ist vorneLinks deine lokale Variable?
Weil int tempVL muss man ja vor dem loop schreiben und das braucht man ja für jeden Sensor.

Naja gut ich weis auch keine andere Lösung, und diese funktioniert vorerst mal, ich kann das ja bei mir von glabl zu lokal ändern!

Bin mir nur nicht sicher ob mein Loop Teil stimmt, der Compiler meckert nicht, ich hab die einzelnen Scans für jeden Sensor einfach untereinander geschrieben!

Code:

---

void loop()
{
    scan_VORNE_MITTE();
    distanz_VORNE_MITTE = distance;
    if(distanz_VORNE_MITTE < triggerDistanz)
    {
      zurueck();
    }
      else
    {
      vor();
    }
   
    scan_VORNE_RECHTS();
    distanz_VORNE_RECHTS = distance;
    if(distanz_VORNE_RECHTS < triggerDistanz)
    {
      zurueck();
    }
      else
    {
      vor();
    }
   
    scan_VORNE_LINKS();
    distanz_VORNE_LINKS = distance;
    if(distanz_VORNE_LINKS < triggerDistanz)
    {
      zurueck();
    }
      else
    {
      vor();
    }
   
    scan_RECHTS();
    distanz_RECHTS = distance;
    if(distanz_RECHTS < triggerDistanz)
    {
      zurueck();
    }
      else
    {
      vor();
    }
   
    scan_LINKS();
    distanz_LINKS = distance;
    if(distanz_LINKS < triggerDistanz)
    {
      zurueck();
    }
      else
    {
      vor();
    }
}

---

Wenn ich das wie du Lokal mache, verschwindet die Distanz_VORNE_MITTE = distanz.
Und stat if(distant_VORNE_MITTE < triggerDistanz) komt dann if(vorneMitte < triggerDistanz)

Hab ich das richtig verstanden?

1234567890

Du kannst die Sensoren auch direkt nacheinander abfragen, und dann alles verODERn:

if(vorneRechtsWasIst ODER vorneLinksWasIst ODER vorneMittigWasIst)
{ ausweichmanoeverStarten(); }

In ausweichmanoeverStarten() kannst du nun entscheiden, ob du grade zurück willst, oder nach links bzw. rechts ausweichen willst.
Lokal sind bei mir die, die mit tempXYZ, die werden nämlich nur an dieser Stelle mal kurz gebraucht.
Die Werte vorneLinks bzw. vorneRechts aber sind global-die kann ich in anderen Unterprogrammen auch benutzen-um z.B. entsprechend zu reagieren.
Ist ganz einfach: eine Variable gibt es dort, wo sie deklariert wurde: machst du das im Header, hast du sie für sämtliche Tasks dann zur Verfügung. Machst du es- wie ich mit den beiden tempXYZ, im jeweiligen Task, dann "leben" die auch nur dort.
Bei mir schwirren inzwischen wohl an die 100 Variablen (davon nen drittel Long-Variablen) im Programm herum, da macht sowas durchaus Sinn- irgendwann ist der grösste Speicher voll, da spare ich lieber gleich das, was simpel zu sparen geht.

@ i_make_it

da hast du vollkommen recht, darüber hab ich mir auch schon Gedanken gemacht keine Sorge^^

Ich werde sogar wahrscheinlich 4 Taster bzw ein Großen Bumber noch bauen, bzw konstruieren, weil gerade als Notlösung oder wenn ein Stein oder
Lebewesen vor den Roboter kommt, wo aber unterhalb der Sensoren sind oder die Sensoren das zu tiefe Hindernis nicht erkennen, der Roboter trotzdem zurücksetzt !!.
Das ist schon wichtig da hast du auf alle Fälle recht =)

@ Rabenauge

das würde dann so ausschauen:

wenn sensor_vorne_mitte kleiner als 70cm mist ODER sensor_vorne_rechts kleiner als 70cm miss ODER sensor_vorne_links kleiner als 70cm Mist ODER ...... USW
dann fahre zurück drehe nach rechts und fahre weiter so lange vor bis zum Nächsten Hindernis!

Code:

---

void loop()
{
  if(distanz_VORNE_MITTE < triggerDistanz || distanz_VORNE_RECHTS < triggerDistanz ||
  distanz_VORNE_LINKS < triggerDistanz || distanz_RECHTS < triggerDistanz || distanz_LINKS < triggerDistanz)
  {
    zurueck();
  }
    else
  {
    vor();
  }
}

---

Sehe ich das so richtig?

Oder schreibt man:

sensor_vorne_mitte ODER sensor_vorne_rechts ODER sensor_vorne_links ODER .... USW kleiner als 70cm dann mach dies oder das ??
Oder wie ich im Code geschrieben habe nach jedem Sensor die triggerDistanz?

So ungefähr. Da müssen nur noch nen paar Klammern rein, sonst klappt das nicht:

Code:

---

  if((distanz_VORNE_MITTE < triggerDistanz) || (distanz_VORNE_RECHTS < triggerDistanz) ||
  (distanz_VORNE_LINKS < triggerDistanz) || (distanz_RECHTS < triggerDistanz) || (distanz_LINKS < triggerDistanz))

---

Im übrigen würde ich wenigstens unterscheiden: ist vorne rechts was, dann nach links ausweichen, ist links was, dann nach rechts.
Und selbst das gibt noch keine gute Fahrstrategie, immerhin soll ja möglichst alles gemäht werden, also auch möglichst nahe an Hindernissen.
Das ist dann der _wirklich_ schwierige Teil....

Übrigens: was den Bumper angeht, das ist mechanisch recht simpel baubar: ne Art bewegliche Stosstange vorn (bisschen um die Ecken ziehen ggf.), schwingend aufgehängt, und nen Mikrotaster oder 2 dran, fertig.
Die dann ganz knapp über dem Boden. Bei langsam fahrenden Maschinen funktioniert das.

Zitat:

---

So ungefähr. Da müssen nur noch nen paar Klammern rein, sonst klappt das nicht...

---

Die Klammern sind nicht nötig.

Hm-biste da sicher? Ich hatte schon nen paarmal damit Probleme...und eigentlich leuchtet es auch ein, da ja jeweils _nur_ die Ergebnisse der Vergleiche verODERT werden müssen.