Inzwischen hab ich sowas wie ein Fahrprogramm geschrieben.
Und...Probleme.
Im Grunde läuft es so ab: es wird ein Ultraschall-Ping nach vorne gesendet, dann aufs Echo gewartet, und anhand der ermittelten Entfernung festgelegt, was passieren soll: bei mehr als einem Meter Platz Volgas, wird es weniger, geht der XP2 etwas vom Gas, und wenn ein halber Meter unterschritten wird, wird gelenkt.
Eigentlich ganz simpel nur- funktioniert es nicht richtig.
Der Zustand "Vollgas" wurde nie erreicht.
Also hab ich mir mal angeschaut, was denn der vordere US-Sensor so liefert- und der kommt, aus irgendeinem Grund, nicht mehr über etwa 70cm hinaus.
Auch nicht, wenn 5m vor dem Roboter nichts ist.
Da ich absolut keine Erklärung für finden konnte (und irgendwelche Beeinflussungen durch andere Programmteile ausschliessen wollte), hab ich die Sensor-Abfrage-und Auswert-Routine mal in ein separates Programm gepackt, mit dem selben Ergebnis.
Interessant ist: betreib ich den Arduino Nano nur an USB, wird die mögliche Entfernung grösser.
Schalt ich auf Akkubetrieb um ist bei 70 cm Schluss.
Es kann aber kein Problem mit der Stromversorgung sein, denn im Akkubetrieb messe ich an der 5V-Schiene (die auch den US-Sensor versorgt) 4.97V, im USB-Betrieb nur knapp vier.
Es müsste also, wenn die Stromversorgung die Ursache wäre, umgedreht sein.
Nen Gegentest habe ich auch gemacht: der hintere US-Sensor erreicht lässig Werte oberhalb nem Meter.
Der funktioniert also offenbar...die Software für beide kann auch nicht die Ursache sein, denn die ist identisch.
Interessant auch: innerhalb der Distanz, die der vordere schafft, stimmen die Ergebnisse auch.
Aber während eben der hintere auch Entfernungen von mehr als 2m sicher messen kann, ist vorne bei knapp über 70 cm Schluss.
Ich hänge mal die Sensoren-Abfrage an, finde da zwar keinen Fehler (wie gesagt, der hintere wird ganz genauso abgefragt, funktioniert aber richtig), vielleicht findet doch jemand etwas, dass ich übersehen habe:
Code:void pingVorne()// ******************** Vorn nach Hindernissen suchen ************************************** { delay(10); // ggf, alte Echos abklingen lassen digitalWrite(triggerVorne, LOW); delayMicroseconds(2); digitalWrite(triggerVorne, HIGH); //Trigger Impuls 10 µs delayMicroseconds(10); digitalWrite(triggerVorne, LOW); //Messung starten long laufZeit = pulseIn(echoVorne, HIGH,maxEntfernung); // Echo-Zeit messen, aber nicht zu lange warten float messung=laufZeit/ 58.2; //Laufzeit in cm umrechnen entfernungVorne = ((entfernungVorneAlt*0.2)+(messung*0.8)); // Ergebnis glätten if(entfernungVorne==0) // das gibts nicht, also muss die Bahn frei sein { entfernungVorne=120; } entfernungVorneAlt=entfernungVorne; }
Die Variable maxEntfernung ist ne globale, die sorgt dafür, dass der Eingang nicht die volle Sekunde wartet, was bei pulseIn() normalerweise der Fall wäre.
Die kann auch nicht die Ursache sein (damit _könnte_ man die mögliche Entfernung einschränken)- aber der hintere benutzt die auch.
Der einzige Unterschied liegt in den Pins: der vordere hängt an A0 und A1, während der hintere digitale Pins nutzt.
Aber die sind natürlich ordentlich als Ein- bzw. Ausgang definiert.
Hat jemand ne Idee?
Zitieren
Zitat von Rabenauge
Lesezeichen