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

[Benny1989]

Hallo liebe Community,

Es geht um meinen Roboter RSL-7 wo ich mich seit langem grübeln nun doch entschieden hab, die Steuerung Umzubauen! BZW zu erweitern.
Ich wollte mein Roboter immer selbst steuern und das sollte nun auch so bleiben, aber wie gesagt würde ich ihn gerne um den Automatismus erweitern!

28696286972869828699

Also sprich von Hand aus der Garage zur Wiese fahren, um die Bäume herum mähen die auf meiner Wiese stehen (am Rand außen herum ) und anschließend wenn dann in der Wiese
nur noch ein Rechteck steht, das dann mit Hilfe einer Induktionsschleife automatisch ab zu mähen.

Hier mal ein Bild, weil ein Bild sagt mehr wie 1000 Worte =)

28695

Wie ihr seht, in der Wiese steht nicht ein Baum, es ist eben und keinerlei Hindernisse.

Kurz zur Elektrik, das ihr euch ein besseres Bild machen Könnt, in der Schaltzentrale am Heck des Roboters, Arbeitet ein Arduino Uno der die Signale die er aus meiner Fernsteuerung bekommt
( ebenfalls ein Arduino Uno fungiert als Sender ) und an einen Modellbau Fahrtenregler aus der Panzerscene weiterleitet.

Hintergrund ist der das ich aus dem Bereich Modellbau komme und ich mich langsam in die Elektrik und Microcontroller Scene einarbeite.
Ich hab den Fahrtenregler deshalb ausgesucht weil ich damals keinen gescheiten Motortreiber gefunden hab, der meine beiden 750 Watt Elektromotoren ansteuert kann.
Noch ein Pluspunkt für den Fahrtenregler ( Fa. SGS Electronic Modell TVC-B-100 ) das ich mir die H Brücke sparen kann zu programmieren da er das alles schon beinhaltet!

Wenn Bilder davon haben wollt weil ich aktuell grad keine zur Hand hab, einfach sagen, dann stell ich welche ein =)


Nun meine Frage an euch!

Habt ihr mir da ein Paar Tips oder Links wo ich mich einlesen kann, muss man den Code selbst schreiben? oder gibt es was wo man sich anpassen kann?
Ich möchte am Anfang auch was recht einfaches haben, Ohne GPS und ohne Giro Kreisel oder was es da alles so gibt, ein wenig hab ich mich schon informiert!
Das Prinzip soll ganz einfach sein, eine rechteckige Induktionsschleife und am Roboter vorn einen Empfänger mit Spulen. Er soll das Feld dann selbstständig ab mähen,
aber zum Beispiel soll immer Vorwärts fahren und nicht vorwärts an die Induktionsschleife und dann Rückwärts weiter fahren, das möchte ich nicht!
Evtll noch ein Druck Schalter das wenn er gegen etwas Fährt natürlich anhält oder ausweicht, weil aktuell wiegt der RSL-7 135KG, also kein Leichtgewicht, ich bin zwar gut Versichert
aber ein Personen Schaden möchte ich natürlich vermeiden =)

Ich hätte auch kein Problem, noch ein Arduino in meine Schaltzentrale zu bauen, so das ich ihn in die Wiese fahren kann, die eine Schaltung so zu sagen abschalte und den anderen Arduino
starte, es gibt bestimmt eine Möglichkeit das alles in einen Arduino Code zu basteln, aber liebe Leuz ich bin Anfänger / Fortgeschrittener und kein Profi -.-
Wenn ich zwei Schaltungen mit zwei Arduinos so zu sagen dann habe, stellt sich mir nur die Frage wie ich die beide an mein Fahrtenregler anschließe evtll mit einem Relais ?

Also ein Paar Tipps und Anregungen oder ein Link zu euren Projekten währe Mega Cool =)

Mfg Benny

[Rabenauge]

Klar wirste das selber programmieren müssen....wer sonst? ;)
Fertig wirds da nichts geben, weil du ja nun nicht gerade ein Teil hast, was viele auch so haben, also setz dich hin und mach.
Wie man das mit ner Induktionsschleife machen _kann_, steht irgendwo bei RN-Wissen, wenn ich mich recht entsinne.
Das Rangierverhalten, was du dir wünschst, musst du dir halt dann auch programmieren...

Zum Testen empfehle ich übrigens dann doch etwas leichteres- was zum Geier hast du da zusammengebaut? Ich kenn Rasentrecker, die leichter sind...

[Benny1989]

Guten Morgen,

ein Roboter der nichts aufhält - grins.
Spaß bei Seite, gibt Leute die bauen kleine leichte Roboter - gibt andere die die anderen Kalieber ;)

Das ich das selbst Programmieren muss ist klar, nur stelle ich mir das garnicht so einfach vor -.-
Mit den ganzen Algorithmen, wie er fahren soll, unter welchem Winkel usw usw.

Also einfach Sachen kann ich schon programmieren, aber sowas da hörte auf -.-

Das mit der Induktionsschleife vielleicht noch okay - aber die Funktionsweise wie man sowas Programmiert
müsste doch irgendwo stehen? Und Tips oder Erfahrungen was andere schon gemacht haben auf was man achten
sollte, müsste doch irgendwo stehen :)

MfG Benny

[shedepe]

Mach dir eine Aufstellung was du aus Sicht des Roboters alles für Informationen hast. Was der Roboter mit diesen Informationen anfangen soll und überlege dir doch einfach mal eine einfache Vorgehensweise wie du dein Problem algorithmisch lösen könntest.
Über konkrete Ideen lässt sich viel einfacher diskutieren, als wenn man dir jetzt verschiedene allgemeine Ansätze an den Kopf werfen würde.

PS. Ich glaube wenn du zumindest noch einen elektronischen Kompass drauf packen würdest, wäre die Aufgabe schon viel einfacher lösbar

[Benny1989]

shedepe, das is doch mal ein guter Ansatz, hab ich noch garnicht dran gedacht, weil wie gesagt die ganze Algorithmus Geschichte absolutes Neuland ist.

Also was ich mir vorstelle was der Roboter machen soll:

- Systematisches abmähen der Induktionsschleife ist klar, im Zufallsprinzip ist wahrscheinlich einfacher als erstmal die Induktionsschleife einmal umfahren und dann systematisch Bahn für Bahn mit 6cm überlappung abzuräumen.
Da dies aber gleich in die GPS und Kreisel / Gyro Region geht, wollen wir es nicht gleich über treiben =) Wobei mir das ehrlich gesagt lieber währe, der Saugrobi von Vorwerk meiner Oma kann dies ja auch^^
- Dann mit Hilfe eines oder mehreren Ultraschallsensoren ( HC-SR04 ) ein Hindernis umfahren, bzw Stoppen und Zurücksetzten ( Wenn jemand in den Mähbereich des Roboters gelangt )
- Zum Mähprinzip stelle ich mir so vor das er immer Vorwärts mäht, also an die Induktionsschleife kommt - zurücksetzt - und nach links oder rechts wegdreht und Vorwärts weiter mäht
- Wie du schon gesagt hast ein Kompass währe ned schlecht das wenn er beim mähen etwas abdriftet leicht nach korrigiert.


Das währe schon das was ich mir für den Einstieg / Anfang vorstellen würde, nur das jetzt alles in ein Algorithmus zu packen ....... -.- >.< *__*

Was meint ihr sind die Ansätze um zu setzen? Wie gesagt vorerst mal ohne Spielereien wie irgendwelche Sensoren auslesen und an die
Fernbedienung schicken oder sonstige Spielereien.

[shedepe]

Also um eine Mikrocontroller steuern wirst du wohl nicht drumherum kommen. Ein einfacher Algorithmus wäre doch z.B. Starte in der rechten untere. Fahre solange bis du vorne die Induktionsschleife findest. Dann fahre rückwärts und lenke so dass ins Feld reinkommst. Dann fahre geradeaus bis du hinten die Induktionsschleife findest und mache das ganze noch mal. Gezieltes wenden ist ohne weitere Sensorik nahezu unmöglich.

[Benny1989]

also ich hab ja schon ein arduino uno verbaut, hab genug platz für weitere weil ich ja die Fernsteuerungstechnik beibehalten weil, weil mit dem Roboter nicht nur Rasen gemäht wird.

Okay leuchtet ein, dann komm ich natürlich um die Sensorik nicht herum, denn mein Roboter is so konstruiert nur für Vorwärts rasen mähen!

Nur die ich den Code anpacke und Was für Sensoren und wie ich die zusammen setzte is mir noch ein Rätsel

[shedepe]

Da solltest du dich nunmal informieren was es für Sensoren gibt und welche Daten diese dir liefern. Dann kommt als nächstes die Recherche wie man diese Sensorik mit einem Mikrocontroller ausliest. Wenn das klappt (sowie die motor ansteuerung) kannst du ja einfach mal etwas rumprobieren.

[Benny1989]

ja, wie nennt sich denn der sensor für die induktionsschleife? dann haben wir noch den Ultraschallsensor und brauche ich auch noch einen Kompass?

Mein Roboter wird ganz normal angesteuert wie zwei Servos, zwecks dem Modellbaufahrtenregler! Also wie zwei normale Servos!

Einfach mal etwas rumprobieren is gut :P grins, hab mir mal ein paar Algorithmen im Internet angeschaut, ich versteh nur Bahnhof -.-

[Rabenauge]

Genau so.
Grobe Planung (was brauche ich mindestens-da kommste halt nunmal nicht drumherum), und dann eine Strategie überlegen: welche Informationen kann ich so gewinnen und was kann man damit anfangen.
Nen Ultraschallsensor vorne rantackern, und damit mehr oder weniger effizient Hindernissen ausweichen ist ein Anfang-aus Erfahrung würd ich allerdings da gleich zweie nehmen, da man mit einem keine vernünftige Ausweichstrategie entwickeln kann (wenn er starr montiert ist), sondern nur merkt: irgendwo da vorne muss was sein....
GPS ist so eine Sache-meine ersten Tests gestern haben relativ klar ergeben: alleine für genaues fahren nicht zu gebrauchen.
Da schafft man Genauigkeiten von 5-10m, das ist was, aber für deine Aufgabe dort viel zu ungenau. Da brauchst du also ne "zweite" Meinung...
Ich möglicherweise auch..:(
Bau die Induktionsschleife, und wenn _das_ läuft (der Mäher den Bereich unter keinen Umständen mehr verlässt), konzentriere dich erst auf die Hinderniserkennung und entsprechende Ausweichstrategien. Damit hast du schon ne Weile zu tun und ja: geht auch umgedreht-erst ausweichen, dann im Käfig bleiben...

[Benny1989]

Okay wie ich ne Iduktionsschleife baue bekomm ich raus bzw, hab ich schon Ansätze gefunden. ja natürlich meinte ich mehrere, ich dachte sogar an 4. Denn mein Roboter is 600mm Breit uns 1250mm Lang, Dachte Zwei Vorn
und einer Links vorne der nach etwas mehr nach Links schaut und das gleiche auf der anderen Seite. Ja das mit dem GPS kenne ich z.b. vom Smartphone - das is ja auch nur auf 3 bis 7 Meter genau!

Da währe ne Alternative zum GPS natürlich nicht schlecht =)

Habe mir gerade im CAD ein Bild erstellt wo ich mal einzeichne wo ich mir die Sensoren vorstelle.
Das man mal was hat zum diskutieren .....

Gäbe es auch die Möglichkeit die Induktionsschleife, von Namhaften Herstellern zu kaufen?
Also von den Kaufgeräten der Mähroboter? oder besteht da ein Unterschied ?

- - - Aktualisiert - - -

Hier mal das Bild,

das rote stellen die Bereiche der 4 Ultraschallsensoren da ...
die blauen Kreise die Sensoren für die Induktionsschleife ...

Also ich denke mindestens Zwei für die Induktionsschleife und mindestens zwei eher drei für den Ultraschall

28707

[Rabenauge]

Das "schräg gucken" kannst du mit preiswerteren (vermutlich mit besseren ebenfalls) US-Sensoren vergessen.
Das ist ein Sonar: die Dinger schicken nen Ultraschallton los, und messen dann die Zeit, bis das Echo eintrifft. Wenn diese Töne aber in spitzem Winkel z.B. auf ne Wand treffen, werden sie zwar reflektiert, aber nich zum Sensor zurück- er merkt dann nix.
Zweie schräg nach vorn (so dass sich in der Mitte die Bereiche grade knapp überlappen, um nen möglichst breiten Bereich zu erfassen) funktionieren ganz gut, und du hast dann die Möglichkeit festzustellen: ist gradeaus was oder eher links oder eher rechts.
Seitlich musst du halt probieren, am Monstertruck habe ich da nur je einen, aber zusätzlich noch nen schwenkbaren IR-Sensor hinten, der _auch_ nach den Seiten gucken kann.
Du hast doch eh Arduinos rumschwirren, dann besorg dir mal ne Tüte von den Teilen und teste bisschen, vier Stück sollte nen UNO schon bedienen können, wenn man bisschen bastelt, sogar weit mehr (man kann z.B _manchmal_ mehrere Triggerpins zusammenfassen oder auch die Sensoren so umbauen, dass sie nur noch einen Pin für Trig und Echo brauchen).
Ich bin da selber bisschen am rumprobieren, zumal die Ansteuerung- mit pulseIn wirds bei mehreren total lahm, die (angeblich supertolle") newPing-Bibliothek hat auch ihre zicken...
Und: ich hoffe, dein Monstrum ist nicht allzu schnell? Outdoor sind nämlich die 4m (mit Glück werdens 5) nicht so besonders viel...

[Benny1989]

also zum Testen würd ich mal zwei nehmen! ja hab en Uno im Roboter verbaut aber wie gesagt die Intakte Roboter Steuerung möchte ich so lassen!

Ich hab grad mal ein Einkaufsliste gemacht was ich mir besorgen will, werd mir auf jeden Fall für diesen Algorithmus nen Arduino Mega holen, hat mehr Pins
und hat en Memory von 256KB, denke er ist besser geeignet als der UNO.

Aber wie ich das rausgehört habe, kann ich aber z.B.: schon ein HC-SR04 nehmen oder ? oder ist dieser Sensor nicht so geeignet?

Dann bin ich grade am Code rum programmieren, -.- , sensor auslesen is kein problem, servo 360 immer in eine Richtung drehen lassen auch nicht!
Nur jetzt kommst, wenn der Sensor weniger wie (zb) 20 oder 10 cm misst dem Servo sagen STOP - 280 Grad rumdrehen und dann weiter fahren / drehen.

Die Geschwindigkeit meines Roboters kann ich ganz fein regeln, ich habe damals nicht an den Elektromotoren gespart - sonst kauft man zwei mal^^
Haben jeweils 750W - mit enormer Getriebe Untersetzung und in meinem Roboter is es nochmal 3:1 Untersetzt.

Mal zum Vorstellen, ich hab mit meinem Roboter mein A3 BJ2002 Facelift (1280KG Leer ) auf unserem Firmengelände gezogen - hat einwandfrei Funktioniert =)
Des weiteren haben sie solch eine Kraft, das wenn das Gras zu hoch ist, mein 3,2 PS starken Benzin näher ab zu würgen =)

[Benny1989]

Neustes Update^^

hab das Wochenende mit verbracht bissle an einem Sketch zu arbeiten - bin noch ned ganz zu frieden aber für anfängerische Möglichkeiten
recht einfach gehalten der Sketch.

Habe jetzt experimentiert mit einem Arduino Mega + Motor Shield von Arduino und zwei Infrarotsensoren ( Sharp GP2Y0A21YK0F )

Ich muss dann nur wieder schauen wie ich den Code von Motor zu Servo umschreibe, bzw vllt geht es auch als Motor geschrieben.
Wegen meinem Fahrtenregler, bin der Meinung der reagiert besser wenn man ihn als Servo anspricht, weil er bei jedem einschalten die 0 Stellung
abfragt. Deswegen wird als Servo besser sein!

Hier hab ich euch mal zwei Bilder dazu:

2873628737

Hier mal mein Code - aber ned auf mich einhacken was alles falsch und richtig ist -
ist einfach gehalten und so programmiert wie ich damit klar komm.
Ist aber Noch ned ganz fertig :-/


int sensor_Rechts = A3; // Sharp IR Sensor an Pin A1
int sensor_Links = A4; // Sharp IR Sensor an Pin A2
int pwma = 3; // PWM Pin für MOTOR Rechts
int pwmb = 11; // PWM Pin für MOTOR Links
int motora = 12; // Direction Control für Motor Rechts
int motorb = 13; // Direction Control für Motor Links
int sensorRechts;
int sensorLinks;


void setup()
{
pinMode(sensor_Rechts,INPUT);
pinMode(sensor_Links,INPUT);
pinMode(pwma,OUTPUT);
pinMode(pwmb,OUTPUT);
pinMode(motora,OUTPUT);
pinMode(motorb,OUTPUT);
digitalWrite(pwma,HIGH); //This allows the motors to run at full speeds
digitalWrite(pwmb,HIGH); //This allows the motors to run at full speeds
}



void loop()
{
vorward();

sensorRechts = digitalRead(sensor_Rechts);
if(sensorRechts==HIGH) // Wenn Hindernis erkannt wird
{
right();
}

// ---------

sensorLinks = digitalRead(sensor_Links);
if(sensorLinks==HIGH) // Wenn Hindernis erkannt wird
{
right();
}
}

// pwmb motor rechts / pwma motor links
// motora LOW = Vorwärts / motora HIGH = Rückwärts

void vorward()
{
digitalWrite(motora, LOW);
digitalWrite(motorb, LOW);
analogWrite(pwma, 220);
analogWrite(pwmb, 220);
}

void backward()
{
digitalWrite(motora, HIGH);
digitalWrite(motorb, HIGH);
analogWrite(pwma, 220);
analogWrite(pwmb, 220);
}

void right()
{
digitalWrite(motora, LOW);
digitalWrite(motorb, LOW);
analogWrite(pwma, 160);
analogWrite(pwmb, 0);
}

void left()
{
digitalWrite(motora, LOW);
digitalWrite(motorb, LOW);
analogWrite(pwma, 0);
analogWrite(pwmb, 160);
}

Bekomm es noch ned ganz hin das wenn der Sharp - LOW- sendet also - ein Hindernis erkennt, das er dann zuerst
3 Sekunden lang Rückwärts fährt und dann Rechts fährt und anschließend wieder Vorwärts fährt.

Hab mich jetzt mal entschlossen, mein großen Roboter auf entweder 4 Ultraschall Sensoren oder 4 Infrarotsensoren auszustatten
und einfach wenn er ein Hindernis erkennt, zurücksetzt, sich nach rechts dreht ( also bisschen mehr wie 90 Grad muss ich noch
schauen dann wie viel Sekunden das sind und dann im Sketch eintragen ) und dann wieder Vorwärts weiter fährt!

[Rabenauge]

Wirst du auch nicht.
Erstens: die dinger haben nen Erfassungsbereich von 80cm. Damit wirste draussen nicht weit kommen...
Zweitens: dieser Sensor gibt nicht "low" oder "high" aus-sondern ne analoge Spannung, die mit der Entfernung abnimmt.
Die musst du messen, dann die Messkurve (leider ist das Ausgangssignal nicht linear zur Entfernung) programmieren und _dann_ kannst du ne Entfernung ermitteln.
Theoretisch gehts aber rein digital: ab ca. nem Meter gibt der Sensor "irgendwas" aus, was messbar ist.
Mit digitalRead aber wird das nix: die Schwelle dafür, wann ein Eingang als "High" erkannt wird, dürfte oberhalb 2.5V liegen und die gibt der Sharp erst unterhalb 10cm aus.
Also: lies das Ding so ein, wie es sich gehört: analog.
Dann kannst du testen, bei welcher Entfernung welches Signal am Analogeingang gemessen wird, und nimmst dann deine Wunschentfernung als "High" ins Programm.
Und nochwas: so, wie du diese Sensoren montiert hast, wirst du viele Hindernisse übersehen. eine der Stärken dieser Sharp`s ist es, nur nen sehr schmalen Bereich zu erfassen. Die kriegen alles mit, wenns vor ihnen auftaucht, aber bei 10Grad seitlich-gar nix mehr.

Motor-und Servoansteuerung sind im übrigen zwei ziemlich verschiedene Dinge-du kannst nen Motor _nicht_ so ansprechen wie ein Servo.

[Benny1989]

Hallo Rabenauge,

meinst du 80cm reichen nicht? Es würde doch reichen wenn er 10 bis 20cm das Hindernis erkennt oder ? wie gesagt ich bin am Anfang in die Materie einzusteigen! Ich hab meine Roboter bis jetzt auch immer selbst gesteuert!
Also mit Sensoren und was es sonst noch so gibt natürlich auch keine Erfahrung. Hardware wie Software !

Also wenn ich es richtig verstanden habe - sind die Infrarot Sensoren nicht geeignet! Sprich ich benötige Ultraschallsensoren hab ich das richtig verstanden?

Ja die Anordnung auf einem Test Roboter ist wie gesagt nur zum testen, an meinem Großen Roboter würde ich je nach dem 3 Stück vorn, und jeweils einer , zur Seite, so ca. 45 Grad ausgerichtet, Mein Roboter ist 500mm Breit!

Ist für den Ausseneinsatz der Ultraschalsensor HC-SR04 geeignet ? oder gibt es da bessere Modelle? bei mein Lieblings Online Shop hab ich diesen hier gefunden!

http://www.exp-tech.de/Sensoren/SeeedStudio-GroveSeeedstudio-Grove-Ultraschall-Entfernungssensor.html

Diesen hier kann man gut mit M3 Schrauben befestigen und er hat eine Buchse für die Kabel, der würde mir sehr gut gefallen!
Passt auch preislich wenn ich 5 oder 6 davon benötige!

Vllt kannst du / ihr mir einen anderen Bewerten empfehlen! wo es auch Sketche dafür gibt! und vllt kannst du mir nochmal erklären für was
es wichtig ist das der Roboter - das Hindernis früh erkennt? Logisch währe jetzt das man so programmieren kann das er es um fährt!

Jetzt nochmal zum Code!
Das zwischen Servo und Motor ein großer unterschied ist ist klar - Dann werd ich mein Code mal versuchen umzuschreiben! auf zwei Servos und ein
Ultraschall Sensor!

Mein Fahrtenregler handhabt sich wie zwei Servus, er hat zwei Servokabel, eins für die Lenkung und eins Für Vor und Zurück, den V Mischer hat er schon
integriert!

Zum Code versuch ich mal zu schreiben:

Immer Vorwärts fahren - Wenn Hindernis erkannt dann gerade zurück ein stück - Drehung nach rechts oder Links und dann weiter gerade aus!

Ich kann wirklich mal einfach anfangen ohne, Sensor bezogen, sprich das er ned schaut ob links oder rechts von ihm platz ist zum wenden,
denn da wo ich es teste ob auch die Hardware funktioniert, gibt es keine Hindernisse.

Meine Frage ist nur - Wie ich ein Servo Vor und Zurück drehen lass, also für Vorwärts und Rückwärts. Muss ich so tun als würde ich zwei 360 Grad
Servos programmieren.

Sonst hatte ich immer einen Poti wo ich ausgelesen hab und an den Servo geschickt habe!

Mfg Benny

[Rabenauge]

Das Ding fängt bei 80cm grade erst an- auf 85cm ist der praktisch blind!
Ob das wirklich reicht, musst du selber entscheiden, aber bedenke, dass es auch möglich ist, das "Hindernis" kommt ihm entgegen-wie schnell läuft ein Mensch?
80 cm sind da nix.

Diese IR-Sensoren, erfassen, wie ich dir schon sagte, einen sehr schmalen Bereich-weiss es nicht mehr aus dem Kopf, aber mein NiboBee hat sich damit nen Weg durch aufgestellte Bleistifte gesucht-heisst, er hat auch die Zwischenräume gefunden! Das klappt nur, wenn der Sensor so schmalbandig misst, dass er so dünne Sachen einwandfrei erkennen kann-mit nem US-Sensor wäre _das_ unmöglich.

Für dich, wo du eher nen breiteren Bereich, dafür nur "grob" erfassen willst, sind US-Sensoren eindeutig die bessere Wahl- ob nun HC-SR 04 oder die von dir vorgeschlagenen- eher ne Preisfrage. Für das, was von deinen einer kostet, krieg ich nen Dutzend HC-Sr04 und: die tun es.
Aber die bessere Montagemöglichkeit hat natürlich auch was- der Stecker ist witzlos (die HC-SR04 haben den auch, nur ohne Gehäuse drum), aber die Schraubbefestigungen gefallen mir. Die 04er haben winzige Löcher-da passt nicht mal M2 durch. :(
Da du ne robuste Lösung benutzen solltest, wahrscheinlich besser.
Effektiv wirst du, wenn die Sensoren starr montiert sind, so viele brauchen, dass der gesamte nötige Bereich (vorm Fahrzeug) komplett abgedeckt ist. Da hilft nur ausprobieren, fürchte ich.


Und: vergiss doch endlich mal "fertige Sketche"- die gibt es nicht!
Jeder baut was anderes-wenn du Glück hast, bekommst du für irgendeine Hardware ne brauchbare Bibliothek-inzwischen versuche ich, auch das möglichst zu umgehen.
Die meisten Bibliotheken (oder sagen wir einfach: viele..) haben nämlich so ihre Macken.

So. Du steuerst also deine Motoren über nen Servocontroller an, der zudem nen Mixer integriert hat- Murks vom Feinsten, auf so eine Idee muss einer erstmal kommen-Kompliment. ;)
Aber: macht nix-wenns funktioniert!
Dann hast du es ja wirklich leicht-keine Ahnung, was der Mischer genau macht, aber im Grunde brauchste dann ja nur die Microsekunden auf die Leitungen schicken. Einmal die für die Geschwindigkeit (dürfte irgendwo zwischen 1000µS und 2000µs sein (1500 ist dann standardmässig Stop), und gelenkt wird mit der anderen Leitung-genauso.
Die Werte können allerdings ein bisschen schwanken-musst du ausprobieren, einfach mal ein Sero anstecken (damit du siehst, was wirklich passiert).
Wie man Servos ansteuert, da findest du unter den Beispielprogrammen einiges zu.

[Benny1989]

okay dann werde ich das mal testen, wieviel US Sensoren ich benötige, da könntest du recht haben. Das bekomme ich nur durchs testen raus!
Der HC-SR04 ist zwar günstiger aber wie du auch gesehen hast, das die Anschraubmöglichkeiten wesentlich besser sind!

Dann zu dem Fahrtenregler, das is alles andere als Schiet glaub mir - das Teil is jeden Cent wert! davon abgesehen das es wahrscheinlich gar keine
reine H-Brücke gibt die 2x 100A dauerhaft verträgt, hab ich auf den zurück gegriffen, zumal ich ja mein Roboter ganz normal herkömmlich wie ein
Modellbau Panzer mit einer Fernsteuerung gesteuert habe. Ich kann den integrierten Mischer auch ausschalten das soll nicht das Problem sein!
Vllt kann man das auch selber bauen und zusammen löten, aber dazu fehlt mir die nötige Kenntnis!

Ich will das selbst steuern ja auch beibehalten, weil wie gesagt bei mir sind die Dimensionen ein wenig anderst, ich kann nicht her gehen und mein
Roboter einfach auf die Wiese oder den Rasen setzten, wir sprechen immer hin von 125 KG. Deswegen sollte er von Hand fahr bar bleiben,
ist auch viel zu schade für das was ich schon in den Code gesteckt hab bis es funktioniert hat!

Zu dem Code - sorry wenns falsch rüber gekommen ist aber ich suche nichts fertiges !! Ich habe nur gemeint wie du auch geschrieben hast!
Das ich nach Beispielprogrammen suchen werde - Ich bekomme hin mit einem US Sensor, wenn ich aber evtll 5 habe, da werd ich evtll etwas Hilfe brauchen!

Danke für deine Ganze Tips, ich werde mal schauen nach den US Sensor von Seeedstudio, da werd ich mir mal zwei bestellen zum testen!

[Rabenauge]

Zu den US-Sensoren gibts eine Bibliothek, die wohl bis zu 15 Stück (oder gar noch mehr? ) handlen kann.
Such mal nach der NewPing-Library. Momentan hab ich die auch auf meinem Roboter an Bord-weiss aber noch nicht genau, ob ich sie behalten werd-auch die hat nen paar Macken, die mir nicht gefallen. Sie bietet aber z.B. die Möglichkeit, Interrupts auszulösen, wenn etwas in den festgelegten Bereich kommt- kann nützlich sein. Übrigens: auch für die HC-SR04 gibts spezielle Halterungen aus Plastik und Alu...

Was deine Fahrsteuerung angeht: die Modellbau-Regler sind, je nach Ausführung (auch da gibts Mist) schon gut-das stell ich nicht in Frage. Murks ist der zusätzliche Mischer. Den brauchste nämlich bei einer Panzersteuerung absolut nicht, da du ja ganz normal jeden Motor einzeln ansteuern kannst- und somit ohne Mischer ganz problemlos rangieren (und vermutlich deutlich besser, da du nie genau weisst, was der Mischer da zusammeninterpretiert).
Du brauchst also nicht mal mehr Leitungen...

Zu den meisten Sensoren gibt es übrigens Datenblätter-oft ist da auch der Erfassungswinkel erwähnt, teilweise skizziert, beim HC-SR04 sieht das ungefähr (die Dinger sind nicht umsonst so billig, bisschen Streuung ist da schon) so aus: http://farm9.staticflickr.com/8447/7886931546_f26470deb2.jpg
Du siehst: er hat nen recht breiten Erfassungsbereich, ist für dich also geeigneter.
Wenn man nur einen schmalen Bereich erfassen kann (wie mit den Sharps), muss man den Sensor beispielsweise dauernd hin-und herschwenken, um die nötige Breite abzudecken. Der Vorteil ist: enge Lücken kann man damit gut vermessen, aber es ist natürlich deutlich aufwendiger zu programmieren.
Beim Monstertruck habe ich zwei US-Sensoren schräg nach vorne gerichtet (so dass ich feststellen kann: Hindernis eher links oder eher rechts), zwei an den Seiten (da die Teile bei spitzem Winkel zum Hindernis nicht wirklich funktionieren), so kann ich z.B. auch an Hindernissen entlang fahren, und im Heck habe ich nen Sharp-auf einem Servo zum schwenken.
Damit kann ich dann, wenn der Roboter z.B. in eine enge Lücke gefahren ist, hinter dem Fahrzeug genau vermessen, wie ich wieder rausrangieren kann.
Wäre in deinem Fall allerdings wohl übertrieben, wenn du auch nach hinten zwei oder drei (ich weiss nicht, ob du die Breite deines Ungetüms mit zweien abdecken kannst, das musst du einfach versuchen) starre US-Sensoren montierst, müsste das evtl. genügen.

Sowas kann man recht einfach testen: die Sensoren mal drehbar (per Hand) auf nem Brettchen montieren, an den Arduino damit, und für jeden Sensor ne LED an den Arduino anschliessen. Schon kannst du in Ruhe ausprobieren, welche Bereiche du auf welche Entfernung abdecken kannst.
Hab ich ähnlich gemacht: nen Hindernis aufgestellt, den Roboter in passender Entfernung dazu und dann mit Kreide markiert, wo das Hindernis stehen muss, damit es erkannt wird. So hat man dann schön ne Skizze.
Nachdem ich das hatte, hab ichs mir in ein Grafikprogramm übertragen, und konnt so recht easy ausrechnen, wo ich was brauche, und wie die Sensoren angeordnet sein müssen.
Geht aber mit Millimeterpapier, Lineal und Bleistift auch.

[Benny1989]

okay, ich bin schon fleißig am Code basteln und werde schauen ob ich mehere programmiert bekomme ....

Ich werd es jetzt mal mit einem probieren, wie gesagt meine Programmier Kenntnisse halten sich in grenzen - ich steigere mich um jedes Projekt =)

Will gleich noch mein Code an Servos ausprobieren, dann kann ich ihn dir auch gerne zeigen^^

Das mit den US Sensoren sollte ich als gelernter Technischer Zeichner hinbekommen, ich hab schon angefangen mir ne Halterung zu konstruieren!
Dazu hätte ich noch eine Frage, wie hoch über dem Boden sollten sich den die US Sensoren befinden? was hat dir denn die Praxis gezeigt?
Eher wenig oder eher mehr ? hab auch schon überlegt zwei etwas höher, in meinem Fall so 300mm über Boden zu platzieren und der in der Mitte
dann etwas leicht nach unten, wo dann natürlich auch die Distanz etwas geringer ist!

Hab in meiner CAD Software auch schon die Winkel des US Sensor eingetragen, wenn ich das am Testen bin wie du beschrieben hast!
Kann ich mir die US Sensoren so platzieren das sie etwa so 5 Grad überlappen das auch sicher gestellt wird, das nichts übersehen wird!

Hier mal ein CAD Bild ohne Verkleidung:

28761

[Rabenauge]

Hm, die Dinger haben nach oben und unten nen erstaunlich schmalen Erfassungsbereich. Meine sind nur etwa 10cm über dem Boden-ich dachte, ich könnte dann auch Abhänge (oder Treppen) erkennen: geht nicht. Kann aber auch am zu spitzen Winkel liegen...ich habs nicht weiter verfolgt. Einfach mal testen...

Das Überlappen _kannst: du machen, musst dann nur sicherstellen, dass sie wirklich _einzeln_ abgefragt werden (sonst nämlich könnt der eine das Echo vom anderen hernehmen, und das gibt ein Durcheinander), also nen paar ms warten zwischen den Abfragen.
Hat sogar nen Vorteil: du kannst so _auch_ feststellen, ob grade vor dem Ungetüm irgendwas ist oder mehr rechts, mehr links-und deine Ausweichstartegie danach richten.
-haben beide Sensoren (in ungefähr derselben Entfernung..) ein Echo, muss das Hindernis sich halbwegs mittig vor dem Roboter befinden
-hat nur der linke Sensor ein Echo, ist links was im Wege
-gleiches gilt für rechts

Bedenke aber auch, dass die Überlappung der Bereiche den Gesamtbereich wieder schmaler macht-da verlierste bisschen Breite bei, also nicht übertreiben.

Was den Code angeht: ist doch easy. So wie du _einen_ abfragst, machste das nacheinander mit...beliebig vielen.

[Benny1989]

also ich hatte heute Abend ein kleines Erfolgserlebnis =) =) =)

Ich hab mein Code auf mein Mega geladen, bin rüber in die Firma und hab den Mega an mein Roboter angeschlossen,
Samt HC-SR04. Natürlich nicht richtig installiert sondern nur zum Testen!

Ich hab es jetzt hinbekommen, den Code so zu schreiben das ich die Distanz einstellen kann ( momentan auf 70cm )
wenn der Roboter ein Hindernis erkennt setzt er zurück stoppt und dreht dann nach rechts und fährt dann weiter vorwärts =)

Nach und nach will ich das jetzt verfeinern, also mit den Verschiedenen US Sensor, bzw mehreren und muss es auch mal an den
Roboter bauen, das ich es auf dem Rasen testen kann!

Bin erstmal froh das es so funktioniert^ und werd mal probieren ob ich es hin bekomme, mit mehreren US Sensoren ...

Stellen sich mir noch zwei Fragen: einmal meinst du wenn ich den US Sensor von Seeedstudio nehme, kann ich einfach anstelle von dem HC-SR04
verwenden? oder ist der anderst ? der hat ja auch ein Echo und ein Trigger Pin ???

Wenn nicht, die HC-SR04 Sensoren gefallen mir schon, wo hast du denn die Halterungen gefunden?
Würde ich dann schauen und wenn es mir zusagt, dann die HC´s zu verwenden!
Weil wie du schon schriebst das die HC´s es auch tun und wenn ich 6 Seeedstudio kafe kann ich mir viel mehr HC´s kaufen^^

Danke Rabenauge für deine Ganzen Tips - sehr Hilfreich - das schätze ich sehr an diesem Forum.
Ich hoffe durch die Beiträge hier, können auch andere User etwas davon für sich verwenden.

Nehme auch gerne Tips oder Ratschläge von anderen an - jeder Tip ist Gold wert^^

Mfg Benny

[Rabenauge]

https://www.google.de/search?q=bracket+hc-sr+04&client=opera&hs=es2&channel=suggest&tbm=isch&tbo=u&source=univ&sa=X&ei=a3jYU5OHK8LnywO9nYH4Dw&ved=0CB8QsAQ&biw=1166&bih=810

Massenhaft-wo es die gibt musst du selber mal suchen-haben einige Läden in diversen Ausführungen.

Zu Sensoren gehört immer mindestens ne brauchbare Beschreibung-wenn es die nicht gibt, kauft man sie nicht. Wahrscheinlich werden die Dinger ähnlich angesteuert wie die HC-SR04 aber-ich kenn sie nicht. Aber ebenso möglich, dass sie z.B. ne I2C-Schnitstelle haben (wäre genial, aber teurer, vor allem wenn man die Adresse ändern kann). Die HC-SR04 kann man übrigens auch umbauen, dass sie nur einen Pin brauchen- würd ich dir aber erstmal von abraten, der Mega hat genug Pins.
Also: den Anbieter fragen oder nach nem Datenblatt oder so suchen.

[Benny1989]

okay danke für den Tip, aber ich werde mir selbst eine Halterung wo ca 3 HC´s rein passen konstruieren und selbst fräsen!
Denn ich mach mir solch Sachen immer gerne selbst, denn dann hab ich es wie ich es brauche, und die meisten kommen aus
Fernost dauert der Versand recht lange, und kaufen kann jeder^^

Werd mir mal 5 Stück von den HC-SR04 zulegen, da weis ich das es funktioniert - wie gesagt ich teste mal einen, und dann schauen
wie ich es mit drei hin bekomme.

[Sebas]

Sorry etwas offtopic, aber wo hast du denn die Reifen her?
Viele Grüße,
Sebastian

[Benny1989]

Guten Morgen Community,

ich hab gestern mal die Sensoren und die passende Abdeckung des HC-Sr04 konstruiert und den Streuwinkel ebenfalls!

Dazu hab ich drei Bilder die das verdeutlichen sollen, da hab ich dann auch geschaut zwecks dem Abstand und der Überlappung.
Jetzt ist es nur so, habe mir nicht die HC-SR04 bestellt weil ich nur einen habe, sondern habe den bestellt aus dem vorherigen Beitrag .....
Habe gelesen der arbeitet auch mit Trigger und Echo Pin - und programmiert sich genau so wie der HC-SR04.
Wenn der neue US Sensor kommt muss ich natürlich wieder nach dem Streuwinkel schauen und wieder neu konstruieren, das ist aber kein Problem.
Hab auch erstmal einen bestellt um es nochmals zu testen! Werde aber gleich drei Abdeckungen aus Aluminium aus dem vollen Fräsen. Weil ich davon ausgehe
das es mit diesem US Sensor genau so funktioniert - das ja nichts mit der Abdeckung zu tun hat.

Hintergrund ist folgender .... das ich mir das Sensor Shield für mein Mega mit bestellt habe, das ebenfalls von der Firma Speeedstudio ist!
Der Vorteil bei Speeedstuido ist, das denen ihr ganze Shields und Sensoren und alles die gleichen Buchsen haben und es auch passende
Kabel dazu haben, dann kann man sich ein Haufen löterrei und Bastelei sparen! Das finde ich wirklich gut , den auf das Sensor Shield,
passen jede Menge Sensoren, Buttons, LED´s, Pottis usw usw

Hier mal der Link dazu: ( Der Link zum US Sensor war zwei Beiträge von mir vor diesem enthalten )

http://www.exp-tech.de/Shields/Seeed-Studio-Grove-Mega-Shield.html

Hier hab ich euch die besagten Bilder, wo man das mit dem Streuwinkel sieht. Wenn das mit dem einen Funktioniert
werde ich mir noch zwei besorgen. Das sind auf den Bildern die drei oberen.

Dann hab ich mir überlegt, ich mach noch zwei dazu, für niedrigere Hindernisse, diese sind dann 10 Grad nach unten geneigt
und schauen 18 bis 20 Grad zueinander ! Aber wie gesagt Testen will ich es erst mit einem dann mit allen dreien!
Wenn dann alles so funzt wie ich mir das vorstelle gibt es bestimmt auch mal ein Video^^

287842878528786

Mfg Benny

p.s. @ Sebas: Die Reifen sind echt mega geil und recht günstig! Mit den Reifen hast du über all Traktion - Bin hoch zufrieden bin auch nie stecken geblieben!
Und wenn dann hat der Reifen die ganze Wiese umgegraben^^ - Kann ich nur weiter Empfehlen!
Vorteil ich noch das es sie in 3 verschiedenen Befestigungsmöglichkeiten gibt - Also Flansch, Hohlstift oder Keilnut,
kann jeder entscheiden was besser ist für seine Anwendungen bzw was man für eine Befestigungsmöglichkeit hat!
http://www.radundrolle.de/seiten/luftraeder/AS-Reifen/AS-Profil_400x100-Antrieb.htm

[Benny1989]

Hallo Community,

nach etwas testen und herum spielen mit dem Code, hab ich was gravierendes herausgefunden >.<

Und zwar: wenn der Rasenmäher aus ist, funktioniert es einwandfrei, sprich der Code geht.
( fährt gerade aus bis Hindernis , dann 3 Sekunden zurück und dann 4 Sekunden nach rechts drehen - anschließend weiter bis nächstes Hindernis! )

Nur wenn der Rasenmäher an ist! ! Misst der Ultraschallsensor wirklich ein krampf zusammen!
Das heist für mich das der US Sensor so arg schwingt das ihm irgend was nicht passt!

Wobei als info für euch, der Rasenmäher sowie der US Sensor schwingend ausgehängt bzw befestig sind ! Wie ihr auf den Bildern sehen könnt

28828

Und wie gesagt wenn der Rasenmäher aus ist, geht es selbst im Gelände, und wobei der Sensor so gut wie nicht schwingt bzw vibriert.

Ich werde morgen versuchen einen Größeren Schwingungsdämpfer zu verbauen und es dann nochmals testen.
In der Hoffnung, das der größere Schwingungsdämpfer noch mehr Vibrationen verhindert!

Habt ihr vllt noch eine andere Idee? oder noch einen anderen Ultraschall Sensor denn ihr empfehlen könnt ?
Darf auch bisschen teurer sein wie paar Euro, nur 70 oder 100€ sollte er ned grad kosten, denn ich möchte ja ein paar verbauen!

[Klebwax]

Nur wenn der Rasenmäher an ist! ! Misst der Ultraschallsensor wirklich ein krampf zusammen!
Das heist für mich das der US Sensor so arg schwingt das ihm irgend was nicht passt!

Wer sagt dir, daß es "mechanische" Störungen, Vibrationen sind?

Könnte der Mähmotor auch Ultaschall absondern, der den Sensor beeinflußt? Könnte der Motor nicht auch elektrische Störungen im Sensor oder in den Zuleitungen verursachen? Oder ein Wackelkontakt? Oder ...

Ich würde erst mal das Problem analysieren, bevor ich an Lösungen arbeite.

MfG Klebwax

[Benny1989]

ja guter Ansatz, also daran hab ich auch schon gedacht! Nur Kabel hab ich überprüft, die sind in Ordnung!
Habe auch ein zweiten US Sensor ausprobiert, also an dem kann es auch nicht liegen so das der eine kaputt wäre!

Weis nicht wie ich es testen kann ob der Rasenmäher irgend welche elektrischen Störungen des Ultraschall Sensor veruracht?

Also hab heute mittag schon eine ganze Weile probiert und zu testen um es aus zu probieren an was der Fehler liegt!

Grins ich weis schon wieder eine Frage über die Lösung! Gäbe es auch noch ein anderes Sensor ? um Hindernisse zu erkennen ?
Also auser Infrarot?

[i_make_it]

1234567890

[Sisor]

Nur wenn der Rasenmäher an ist! ! Misst der Ultraschallsensor wirklich ein krampf zusammen!
Das heist für mich das der US Sensor so arg schwingt das ihm irgend was nicht passt!
Du übersiehst das Wesentliche! Ultraschall bezeichnet Frequenzen ab 16 kHz, also etwa ab der oberen Hörgrenze des Menschen.
Ein Vebrennungsmotor gibt solche Ultraschallgeräusche von sich. Diese misst du mit deinen Ultraschall-Sensoren.

[i_make_it]

1234567890

[Benny1989]

Ich hab auch schon überlegt, vom PKW eine Einparkhilfe zu nehmen, vllt geht das ja auch, weis nur nicht ob man den so einfach mit dem
Arduino ansteuern kann. Also solch ganz normalen PDC´s da hab ich einen neuen von einem A6 zu Hand.

Okay, also einfach eine Stüroporplate nehmen an dem Roboter befestigen, und an die Platte dann den Ultraschall Sensor?
Das Sensorkabel ist sowieso zwei geteilt, also ein Kabel mit 4 Adern von hinten nach vorne und dann kommt das 8cm lange Sensor Kabel.
Wenn Bilder erwünscht kann ich gerne eins machen!

Zur Stüroporplatte eine Frage muss die einfach so groß wie der Sensor sein oder muss die nach Oben etwas verlängert sein? also das sie über
den Roboter hinausschaut?

[Rabenauge]

Die Sensoren _sollten_ eigentlich auf nix anderes reagieren, da sie moduliert arbeiten.
Natürlich ist es denkbar, dass der Benzinmotor da zufällig _auch_ Störungen einstreut aber wie schon gesagt: das muss analysiert werden.
Bau den Sensor mal ab (Kabel dran lassen), halt ihn in der Hand, bei laufemdem Mähwerk und guck, was dann passiert.
Vibrationen sind schon denkbar-aber ich glaubs nicht so richtig. Die kannst du damit in jedem Fall schonmal ausschliessen.

Am ehesten vermute ich da sowas wie Störungen durch die Zündanlage des Mähmotors- das sind elektrisch gesehen meist so richtige Schweinereien, die da abgehn. Die können noch weit mehr durcheinander bringen.

Oder mach nen Versuchsaufbau: irgendein Board, Sensor dran, Batterie und nen Display (oder Lapi, Hauptsache du siehst was der Sensor treibt)-also mechanisch und elektrisch völlig getrennt vom Fahrzeug, und dann geh damit in die Nähe, während der Mäher läuft.
Da kannst du dich von allen Seiten ranpirschen, und somit ziemlich schnell rausfinden, ob es nix weiter ist als lausige Funktstörungen der Zündung, oder doch was anderes.

[Benny1989]

Also wie ich schon gesagt hab hab ich am Montag jede Mänge getestet, ich bin schon mit meinem Macbook hinter meim Roboter hergelaufen,
wenn Motor aus, dann misst er Sauber und er an ist, dann misst er immer 130cm, 50cm, 0cm, 50cm, 3cm, 24cm, 85cm, 5cm.

Ich habe ihn auch schon abgeschraubt und den Roboter samt Rasenmäher laufen lassen, also was du Rabenauge beschrieben hast was ich testen soll.
Kann ich auch ausschließen, bzw nicht ganz das muss ich nochmals testen, also wie geschrieben hab ich den Sensor abgeschraubt und bin vor meinem Roboter
hergelaufen, jetzt war ich natürlich einen guten Meter davon entfernt, was passiert wenn ich den Sensor in die nähe des Motors halte, hab ich noch nicht getestet.

Das werde ich heute Mittag gleich mal tun, werde trotzdem ausprobieren, was passiert, wenn ich einen größeren Schwingungsdämpfer verbaue, da ich später e in die Stadt muss.

Ich weis nur nicht was ich noch testen kann wenn es der größere Schwingungsdämpfer und den Sensor neben den Motor halten nicht die Ursachen sind!
Akku Rasenmäher statt Benzinrasen Mäher verbauen^^ Der hat keine Zündung und ist leichter! Würde gehen oder ? weil der Elektromotor vom Akku Rasenmäher
den US Sensor nicht stört oder ? macht mein Hauptantrieb von Roboter ja auch nicht ;-)

[Sisor]

Die Sensoren _sollten_ eigentlich auf nix anderes reagieren, da sie moduliert arbeiten.
Kannst du das ausführen?

[Rabenauge]

Hm-hab mich evtl. etwas falsch ausgedrückt. Ich meinte damit, dass die _nur_ einen bestimmten Frequenzbereich "hören" (um die 40 kHz, glaub ich) und auch das _nur_ dann, wenn sie vorher gesendet haben.
Alleine das aber sollte die Sache relativ robust gegen akustische Störungen machen.

@Benny: wenn es so ist,dass du auch dann die Felmessungen hast, wenn du den Sensor lediglich am Kabel hast, ist die Sache mit nem Schwingungsdämpfer aussichtslos- den hast du ja, wenn der Sensor nicht mit der Maschine mechanisch verbunden ist, sowieso!
Wenns dann trotzdem nicht besser geht, kannst du das als Lösung ausschliessen.
Und: nimm bloss kein Styropor- das Zeug überträgt Schall nämlich hervorragend. Halt dir mal ne Styroporplatte ans Ohr und klopf dran...

Ich würd mir als nächstes die Zündanlage vornehmen denn: der Sensor speist ja das Echo-Signal (aufbereitet) auf nen Digitalpin.
Wenn nun in diese Leitung von aussen irgendeine Spannung eingespeist wird, kann nur Müll rauskommen. Und genau das tun die meisten Zündanlagen leider.
Im einfachsten Fall (wenn du Glück hast) genügt es, die Leitungen (Zündkabel und Sensorkabel) abzuschirmen-kannst du testweise mal tun, indem du beides in Alufolie wickelst.
Pass aber auf dass du dabei keine Kurzschlüsse machst.

[i_make_it]

1234567890

[Sisor]

Bis zum Gegenbeweis bleibe ich der Meinung, dass der Lärm des Rasenmähers in seiner Umgebung ein so hohes Grundrauschen im 40 kHz Bereich erzeugt, dass es den Pegel der Ultraschallmessung überssteigt. Dies macht eine Messung des mit dem US-Sensor unmöglich. So hohe Frequenzen sind allerdings sehr leicht abdämmbar.

[Benny1989]

Also,

habe es getestet, habe das ganze Kabel ( 80cm ) mehrmals mit Alu Folie umwickelt und keine Entwarnung, der USSensor wird immer noch gestört.
Dann hab ich ihn abgeschraubt und wenn ich ihn Hinter den Roboter hebe geht es, also so ca 50 bis 60 cm vom Rasenmäher entfernt!

Dann hab ich getestet um so näher, ab einem abstand von ca 40 bis 50cm, man an den Mäher hinkommt, wird der USSensor gestört!
Ich habs angeschirmt, bis ans Ende wo der Sensor ist bis da wo es in meine Steuerungszentrale geht! Da ist aber noch ein bisschen Freies Kabel!
Muss das komplett abgeschirmt sein? Ich könnte schnell in den Elektroladen meines Vertrauens fahren und mir 4 adriges Abgeschirmtes Kabel holen!
Die Frage ist nur - von dem 4 adrigen bis zum Sensor kommt noch mal ein Verbindungskabel das ist leider nicht Abschirmen kann weil es nur 0,5 Quadrat ist.

Ich Hader die ganze zeit mit mir ob nicht doch ein Akku Mäher von Vorteil währe! Aber das halte ich mir als letzte Option frei!
Gibt es noch eine Andere Lösung außer Infrarot und Ultraschall ?

@ Sisor - wie meinst du das, dass währe ganz einfach bzw leicht ab zu dämmen?
@ i_make_it - ich hab leider solch Gerätschaften nicht und auch nicht das wissen das alles so zu prüfen wie du beschrieben hast!

Ich weis nur das was ich grade eben beschrieben habe, vllt habt ihr mir noch einen Tip.

Werde jetzt noch probieren das Zündkabel ab zu schirmen .... in der Hoffnung das dass etwas Besserung bringt!

- - - Aktualisiert - - -

okay , Nachtrag von mir ..... Selbst mit abgeschirmtem Zündkabel und besser abgeschirmtem Sensorkabel, keine Besserung -.-

[Rabenauge]

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.

[Benny1989]

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?

2883828839

[Benny1989]

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?

[Rabenauge]

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.

[Benny1989]

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??

[Sisor]

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.

[Benny1989]

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?

[Sisor]

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.

[Benny1989]

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 ;-)

[Sisor]

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.

[Benny1989]

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 ...

[Sisor]

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

[cdk]

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-Spektrumanalyser/UTD-2102-CM/3/index.html?&ACTION=3&LA=2&ARTICLE=123971&GROUPID=4044&artnr=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-Spektrumanalyser/UTD-2025-CL/3/index.html?&ACTION=3&LA=2&ARTICLE=129858&GROUPID=4044&artnr=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!

[Benny1989]

@ 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 :-)

[i_make_it]

1234567890

[Benny1989]

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

[Rabenauge]

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.

[i_make_it]

1234567890

[Benny1989]

@ 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 :)

[Benny1989]

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:


#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!


#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

[Rabenauge]

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.

[Benny1989]

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:


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!

[Rabenauge]

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??

[Benny1989]

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?




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();
{
{
{

[Rabenauge]

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;}
}

[Benny1989]

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 ?


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();
}
}
}

[Rabenauge]

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.

[cdk]

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

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

[Rabenauge]

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....

[Benny1989]

@ 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 ;-)


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.




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();
}

}

[Rabenauge]

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:



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.

[Benny1989]

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?


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);
}

[Rabenauge]

.
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:


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...

[Benny1989]

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!


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?

[i_make_it]

1234567890

[Rabenauge]

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.

[Benny1989]

@ 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!


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?

[Rabenauge]

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



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.

[Sisor]

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

[Rabenauge]

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.

[Sisor]

Hm-biste da sicher?Ja, schau hier: Operatoren nach Priorität geordnet (http://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit% C3%A4t)


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. Auch ohne Klammern werden die Ergebnisse der Vergleiche verodert.

[Benny1989]

Danke ihr beiden für eure Tip´s.

ich hab es jetzt so gemacht, das wenn der Sensor Mitte, Vorne Rechts und Rechts ein Hindernis erkennt, stoppt, zurücksetzt sich nach links dreht und dann
wieder gerade aus vor fährt. und natürlich für die Sensoren Vorne Links und Links - nach Rechts ausweichen!


void loop()
{
if(tempVORNE_MITTE < triggerDistanz || tempVORNE_RECHTS < triggerDistanz || tempRECHTS < triggerDistanz)
{
zurueck_RECHTS();
}
else
{
vor();
}

if(tempVORNE_LINKS < triggerDistanz || tempLINKS < triggerDistanz)
{
zurueck_LINKS();
}
else
{
vor();
}
}

ja Rabenauge, so hab ich mir das mit dem Bumper schon gedacht, deswegen muss ich dann noch zwei Taster integrieren, und natürlich auch
konstruktiv umsetzten! Recht weit unten angebracht und einfach schwingend aufgehängt wie eine Stoßstange sollte es aussehen! Aber da muss
ich mir dann erst noch ein paar Gedanken machen, einerseits zum Code und andererseits für den Bumper an sich!

Das mit den Tastern kommt ja dann auch in den Loop Teil wo heist wenn Taster HIGH ( z.b.) dann stop - zurück und schauen ob links oder rechts frei
und da wo frei ist hin ausweichen! So hab ich mir das gedacht, nur so geschrieben ist einfacher wie im Code geschrieben :D

[Rabenauge]

Du hast doch nen Mega 2560 drauf. Der hat bei dir aber kaum was zu tun, deshalb würde ich kurzerhand den/die Taster an Interrupts binden.
Das hat Vorteile: die brauchen nie extra abgefragt werden, und es wird immer _sofort_ reagiert.
Hab ich beim Monstertruck auch gemacht: wann immer ich den Joystick-Button drücke (der entkoppelt bei mir auch sämtliche Servos, also auch die Fahrmotoren, bzw. schaltet sie zu (halt an, wenn sie aus sind, und aus wenn sie an sind), wird ein Interrupt ausgelöst der nen Flag setzt (ne simple kleine Variable) die dann _umgehend_ auf das Ereignis reagiert.
Trotz der Tatsache, dass ich nun teilweise wirklich zeitraubende Aktionen am laufen hab, ist da keine merkliche Verzögerung da.
Genau richtig, so als "Notaus".
Wenn man das Ding nämlich nur zyklisch abfragt, kommts drauf an, wann der mal "dran ist"- das kann für nen Notstopp zu lange dauern.

[Benny1989]

also war der Code richtig wie ich es geschrieben habe?

der Compiler mekert in dem Scan Unterprogramm, das " no match for operator

Das is ja von mir so geschrieben wie es Rabenauge vorgeschlagen hat!
Nur im Original kam im Loop Teil von folgendes: frontDistance = distance;

"distance" ist ja jetzt bei mir "VORNE_MITTE" und tempVORNE_MITTE das hab ich verstanden das die Variable nicht mehr
Golbal sondern Lokal ist!


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



das mit dem Bumper muss ich schauen, wenn du das so beschreibst wie du das machen würdest, muss ich konzentriert lesen!
Hab mir damals ein Buch gekauft und hab von Buttons und LEDs und Servos - zu - Xbee und Funkmodulen und Sensoren gewechselt.
Wie ich schon schrieb das ich für sowas halt noch etwas brauche und mich an jedem Projekt steigere.

Machen Ausdrücke sind mir noch fremd, deswegen was für jemand änderst mit dem Bumper Code eine Kleinigkeit ist - für mich immer in Ruhe angehen muss!

Habe gelesen das vor das VORNE_RECHTS wenns Lokal sein soll natürlich auch ein "int" davor muss oder etwa nicht?

In etwa so:


void scan_VORNE_RECHTS()
{
int tempVORNE_RECHTS = VORNE_RECHTS.ping();
int VORNE_RECHTS = tempVORNE_RECHTS / US_ROUNDTRIP_CM;
if(VORNE_RECHTS == 0)
{
VORNE_RECHTS = MAX_DISTANCE;
}
delay(100);
}

Das heist jetzt sollten die Unterprogramme und die IF Anweisung stimmen, wenn der Code nun steht kann ich mich an die Sensoren an meinem Roboter machen.
Und denn Bumper mal in Ruhe konstruieren ....

[Rabenauge]

Sieht relativ gut aus aber:

int VORNE_RECHTS solltest du wohl schon global lassen-auf diesen Wert willst du ja an anderer Stelle auch zugreifen dann?
Für sowas benutz ich immer die serielle Konsole-da kann man fix mal ne Ausgabe schreiben, und gucken, ob dieser oder jener Wert auch dort ankommt, wo er gebraucht wird.

[Benny1989]

okay, da hast du auch wieder recht sollte schon global belieben.

Und dann mal zum Testen kann ich den Code für den Taster schon mal normal schreiben oder also so das auch ich ihn verstehe :D

[Rabenauge]

Kannst du aber machs mit Interrupts. so eine Sicherheitsfunktion ist recht nutzlos, wenn sie erst nach Sekunden reagiert...

[Benny1989]

Ja, das is natürlich Sinnvoll, ich will es ja nicht nur als Sicherheitsfunktion, sondern ich hab in der Wiese Steine wo die Ultraschall Sensoren nicht erkennen und im Garten ein kleines
Stückchen mit so Holzrabatten begrenzt, das erkennen die Sensoren auch nicht!

Sprich der Bumper soll auch dazu dienen, wie besagt, stoppen, zurücksetzten, wenden und weiter gerade aus!

Nur das mit den Interrupts muss ich mir noch sehr genau anschauen!

Was mich auch noch brennend interessiert ! Wie ich das umsetzte das wenn es heist fahre gerade aus das der Roboter auch gerade aus fährt!
Also mit einem Giro Kreisel oder so und dann Sensoren an jedem der beiden Motoren, das die Software auch weis was der Roboter macht!
Sprich, wenn man vorn gegen den Roboter drück, wenn er gerade aus fährt oder das Gelände uneben ist! Das er selbständig koregiert und
wahrscheinlich mit Toleranz versehen die Spur automatisch hält!

Aber wollen wir es nicht gleich übertreiben, Stück für Stück, das ist ja ein Hobby und kein Projekt was morgen fertig werden muss!
Hab jetzt erstmal die Halterungen für die Sensoren konstruiert, werden dann am Wochenende programmiert, muss mir nur noch
über die Kabelführung Gedanken machen ..... wie immer wenn Bilder gewünscht sind einfach sagen^^

[Rabenauge]

Mach ruhig ab und zu Bilder-warum nicht.

Eine Geradeausfahr-Regelung willst du also einbauen, hm...am simpelsten würde das in deinem Fall (mit deiner abenteuerlichen Ansteuerung als Servos) wohl mit nem ganz normalen Modellbaukreisel gehn. Da brauchst du überhaupt nix in Software zu machen-aber:
Das ist doch nicht das Ende der Fahnenstange. Schliesslich willst du irgendwann ja auch effektiv mähen können-derzeit ist der Stand so, dass das Teil eher willkürlich auf der Wiese rumfahren wird, und dabei-zufällig- alles mäht irgendwann, oder auch nicht.
Da wäre ein Kompass natürlich sinnvoller (war nicht auch mal ein GPS im Gespräch?-die liefern ohne richtigen Kompass nicht allzu oft ordentliche Kursdaten, also wär der auch dafür sinnvoll).
Aber: der sollte etwas weg von jeglichem (wirklich: jeglichem) Eisen sein, und falls deine Einsatzwiese nicht tischeben ist, braucht er ne Neigungskompensation. In Schräglage misst er nämlich sonst Mist.
sowas tüdele ich grad auch an den Monstertruck: HMC 5883l als Kompass (spottbillig beim Chinesen, hab 1.5o oder so gezahlt) und dazu die MPU 6050 als Neigungsmesser. Damit kann man den Kompass mit einer Kompensation versehen-ich hoffe jedenfalls, ich kriegs hin.
Gibts aber auch als komplette Module, die heissen dann 9050 oder so (9DoF), haben Kompass, Beschleunigungsmesser und Gyroskop drauf. So ein Ding kann deine Geradeausfahr-Regelung quasi nebenbei mit erledigen.
Da die im allgemeinen per I2C ausgelesen werden, sind auch Pins kein Problem...

[Benny1989]

Klar CAD Bilder kann ich am Wochenende mal einstellen. Bin gerade dabei mir Gedanken zur Umsetzung, der Haltungen für Sensoren zu machen, Aussehn, Funktion, Kabelführung
Befestigung und Design usw usw.

Das mit der Navigation, is für mich noch bisschen Bahnhof, aber ich arbeite mich dann schon ein - wie ich geschrieben hab - eins nach dem anderen. Ist ja ein Hobby und nichts was morgen fertig sein muss!
Weis dann natürlich noch nicht ob ich lieber einzelne oder ganze Module verwende - wie gesagt - davon hab ich nun wirklich keinerlei Erfahrung.

Gut anhören tut sich das schon mal, währe natürlich auch bombastisch wenn der Roboter wüsste wo er schon gemäht hat! Ist ja bestimmt auch machbar - mit dem nötigen Wissen natürlich =)

Den nächsten schritt was ich machen will is das mit den Ultraschall Sensoren und deren Halterung das dass zuverlässig funktioniert - natürlich mit dem wissen das er willkürlich auf der Wiese
um her fährt! Anschließend dann die Bumper und dann schauen wir weiter =)

[Rabenauge]

Bei einem "festen Arbeitsplatz" ist das gar nicht mal soo schwer: du kannst ihm einfach Kurse programmieren (ähnlich wie ich es mit dem Monstertruck vor habe, der bekommt auch Routen, bestehend aus mehreren GPS-Punkten, und soll sich dann an denen lang von A nach B hangeln), musst halt nur für sorgen, dass er auch seine aktuelle Position immer genau genug weiss-mehr als ne halbe Mäherbreite Abweichung sollts nicht werden. Bei deinem, recht langsamen Maschinchen, halte ichs für machbar- nen ordentliches GPS schafft Genauigkeiten unter nem Meter inzwischen.
Wenn du den natürlich auf verschiedenen Wiesen (auch vorher nicht bekannten...) einsetzen willst, muss er das alles selber erledigen-dann wirds herausfordernd.

Ich speichere meine Routen einfach auf ner SD-Karte, da kann ich hunderte raufpacken, und dann unterwegs einfach die gewünschte wählen.
Ganz soweit bin ich allerdings noch nicht, und wenn, dann schaun wir mal, wie weit ich das noch aufbohren will (da geht noch so richtig viel mehr).

Für deinen Mäher: hast du nicht eh ne Fernsteuerung dran?
Dann kannst du doch recht "sorglos" testen- solltest das Gerät natürlich im Auge behalten, und dir die Fernsteuerung als "Notaus" programmieren.
So kannst du ganz gemütlich deine Hinderniserkennung testen- und hast hinterher auch noch ne gemähte Wiese.;)

[Benny1989]

ja das weis ich auch noch nicht so ganz, bis jetzt hab ich zwei so genante Arbeitsplätze ... also zwei Wiesen!
Ich weis aber nicht ob ich nicht doch mal wo anderst mähen muss!

ja ich denke mit GPS kann man ein paar schöne Dinge anstellen, momentan sind mir aber die Sensoren völlig ausreichend!
Wie du schon erwähnt hast, das GPS immer genauer wird. Wir wollen ja nicht gleich übertreiben!

Ich bin immer noch daran an denn Interrupts zu schauen, wenn ich richtig verstanden habe! wenn ich es so schreibe unter die Anweisungen der Ultraschallsensoren

bumperStatus_RECHTS = digitalRead(bumperPin_RECHTS);

if(bumperStatus_RECHTS == HIGH);
{
zurueck_LINKS();
}
if(bumperStatus_RECHTS == LOW);
{
vor();
}

// -----
bumperStatus_LINKS = digitalRead(bumperPin_LINKS);

if(bumperStatus_LINKS == HIGH);
{
zurueck_RECHTS();
}
if(bumperStatus_LINKS == LOW);
{
vor();
}
}

Dann würde der Bumper nicht gleich funktionieren weil die Abfrage nicht gleich erfolgt sondern irgendwo in der Reihenfolge fest steckt!
Dafür die Interupts das egal an welcher Stelle der Code gerade steckt, das wenn der bumper gedrückt wird, der Roboter reagiert!
Hab ich das richtig verstanden ?

Ja ich hab nen Arduino Uno als Sender wo ein Joystick dran hängt ein Uno der mit dem Mega zusammen im Roboter steckt!
Funkverbindung wird ausgeführt mit Hilfe zweier NRF24L01+ Modulen wobei nochmals ein Großer Dank an Sisor geht "Daumen Hoch"

Das ist so zu sagen ein eigener Kreislauf, wenn ich mit dem Autonomen mähen fertig bin und noch hier und da ein Gras Büschel steht oder ein kleines Eck vergessen hat,
bzw nicht erreicht hat, steuere ich ihn von Hand bzw manuell wenn man es so nennen mag, hin und mähe das von Hand weg, genau so um Bäume oder Büsche herum,
das mähe ich auch vorher manuell und wenn ich das hab, schalte ich die Fernsteuerung und den UNO im Roboter aus und den Mega an und es geht Autonom weiter .....

[Rabenauge]

Ja-im Groben hast du es richtig verstanden. Ein Interrupt unterbricht das laufende Programm sofort (genauer gesagt, nachdem der aktuelle Maschinenbefehl abgearbeitet ist), und es wird eine sogenannte ISR (praktisch nen eigenes Unterprogramm) aufgerufen. In der kann man nun _irgendwas_ wichtiges veranlassen.
Das geht im allgemeinen weit schneller, da ansonsten deine Bumper nur dann abgefragt werden, wenn die eben dran sind.

Wozu du allerdings für das bisschen Fernsteuerung nun noch nen Uno brauchst...kann der Mega doch auch noch mit erledigen...

[Benny1989]

ja okay dann hab ich schonmal das richtig verstanden^^
Werde noch schauen - wie ich das Lösen kann.

Ganz einfach weil das mein erstes Arduino Projekt war bzw so mit das erste! klar könnte das der Mega mit erledigen, aber die beiden Unos sollen die Fernsteuerung übernehmen!

Und der Mega alles alles andere was noch kommen soll, mit Sensoren, Autonom und Roboter Arm usw usw!

Wenn ich dann mal die erforderliche Erfahrung auf bringen kann, werd ich vllt alles über den Mega machen und nur noch der Uno in der Fernsteuerung!

- - - Aktualisiert - - -

Hab mal zwei Fragen zu den Interrupts:
Habe ein gutes Tutorial gefunden nur beschreibt derjenige meine Frage nicht!

Mega2560:

Inter. 0 = Digitaler Pin 2
Inter. 1 = Digitaler Pin 3
Inter. 2 = Digitaler Pin 21
Inter. 3 = Digitaler Pin 20
Inter. 4 = Digitaler Pin 19
Inter. 5 = Digitaler Pin 18

Er beschreibt hier die INTER Liste - heist das ich kann die Bumper nur an die Pins anschließen wo dafür vorgesehen sind ?

Und würde das mit den Interrupts im Setup teil dann so aussehn?


attachInterrupt(2, zurueck_RECHTS, RISING);
attachInterrupt(3, zurueck_LINKS, RISING);

Denn er schrieb im Tutorial: “attachInterrupt(INTER, FUNKTION, MODUS)”

Also 2 für den Inter / zurück_RECHTS für die Funktion und Modus "RISING"
Das steht für : Löst aus wenn der Wert des Pins von LOW auf HIGH wechselt

Aber wenn das so passt müsste es das im Setup Teil gewesen sein oder ? also natürlich noch die Globale Variable für den Interrupt deklariert,
und dann natürlich das aus dem vorherigen Post heraus löschen - das is ja klar!

Und trotzdem das man es in den Setup Teil des Sketches schreibt, löst es dann die Funktion aus die beschrieben ist? Weil ich gedacht habe das was man im Setup Teil schreibt
wirklich nur einmal gelesen bzw abgearbeitet wird! Als Info der Compiler meckert schonmal nicht - Grins^^

[Rabenauge]

Interrupts müssen nur einmal "initialisiert" werden-weiter nix. Ist das gemacht (so wie du es beschreibst), löst jedes Ereignis (RISING) den Interrupt aus und es wird der Handler aufgerufen.
ABER: ich würde auf gar keinen Fall zwei Interrupts verschwenden dafür. Du kannst beide Schalter auf einen legen, dann isses Wurst, welcher anspricht. Das spart nicht nur nen Interrupt (einige Bibliotheken benötigen auch welche!) sondern du gehst auch sicher, dass die beiden Interrupt-Handler sich nicht gegenseitig in die Quere kommen, denn das musst du in jedem Fall ausschliessen.
Im Interrupt-Handler würde ich deshalb auch nur zwei Dinge tun:
1. das Fahrwerk sofort stoppen
2. ein Flag setzen. Dieses wird dann im normalen Programmablauf ausgewertet, und es können Rangiermanöver oder ähnliches folgen.
Zudem kann man den Interrupt, wenn er einmal ausgelöst wurde, noch für eine gewisse Zeit "verriegeln". Es muss sichergestellt sein, dass der Interrupt-Handler nicht mehrmals zugleich aufgerufen werden kann. und: nen Taster würde ich immer entprellen, das ist somit gleich mit erledigt.

Beim Monstertruck sieht der Interrupt-Handler so aus, mit Entprellung:


void buttonHandler()//*******************ISR für den Joystick-Button, entprellt*********************
{
static unsigned long lastInterruptTime = 0;
unsigned long interruptTime = millis();
if (interruptTime - lastInterruptTime > 200)
{
if(servoMode==0)
{servoMode=1;}
else
{servoMode=0;}
}
lastInterruptTime = interruptTime;
}

und initialisiert wird der Interrupt so:

attachInterrupt(1,buttonHandler,RISING); // Interrupt für den Stickbutton in der setup()

Beachte dass man die Interupt-Nummer angeben muss, _nicht_ den Pin! Das ist in meinem Fall Pin 3.
Achja: ich hab den Pin auf INPUT_PULLUP gestellt, anders hats nicht funktioniert. Kommt aber drauf an, wie das genau verschalten ist (ich glaub, mein Button gibt beim Drücken LOW aus).
Und: ich kann mit dem Interupt sowohl die Antriebe ein-als auch aus schalten, da ich ne Abschalt-Automatik drin habe, die den Antrieb nach einer bestimmten Zeit anhält. So kann ich den mit dem Button auch wieder aktivieren.

[Benny1989]

hmm okay, und wieso keine zwei Interrupts? der Mega hat ja genug Speicher oder des gleichen! Ist es dann nur das die beiden Interrupts sich nicht in die Quere kommen?
Denn dann verstehe ich auch nicht wie ich die beiden Schalter / Taster anschließen soll - ich brauch ja für jeden Taster ein Pin am Mega! Weil wenn ich ihn an Pin 21 anschließe,
heist der Inter ja 2 so wie hier: attachInterrupt(2, zurueck_RECHTS, RISING);

Dann fängts schon wieder an, dein Beitrag kann ich verstehn aber am Code tu ich mir wieder schwer >.<
Wobei es ja auch Englisch ist und nicht Deutsch wie du letzt geschrieben hast^^;-)

Was mir auch schleierhaft ist der " Servo Mode" also wo sag ich ihm was er machen soll im viid buttonHandler .....
Also in meinem Falle " zurück_RECHTS oder zurück_LINKS ....
Wollte auch zwei haben, das wenn der rechte gedrückt wird, nach links ausweicht und wenn der linke Interrupt ausgelöst wird,
nach rechts ausweicht! Wie kann ich das nun in deinem viid buttonhandler lösen?

Aber ich sollte es dann schon so machen wie du es vorgeschlagen hast? Alleine schon wegen dem Entprellen .... oder ?

[Rabenauge]

Du hast unter anderem zwei "Servos" laufen (für den Mega sind die Fahrtregler nix anderes)- vermutlich über die Servobibliothek?
Die braucht mindestens einen Interrupt schon mal. Diverse andere Bibliotheken ebenfalls (ich glaub, auch NewPing nutzt einen)-man gehe also sparsam damit um, sonst könnte was anderes nicht mehr funktionieren. Mein Monster z.B. kann tone() nicht mehr benutzen-auch das bräuchte nen Interrupt-und alle sechs sind belegt!
Ausserdem darf eine ISR niemals unterbrochen werden (dort wird ja das laufende Programm angehalten, und wenn nun die ISR selber gestoppt würde, weil noch ein Interrupt kommt, kannste dir denken, dass sich das Programm nie mehr in das Hauptprogramm zurückfindet). Aber genau das würde passieren, wenn die beiden Taster "zugleich" ausgelöst werden. In Wirklichkeit werden sie das nämlich nie-sondern mindestens um Mikrosekunden versetzt.
Und: wozu auch? Häng die beiden Taster parallel an einen Pin, dann isses Wurst, welcher der beiden, oder ob beide auslösen. Einfacher gehts gar nicht...

Zur ServoMode: das läuft bei mir so, dass es ne Variable gibt (quasi nur ein Flag) die so heisst. Im Hauptprogramm (eigentlich auch nur in nem Unterprogramm, weil das Hauptprogramm bei mir nur die jeweiligen Fahrprogramme startet) wird zyklisch ein Unterprogramm aufgerufen, was den deutlichen Namen schalteServosAnAus() trägt.
Das guckt, ob ServoMode 1 hat oder 0 und wenn 0, werden die "Servos" (der Fahrtregler ist aus Arduinosicht auch nur ein Servo) abgeschalten, und bei 1 wieder an.
Ist noch bisschen komplizierter, weil das in Wirklichkeit nur dann passiert, wenn sich der Modus auch geändert hat, aber im Prinzip eben.
Das musste ich so machen, weil man natürlich aus der ISR raus nicht noch nen anderes Unterprogramm aufrufen kann bzw. sollte.
Im Prinzip kannst du das genauso machen, dann gehst du sicher, dass eine Betätigung der Stostange niemals verpasst wird, und hast dennoch ne akzeptabel schnelle ISR.
Den Teil:
if(servoMode==0)
{servoMode=1;} kannst du rauslassen (bzw. solltest du...) da der meine Antriebe dann einschaltet, wenn sie bereits aus sind.

Der Rest ist die Entprellung, hier wird sichergestellt, dass nur alle 200ms der Interrupt auch "registriert" wird, das musste ich einbauen, da ich eben ein-und ausschalten kann damit.

Hier dazu noch das Servo-Schalt-Unterprogramm:


void schalteServosAnAus() //********** Servo und Regler zu-oder abschalten *******************
{
if (servoModeAlt!=servoMode)
{
switch(servoMode)
{
case 1:
fahrtRegler.attach(PIN_FAHRTREGLER); // Fahrtregler
lenkServo.attach(PIN_LENKSERVO); //Lenkservo

break;
case 0:
fahrtRegler.writeMicroseconds(1500);
delay(100);
fahrtRegler.detach();
lenkServo.writeMicroseconds(geradeAus);
delay(100);
lenkServo.detach();
break;
}
servoModeAlt=servoMode;
}
}

Das wird einfach in den meisten Fahrprogrammen immer mit in die Schleife genommen, und wenn sich der Servomodus zwischendurch geändert hat (und _nur dann_), tut es seinen Job. Vorteil: es kann auch ohne den Interrupt arbeiten, weil man im Programm die Variable servoMode jederzeit ändern kann. Bei mir ist da z.B. noch ein "Timer" programmiert, der momentan nach ner Minute Fahrzeit die Servos abschaltet- damit mir das Monster nich abhauen kann. Es stoppt also nach dieser Zeit _immer_ - ich gehe hin, drücke den Button, und weiter gehts. Die Zeitspanne kann ich natürlich beliebig verändern, später (wenn ich sicher bin, dass nix mehr schiefgeht) kann das ganz raus.
Auch, wenn z.B. der Fahrauftrag erledigt wurde, wird servoMode auf 0 gesetzt, um dann anzuhalten, oder wenn die Akkuspannung zu niedrig wird...genauso wird per Software eingeschalten im Fahrmodus GPS2Home, wenn die Kursdaten berechnet sind und das GPS einsatzbereit ist. Ist also schön flexibel.

[Benny1989]

oookay, jetzt wird's wieder zu viel^^vllt denk ich manchmal auch zu kompliziert das kann ich mir schon vorstellen!

Also Fakt ist 1x Interrupt und die beiden Taster Parallel an ein Mega Pin ?
Wie gesagt was ich dann noch ned verstanden hab! Ich wollt ja wenn der eine Taster gedrückt wird soll er in die eine Richtung ausweichen
und wenn der andere Taster gedrückt wird soll er in die andere Richtung ausweichen!

Das kann doch parallel geschaltet ned funktionieren oder ?

Ja klar ich benutz ide Servo.h der Fahrtenregler ist nichts anderes wie zwei Servos, das ist bei mir nichts anderes wie bei dir!

Bin mit den beiden Codes die du jetzt beschrieben hast etwas verwirrt ... der zweite war nur zur demo oder?

mein Hauptprogramm sieht wie folgt aus!


void loop()
{
if(tempVORNE_MITTE < triggerDistanz || tempVORNE_RECHTS < triggerDistanz || tempRECHTS < triggerDistanz)
{
zurueck_LINKS();
}
else
{
vor();
}

if(tempVORNE_LINKS < triggerDistanz || tempLINKS < triggerDistanz)
{
zurueck_RECHTS();
}
else
{
vor();
}
}

Also wirklich recht einfach weil wie gesagt das komplizerte noch nicht geht!
Ich hab auch einzelne Fahrprogramme wie vor() / zurück_RECHTS() / stop() usw

Ich verstehe jetzt grad nicht, das wenn ich ein Interrupt habe und zwei Taster, denen zu sagen wenn ausgelöst dann mach dies!

Hab ich ja versucht mit Hilfe von :

attachInterrupt(2, zurueck_RECHTS, RISING);

Aber glaub das mit dem ServoMode hab ich nicht ganz verstanden, also wie du es gemeint bzw beschrieben hast schon, aber wie ich es dann für mein
Programm umsetzen kann - O.o ( Bitte Geduld mit mir :-))

- - - Aktualisiert - - -

Ich könnte es doch so machen, ein Interrupt mit den beiden Tastern.
Das wenn der Interrupt ausgelöst wird, das der Roboter zurück setzt und dann nochmals mit Hilfe von den US Sensoren prüft
ob links oder rechts vom Roboter etwas ist und dann da hin ausweicht wo nichts ist und wenn auf beiden Seiten nichts ist,
soll er immer nach rechts ausweichen ... z.B.

[Rabenauge]

Du hast alles in der Hauptschleife- das hab ich mir abgewöhnt. Kann man, bei einfacheren Programmen, natürlich tun aber:
-ich hab verschiedene Fahrmodi (im Grunde alles eigene Programme, von denen eins beim einschalten ausgewählt wird), und jedes dieser Programme benutzt ne andere Konfiguration (im manuellen Fahrprogramm, bei dem das Auto per Joystick bedient wird, brauche ich weder GPS noch die anderen Sensoren, im Modus "nur Hinderniserkennung" brauche ich den Joystick nicht, ebensowenig GPS und Kompass, usw).
Daher bot es sich an, so ziemlich alles in einzelne Unterprogramme zu packen, die ich, je nach Notwendigkeit, eben aufrufe -oder auch nicht.
Ich kann dir nicht sagen, wieviele einzelne Tasks momentan im Programm sind, aber bestimmt mehr als ein Dutzend (Display, Servosteuerung, 4x Sensoren, Interrupthandler, Kursberechnung, GPS, Kompass und Kompassdaten-Aufbereitung,SD-Karte befragen oder beschreiben........)- aber so halbwegs hab ich immer noch den Überblick, weil die einzelnen Unterprogramme recht überschaubar bleiben.
Meine loop() ist relativ kurz, da die nicht viel erledigt.

Und nein: du kannst mit zwei parallel geschaltenen Tastern natürlich nicht mehr rausfinden, welcher nun betätigt wurde- ich dachte, dafür hast du die US-Sensoren, und die Taster sollen ne Art Notstopp werden??
Bei einem Notstopp isses erstmal Wurst-da kommts drauf an, dass die Kiste _sofort_ stoppt-alles andere kann man dann in Ruhe erledigen, meinste nich?
Ich würde, bei nem Rotationsmäher, den Notstopp so auslegen dass, wenn er ausgelöst wird:
-das Fahrwerk unverzüglich stoppt
-der Mäher selber sofort bis auf den Boden abgesenkt wird (sicherlich auch nicht optimal, aber an nem solchen Mäher kann man keine Bremse verbauen, da fliegt das Messer weg)
-und nun würd ich rausfinden, was eigentlich los war.
Alles andere ist hier zweitrangig...

Falls du wirklich mit zwei Interrupts arbeiten willst (ich würd das nicht machen, siehe oben, aber ist dein Ding), solltest du in der jeweiligen ISR zuerst alle Interrupts mal sperren (weiss ich im Moment nicht ausm Kopf, wie das geht, aber mit detachInterrupt() oder so ähnlich sollt das machbar sein) und am Ende der ISR dann wieder freigeben.

Den Teil der Servo-Ein-oder Ausschalterei könntest du im Prinzip direkt übernehmen, du hast zwei "Servos" dran, wenn ichs noch richtig weiss, ich auch. Mein drittes (der Hecksensor) wird dabei ja nicht berücksichtigt, der hat mit der Fahrerei nix zu tun.
Weiss nicht, wie du deine "Servos" ansteuerst, ich mache das nie mit Gradangaben, da kommt dauernd Murks heraus, und die Einstellungen bei writeMicroseconds() musst du natürlich ggf. ändern-die passen zu meiner Lenkung und meinem Fahrtregler.
Die hab ich im Kopf mittels #define geradeaus 1500 (bzw. eben die richtigen Werte) global festgelegt.

Du bräuchtest dann lediglich in deiner Programmschlaife immer wieder schalteServosAnAus() mit aufrufen, und wenn sich der servoMode mal geändert hat, reagiert das Unterprogramm-ansonsten tut es einfach gar nix.

[Benny1989]

ja so wie du sehe ich das auch, das bei einem Notstop erstmal alle steht, nur wollte ich dann gleich mit entscheiden, das wenns wieder weiter geht, ob er nach rechts oder Links weiter fährt!
Deswegen die beiden Taster. Ich würde jetzt halt mal so machen, das ich mal die beiden Interrupts ausprobiere, ist ja auch so das ich erstmal die 5 Sensoren am Roboter anbringen muss!
Ich weis ja noch garnicht ob mein Sketch geht oder nicht? Deswegen würde ich erstmal die beiden Interrupts lassen.

Denn muss mich ja naoch Gedanken machen wie ich das mit dem Bumper umsetze!

Mein loop Teil ist auch recht kurz! der ganze Code recht lang, das mit den Task hab ich auch schon gesehen, weis ich aber nicht wie das geht!
Dann könnte ich den Sketch bisschen übersichtlicher machen! Dann währe er nicht so lang! Und ich könnte alles in die Einzelnen Tasks unterteilen!

Jetzt würd ich gerne erstmal Stück für Stück machen und ned den ganzen Code gleich fertig schreiben! Weil sonst weis ich ja ned wenn was ned geht woran es hebt!
Habe noch eine Woche Urlaub, da will ich auf jeden Fall die Sensor Abdeckungen fräsen und die Große Sensor Halterung .... vllt klappt es noch das ich nachher Bilder vom
fertig konstruierten einstelle!

Aber das mit den Tasks währe schon mal ne große Hilfe zu wissen wie es das geht!
Und Danke an die Rabenauge, das du mir das immer so Ausführlich erklärst - finde ich große Spitze :-)

[Sisor]

Falls du wirklich mit zwei Interrupts arbeiten willst (ich würd das nicht machen, siehe oben, aber ist dein Ding), solltest du in der jeweiligen ISR zuerst alle Interrupts mal sperren (weiss ich im Moment nicht ausm Kopf, wie das geht, aber mit detachInterrupt() oder so ähnlich sollt das machbar sein) und am Ende der ISR dann wieder freigeben.
noInterrupts() (http://arduino.cc/en/Reference/NoInterrupts)

[Benny1989]

Könnte mir falls das jemand macht oder weis wie man mit den Tabs umgeht im Ardiono pde ?
Das ich zb die Fahrtprogramme nicht im gleichen Fenster habe wie der Loop oder Setup Teil?
Das ich das ein wenig übersichtlicher gestalten kann. Oder macht man das in der Regel nicht so?

Wisst ihr was ich meine ?

[Sisor]

Könnte mir falls das jemand macht oder weis wie man mit den Tabs umgeht im Ardiono pde ?
Da gabs schon mal nen Thread zu: Tabs (https://www.roboternetz.de/community/threads/64517-Programm-s%C3%A4ubern-mit-vielen-void%28%29s-in-eigenen-Tabs)

[Benny1989]

Danke Sisor, würdest du / ihr das so machen oder habt ihr das alles in einem Tab?

So dann hier mal die Bilder, wie ich mir das mal so vorstelle ..... Ist noch nicht ganz fertig aber das ihr mal wisst wie ich mir das vorstelle!

Hier zwei Bilder von der Sensor Abdeckung die für die Ultraschallsensoren sind!
Werden gefräst aus dem Vollen, also sprich aus einem Stück Rennsport-ALuminium.
Die wo zu kaufen sind gefallen mir nicht und ich will das nicht so haben, so wie ich es
mit den einfachen Halterungen machen müsste, ich will z.b. die Kabel nicht sehen möchte dazu im dritten Bild mehr!

2891728918

Hier nun das Bild von der Halterung die dann Schwinungsfrei am Roboter montiert wird!
Die Halterung wird auch komplett aus einem Stück Aluminium gefräst!
Hier seht ihr die Freimachung unter der Abdeckung zur Kabelführung! Wie schon gesagt das ich die nicht sehen möchte!

28919

Im Gesamten sieht das dann wie folgt aus, die Höhe bis zum Boden bzw Rasen wird so 30 bis 35cm liegen!
Je nach dem wie sehr der Roboter im Rasen einsinkt! auf der Hälfte sollen dann die Stoßstange so zu sagen zum Schutz
mit dem Notstop Programm befestigt werden! Die Sensor Halterung ( GRÜN ) ist schon fertig das Design der Kompletten Sensor
Halterung ist noch nicht ganz fertig - werd euch dann das Finale Design nicht vorenthalten werde!

28920

Als Nachtrag:

Auf Bild zwei .... Stehen die Pins des HC-SR04 nach unten, das kommt daher weil ich es erst anderst machen wollte, habe es
noch nicht umkonstruiert! Die Pin´s müssen natürlich gernade schauen das der Stecker dann auch drauf passt.

[Sisor]

Danke Sisor, würdest du / ihr das so machen oder habt ihr das alles in einem Tab?
Bei größeren Programmen ist eine Modularisierung immer sinnvoll. Also je ein Tab für die Funktionen und Variablen aus Funk, Motorsteuerung, Sensorabfrage etc. macht schon Sinn. Das Hauptprogramm sollte dann nur noch initialisieren (setup) und die abstrakte (grobe) Abarbeitung darstellen (loop).

[Benny1989]

okay dann werd ich das mal probieren so zu machen - meld mich wenn ich evtll noch die eine oder andere frage habe!
Müssen die Variablen auch mit in die anderen Tabs oder können die im Main bleiben ?

[Sisor]

Müssen die Variablen auch mit in die anderen Tabs oder können die im Main bleiben ?
Wenn du globale Variablen meist: Kommt drauf an.
Das hier z.B. funktioniert:

// main
int globaleVariable = 10;

void setup() {}

void loop() {
tuwas();
}


// tab
int tuwas() {
return globaleVariable;
}

----------------------------------
Das hier NICHT:

// main

void setup() {}

void loop() {
tuwas();
globaleVariable++;
}

// tab
int globaleVariable = 10;

int tuwas() {
return globaleVariable;
}
----------------------------------
so klappts trotzdem:

// main
extern int globaleVariable; // Compiler die andernorts definierte Variable mitteilen

void setup() {}

void loop() {
tuwas();
globaleVariable++;
}

// tab
int globaleVariable = 10;

int tuwas() {
return globaleVariable;
}

[Benny1989]

also ist "return" der springende Punkt?

im Main steht:

int tempVORNE_MITTE; oder
int ledPin_ROT = 4; oder
int bumperPin = 6;

in dann hab ich es in verschiedene Tabs aufgeteilt wie du ja shon richtig geschrieben hast!
und in dem tab muss dann vor die globale variable das "return" davor?


also anhand von einem Beispiel nur das ich es versteh und wir nicht aneinander vorbei reden!

das is der Main Teil


int ledPin_ROT = 1;
int ledPin_ORANGE = 2;
int ledPin_GRUEN = 3;

void setup()
{
pinMode(ledPin_ROT, OUTPUT);
pinMode(ledPin_ORANGE, OUTPUT);
pinMode(ledPin_GRUEN, OUTPUT);

ampel();
}

void loop()
{
}

und das in neuem Tab der heist Ampel.pde (pde zeigt es dann nicht an in dem Tab )


void ampel()
{
digitalWrite(ledPin_ROT, HIGH);
delay(10000);
digitalWrite(ledPin_ROT, LOW);

digitalWrite(ledPin_ORANGE, HIGH);
delay(5000);
digitalWrite(ledPin_ORANGE, LOW);

digitalWrite(ledPin_GRUEN, HIGH);
}

int ledPin_ROT = 4; zählt ja auch als globale variable - Richtig?
Der Compiler meckert so aber nicht!

[Sisor]

und in dem tab muss dann vor die globale variable das "return" davor?
Nein, das hat nichts miteinander zu tun.
Hab meine Erklärung oben ergänzt.

[Benny1989]

Okay ja das hab ich verstanden!

Aber ist mein Beispiel mit der Ampel richtig? also das man dann gewisse Teile so in Tabs einfach schreiben kann?
Weil wie gesagt mit dem Bsp bei der Ampel er nicht meckert

[Sisor]

Klar, das Ampel Beispiel ist ok.
Ich würde aber alternativ
#define LEDPIN_ROT 1
#define LEDPIN_ORANGE 2
#define LEDPIN_GRUEN 3
(Großbuchstaben) empfehlen, weil es sich hier um Konstanten handelt. Kein Muss, aber guter Stil.

[Benny1989]

Okay, Konstanten das Wort hat mir gefehlt ....

also LED oder Button Pins sind Konstanten! und Das andere Variablen - Global oder Lokal.

Ich wollte e schon Fragen, was zwischen den beiden Unterschiedlichen Schreibweisen der unterschied ist!??

int LEDPIN_ROT = 1; und #define LEDPIN_ROT 1

ich hab schon bemerkt immer wenn eine Library im Spiel ist also, NEW PING.h oder Servo.h wird das gerne gemacht!
Hat das einen bestimmten Grund oder einen bestimmten Vorteil?

Wobei es ja auch: int LEDPIN_ROT und const int LEDPIN_ROT gibt also wenn die Konstante nicht geändert werden soll.

Wie macht man das dann mit dem #define wenn man sie nicht ändern darf oder ist das schon von Anfang an gegeben?

[Sisor]

'Nerdmütze aufsetzen'
#define ist eine Präprozessor-Direktive (wie alle Befehle, die mit '#' beginnen). Bevor der Kompiler den Quelltext in Maschinencode übersetzt, ist der Präprozessor am Start. Der 'klebt' zuerst alle Quelltextteile zusammen, sofern mit #include andere Teile integriert werden sollen. Also bastelt erstmal einen Gesamtquelltext. Gleichzeitig werden auch alle '#define-Begriffe', die im Quelltext vorkommen ersetzt. Also z.B. wo LEDPIN_ROT steht, wird dies mit einer 1 ersetzt.

'const int' arbeitet anders, weil noch eine Typenprüfung stattfindet. Also z.B. würde 'const int zahl = 17.44;' eine Fehlermeldung provozieren, weil hier eine Gleitkommazahl als Ganzzahl definiert werden soll. Normalerweise sollte z.B. 'const int zahl = 8;' vom Optimierer des Kompilers ebenso direkt in Maschinencode geschrieben werden, so dass effektiv außer der Typprüfung kein Unterschied zwischen beiden Schreibweisen vorhanden ist.

'Nerdmütze wieder absetzen'
Kurz: Beide Definitionen sind sich sehr ähnlich.

[Benny1989]

grins okay - danke für die Erklärung

Also wie man es praktisch schreiben möchte, manchmal braucht man aber ja const int.
Habs grade am mega Getestet mit dem AmpelCode, funktioniert mit den Tabs einwandfrei^^

@ Sisor eine Frage, du hast doch mit bekommen, das ich meine 5 Sensoren mit der oder Abfrage, abfrage.


void loop()
{
if(tempVORNE_MITTE < triggerDistanz || tempVORNE_RECHTS < triggerDistanz || tempRECHTS < triggerDistanz)
{
zurueck_LINKS();
}
else
{
vor();
}

if(tempVORNE_LINKS < triggerDistanz || tempLINKS < triggerDistanz)
{
zurueck_RECHTS();
}
else
{
vor();
}
}

Wenn das alles verodert ist fragt er dann auch einen nach dem anderen ab? Nicht das ich mir mit den Echos in die Quere komme ???
Also ned das der eine Sensor das Echo vom anderen Sensor abfragt!

[Sisor]

Ich sehe in deinem Quelltext überhaupt keine Abfrage der Ultraschall-Sensoren.

[Benny1989]

ja grins ....

weil die in den Unterprogrammen stecken^^


void scan_VORNE_RECHTS()
{
int tempVORNE_RECHTS = VORNE_RECHTS.ping();
int VORNE_RECHTS = tempVORNE_RECHTS / US_ROUNDTRIP_CM;
if(VORNE_RECHTS == 0)
{
VORNE_RECHTS = MAX_DISTANCE;
}
delay(100);
}

[Sisor]

- Deine Funktion ist vom Typ void, liefert also keinen Wert zurück.
- Dein Hauptprogramm ruft diese Funktion nie auf.

[Benny1989]

em stimmt, so klappt das wahrscheinlich nicht

ja aber welche Funktion sollte es sonst sein? muss dann eine sein wo auch zurück gibt, hab aber auch gedacht das
void zurück gib .... :-(

währe das dann z.b. " char" ??

[Sisor]

-void bedeutet Leere, Nichts.
-wozu das delay?
-warum nicht einfach

void loop()
{
int vm = VORNE_MITTE.ping_cm();
int vr = VORNE_RECHTS.ping_cm();
if(vm && vm < triggerDistanz || vr && vr < triggerDistanz ...
}
Damit kannst du dir die Funktionen sparen.

Um deine ursprüngliche Frage zu beantworten: Die US_Sensoren werden nacheinander abgefragt, und kommen sich nicht ins Gehege.
Übrigens: Bei 70cm maximaler Distanz dauert ein ping-Funktionsaufruf etwa 2*0,7/340 s = 4 ms lang.

[Benny1989]

okay also so kann ich das auch machen, mit der separaten Funktion hab ich es halt etwas besser verstanden !

Das heist ein US Sensor brauch 4ms für eine Messung?

Ich glaub dir schon das dass so ist hab ich ja auch grad gelesen....
Nur hab ich schon Beispiel Programme gesehen, wo die das auch mit "void" gemacht haben - komisch

Ich hab zum Beispiel global Deklariert die Distanz und die Maximale Distanz:


int triggerDistanz = 70;
int MAX_DISTANCE = 100;

Brauch ich das halt dann noch trotzdem ?
Weil ich würd gern vorerst das so mit den Unterprogrammen machen! Weil das es für mich verständlich bleibt!

Du Sisor, hast ja weit aus mehr die Erfahrung und Kompetenz, wenn du mein Code schreiben würdest währe er wahrscheinlich nur 1/4 so groß wie
jetzt. Das is das was ich gemeint hab, das ich es momentan noch so schreibe das ich es auch verstehe, aber es funktioniert immer besser!

Also wenn ich das so lassen möchte und die Funktion " void scan_VORNE_RECHTS " bleiben soll - muss ich das void ersetzten nur durch welches?
es gibt float() char() Byte() word() nur welches von denen gibt auch Aussagen zurück?

[Sisor]

Nur hab ich schon Beispiel Programme gesehen, wo die das auch mit "void" gemacht haben - komisch
Das geht auch, mit globalen Variablen oder Addressübergabe. Nur ist das nicht der konventionelle Weg.

Beim Initialisieren bestimmt die max_cm_distance letztendlich wie lange die Funktion ping() wartet, bis sie abbricht:
NewPing(trigger_pin, echo_pin, max_cm_distance);
Nach dem Initialisieren wird die max_cm_distance nicht mehr benötigt.
ping gibt den Wert 0 (NO_ECHO) zurück, falls das Echo nicht rechtzeitig eintrifft.

[Benny1989]

Okay das verstehe ich das dass ned der perfekte Weg ist!
Nur welche Funktion ist dann die richtige?

[Sisor]

Nur welche Funktion ist dann die richtige? ping_cm() wäre das was du brauchst.

[Benny1989]

achso muss ich es also so verkürzt machen wie du es gemacht hast und dann keine Unterprogramme?

oder heist es dann "ping_cm scanVORNE_MITTE " oder hab ich es jetzt falsch verstanden ?

[Sisor]

Wenn du wissen willst, ob die beim Initialisieren angegebene Distanz unterschritten ist, reicht:

if (VORNE_MITTE.ping_cm()) tuetwas();

[Benny1989]

okay, ich finde das mega erstaunlich ....
man zerbricht sich den Kopf tage lang ( als Laie ) und dann kommt jemand und sagt dir in 5 Minuten wie es bomben einfach geht!

also wenn ich es richtig verstanden habe sieht der Code nun so aus also der Loop Teil:


void loop()
{
int vm = VORNE_MITTE.ping_cm();
int vr = VORNE_RECHTS.ping_cm();
int r = RECHTS.ping_cm();

if(vm && vm < triggerDistanz || vr && vr < triggerDistanz || r && r < triggerDistanz)
{
zurueck_LINKS();
}
else
{
vor();
}

int vl = VORNE_RECHTS.ping_cm();
int l = RECHTS.ping_cm();

if(vl && vl < triggerDistanz || l && l < triggerDistanz)
{
zurueck_RECHTS();
}
else
{
vor();
}
}

[Sisor]

Eigentlich noch einfacher...


void loop()
{
if(VORNE_MITTE.ping_cm() || VORNE_RECHTS.ping_cm()|| RECHTS.ping_cm())
{
zurueck_LINKS();
}
else
{
vor();
}
...
Du solltest dir mal ein bischen Zeit nehmen und die NewPing.h und NewPing.cpp mal in Ruhe durchlesen, da stehen alle Antworten auf deine Fragen drin.

[Benny1989]

grins wollen wir es nicht übertreiben grins ....
Aber wenn ich das noch einfachere nehme? weis er das dann automatisch? das heist ja wenn die Distanz kleiner ist wie triggerDistanz woher weis er das denn dann ?

brauch ich aber die beiden globalen Variablen noch? ja schon weil sonst weis er es ja nicht was die min und max Distanz ist oder ?

int triggerDistanz = 70;
int MAX_DISTANCE = 100;

Weil das ich es verstehe, warum heist das vl & & vl < triggerDistanz
Wieso zwei mal vl?

[Sisor]

Aber wenn ich das noch einfachere nehme? weis er das dann automatisch? das heist ja wenn die Distanz kleiner ist wie triggerDistanz woher weis er das denn dann ?

Weil du das beim Initialisieren so festlegst.


int triggerDistanz = 70;
int MAX_DISTANCE = 100;
Wozu brauchst du 2 verschiendene maximale Distanzen?

Weil das ich es verstehe, warum heist das vl && vl < triggerDistanz
Wieso zwei mal vl?
vl && vl < triggerDistanz
bedeutet: wenn vl nicht 0 und vl kleiner als triggerDistanz. Wie oben beschrieben bedeutet 0, dass die maxcmDistance überschritten ist.

grins wollen wir es nicht übertreiben grins ....
Damit würdest du aber nicht nur dir einen GROSSEN GEFALLEN tun.
Alles was C und C++ Programieren angeht, ist hundertfach im Netz hinterlegt. Dort kannst du dir deine Fragen selbst beantworten.
In der NewPing Bibliothek ist genau definiert, was die Bibliothek wie macht.

[Benny1989]

okay weil eigentlich brauche ich ja nur die triggerDistanz das reicht ja schon

Ja das muss ich mir im Netz mal genauer an schauen, ich suche oft und finde nichts, Muss ich mal nach ein paar gescheiten Seiten suchen!

Und fürs Verständnis - das vl && vl < triggerDistanz - das fehlt ja dann auch wenn du nur schreibst VORNE_MITTE.ping_cm.
Das heist das steht auch in der Bibliothek ...... ?

Ich hab schon nach so vielen NEW PING Beispielen gesucht und gesucht wo die Bibliothek beschrieben ist - aber nichts gefunden :-(

[Sisor]

Mir fällt gerade auf, dass sich die US-Sensoren wohl doch ins Gehege kommen könnten.
Fallbeispiel:
Sagen wir ein Hindernis 1m ist entfernt
- der 1. US-Sensor wird abgefragt und liefert kein Ergebnis, weil er nach 70cm nicht mehr 'fragt'
- gleich danach wird der 2. abgefragt und wird das Echo des ersten erfassen, allerdings wird dieser 'behaupten', es sei ein Hindernis in 30cm Entfernung (100cm-70cm=30cm)

[Benny1989]

okay kann ich das irgendwie ausmerzen ? oder muss ich das nun doch mit Unterprogrammen machen?

[Sisor]

Ich würde testen, wie weit die US-Sensoren messen können, dann mit dieser maximalen Messdistanz die Zeit berechnen, die mindestens zwischen 2 Messungen vergehen muss.
Im Prg würde ich dann die Sensoren einzeln abfragen und jeweils in der freien Zeit bis zur nächsten Messung andere Dinge wie z.B. Funk auswerten.

[Benny1989]

Okay hört sich nach dem richtigen Weg an. Nur bis ich das testen kann, vergeht noch ein bisschen, denn ich muss die Sensoren noch bestellen und die Halterungen fertigen!
Bis das dann am Roboter so sitzt wie ich das gerne hätte vergeht noch bisschen, das ich das testen kann. Werde es im Hinterkopf behalten und dann an der Stelle weiter machen
wenn das dann Spruch reif ist, genau so wie mit den Bumpern. Schön eins nach dem anderen^^

[Rabenauge]

Kannst du berechnen: Schallgeschwindigkeit und die maximale Reichweite: zwischen 4 und 5m schaffen sie. Wenn du 6m ansetzt dürftest du auf der sicheren Seite sein. Musst die Entfernung natürlich doppelt nehmen, weil ja das Echo zurück kommt.
Das is halt ein Nachteil der US-Sensoren: besonders schnell sind die Brüder nicht.

[Sisor]

Kannst du berechnen: Schallgeschwindigkeit und die maximale Reichweite: zwischen 4 und 5m schaffen sie. Wenn du 6m ansetzt dürftest du auf der sicheren Seite sein. Musst die Entfernung natürlich doppelt nehmen, weil ja das Echo zurück kommt.
Das is halt ein Nachteil der US-Sensoren: besonders schnell sind die Brüder nicht.
Dann wären:
Zeit, die zwischen 2 Messungen vergehen muss: 12m / (340m/s) = 35ms
Zeit einer Messung bei 70 cm maxDistance: 1,4m / (340m/s) = 4ms

[Benny1989]

Das heist wenn man alle 40ms (mit ein bisschen Sicherheit ) die Sensoren abfragt, sollte es eigentlich gehen! oder ?
nur ob 40 oder 70ms das is doch so schnell da macht das nichts oder ? wenn man bisschen Sicherheit dazu gibt?

- - - Aktualisiert - - -

haben wir ja schon gestern geklärt, das hier einer nach dem andern mit ODER abgefragt wird!

Wie sag ich ihm jetzt am besten, das er 40ms warten soll zwischen jeder ODER Abfrage?


void loop()
{
if(VORNE_MITTE.ping_cm() || VORNE_RECHTS.ping_cm() || RECHTS.ping_cm())
{
zurueck_LINKS();
}
else
{
vor();
}

if(VORNE_LINKS.ping_cm() || LINKS.ping_cm())
{
zurueck_RECHTS();
}
else
{
vor();
}
}

[Benny1989]

währe es denkbar mit Hilfe von millis() zum Ziel kommen? da ich kein Delay verwenden möchte weil sonst ja das ganze Programm angehalten wird?

[Sisor]

Ich hab da mal was vorbereitet:

// ----- Ultraschallsensoren (US) -----
#include <NewPing.h>
#define MAX_DISTANCE 70 // 70 cm sind maximale Distanz, Werte darüber sind uninteressant
#define ANZAHL_SENSOREN_US 5
NewPing lUS (1, 2, MAX_DISTANCE); // jeweils die Pins eintragen
NewPing lvUS(1, 2, MAX_DISTANCE);
NewPing mUS (1, 2, MAX_DISTANCE);
NewPing rvUS(1, 2, MAX_DISTANCE);
NewPing rUS (1, 2, MAX_DISTANCE);
NewPing sensorenUS[ANZAHL_SENSOREN_US] = {lUS, lvUS, mUS, rvUS, rUS};
enum SENSOREN_US { LINKS_US, LINKS_VORNE_US, MITTE_US, RECHTS_VORNE_US, RECHTS_US};
// ----- END_Ultraschallsensoren -----

#define MIN_TIME 35 // minimaler zeitl. Triggerabstand in ms

void setup() {}

void loop() {
// Variablen für Zeitpunkt und Sensornummer
static unsigned long timeMemory = 0;
static byte aktuellerSensor = LINKS_US;

// aktuellen US-Sensor abfragen
// (ist MAX_DISTANCE unterschritten?)
if(sensorenUS[aktuellerSensor].ping_cm()) {
switch (aktuellerSensor) {
case LINKS_US : // tuwas(); // Hier jeweils auf Hindernis reagieren
break;
case LINKS_VORNE_US : // tuwas();
break;
case MITTE_US : // tuwas();
break;
case RECHTS_VORNE_US: // tuwas();
break;
case RECHTS_US : // tuwas();
break;
}
}

// Abfrage eines US-Sensors beendet, jetzt Zeit nutzen:
while (millis()-timeMemory < MIN_TIME) {
// nutzeZeit();
}

// auf nächste Abfrage vorbereiten
timeMemory = millis();
// alle Sensoren abgefragt? -> Zähler zurücksetzen
if (++aktuellerSensor > RECHTS_US) aktuellerSensor = LINKS_US;
}

[Benny1989]

uffff ... okay.

Also, du hast das gemacht was ich auch schon vor hatte und nicht hinbekommen hab ( schäm )

Die NEW PING Library kann ja bis zu 15 Sensoren verwalten genau so wie du es gemacht hast!

Nur vom Loop Teil verstehe ich das switch / case / brake nicht ganz ....
Also wie ich sehe is das die bestmögliche Lösung, aber das ich nichts anderes wie vorher oder ?
nur das du Global eine Zeit festgelegt hast in der Reihenfolge mit Pause die Sensoren abfragt?

[Sisor]

Also wie ich sehe is das die bestmögliche Lösung, aber das ich nichts anderes wie vorher oder ?
nur das du Global eine Zeit festgelegt hast in der Reihenfolge mit Pause die Sensoren abfragt?
Kurz: Ja.

Nur vom Loop Teil verstehe ich das switch / case / brake nicht ganz ....
Na dann google mal switch case...
Im Prinzip wird hier je nach Sensor verschieden reagiert.

[Benny1989]

okay, das muss ich mir in Ruhe durchlesen, das es auch hängen bleibt!

du hast unten eine "while" Anweisung wo man in der Pause etwas machen kann?
Sehe ich das richtig? Ist das die Pause zwischen zwei Messungen ?

Und das Brake gehört dann aber schon zum switch und case ?

[Sisor]

du hast unten eine "while" Anweisung wo man in der Pause etwas machen kann?
Sehe ich das richtig? Ist das die Pause zwischen zwei Messungen ?
Ja.

Und das Brake gehört dann aber schon zum switch und case ?
break ist ein C-Befehl, der u.a. in switch-case-Konstrukten Verwendung findet.

[Benny1989]

Okay, danke, ich werd mir die Switch case Geschichte Zeit nah in Ruhe anschauen!
Sensoren sind bestellt und an der Halterung bin ich dran! Bilder Folgen ....

[Feuerring]

Okay, danke, ich werd mir die Switch case Geschichte Zeit nah in Ruhe anschauen!
Sensoren (http://www.rn-wissen.de/index.php/Sensorarten) sind bestellt und an der Halterung bin ich dran! Bilder Folgen ....

schade das nicht weiter Berichtet wurde, ein echt interessantes Projekt